ScriptBasic - Part 2Author: Dave Date: 05.30.14 - 1:21am this is a post on some observations into embedding the ScriptBasic interpreter into your own applications. Note I have only spent about 4 days sifting through the project, so this is a pretty cursory view and I could be way off. This is just what I have seen so far. The code base is some pretty dense C in parts. Lots of function pointers stored in structures. There are sections of code I wouldnt want to touch without a lot of study due to this complexity. I was able to get a VS2008 project file up and compiling in an hour or two which is pretty good. There is a decent CHM for documentation. There is also a lot of sub projects for various things. Ultimately I started my own and followed along with the embedding guide to create a test application. He did a really good job making features optional, such as not having to load a config if you didnt want to (which has to be compiled from text format to use) Typically a config file would point to the installed directories for modules, include directories and app settings. For a standalone app embedding, I would rather do this through an API, which isnt available. It appears that the embedding vision it was built around, was that the parent app would load a script and call defined functions based on events. The parent app can then set/retrieve global variables or function return results. Say from a web server receiving a document request. The embedding style I had in mind was similar to the MS Script control where scripts can call functions in the parent app and do processing from there. More on this latter. I really liked that ScriptBasic has a debugger capability. Its implemented as an opcode preprocessor giving you the chance pause and inspect variables and the execution process. Going back to the density of the code in parts, doing something like extracting the compiled config reader code is a pretty complicated ordeal. It is interleaved througout many sections of code. My first run at trying to extract it in favor of a simple struct took about 6hrs to get it to compile again, and left me with some strange crashs leading me to revert the changes. The preprocessor support and external module support is similarily complex (actually more so). Preprocessors and extension modules are designed to be external dlls. As an extensible script intrepreter executable this is a good design. As an embedded script intrepreter in my own app, I would really prefer they were all in the same binary for development and debugging sake. With a little copy paste, it was pretty easy to add new API allowing you to add a compiled in preprocessor to the internal structures. In terms of a compiled in extension module, this was actually easily accomplished as well, albeit not exactly in the way I was hoping for. I wanted a way to add native functions that could be called in the script easily. Maybe even an object or namespace resolver such as calls to scriba_AddResolver(pProgram, "myObj", &my_resolver); then in the script myObj.MyFunc(1,2) would call my_resolver("myFunc", ...) The easy way to call native functions, is by using the existing extension module capabilities. You can compile them into the embedded library, then use the declare mechanism in the script to access them because they will be exported from the parent app. (even for exes) Originally they were designed to give the scripts access to extended functionality such as registry access on Windows systems, but this is a still the same thing, just in a slightly different light. Adding a new command to the interpreter looks a bit harder and is not that documented. This lets you add individual C functions easily enough, but ultimately my target is going to be adding VB6 COM Objects, This will be managable as is through a single gateway function such as: declare sub callObj alias "callObj" lib "test.exe" a = callObj("myObj.myFunc", 1 , 2) The VB6 CallByName function will be put to good use, but you will be limited to accessing the primary functions/properties of the object I think. (ie myObj.itsObj.someProp probably wont work at least not without some parsing and intermediate steps). Not the prettiest, but manageable. Also, I think the way the preprocessor works..you would have to use wait loops as is to stall it. getch() does this nicely in console mode. Having the opcode processing code not be in a loop and only step when explicitly called might be a better way for a GUI app. I will have to research this more since they do have a GUI debugger and socket based listener to receive debug commands. Code wise the quality seems very good. I havent even bothered to test its script engine capabilities yet in terms of control flow handling, operators, etc. I am just assuming those are all good at this point based on the quality of what i have seen, how well it has functioned so far, and its long dev history. The complexity of the lexer, module manager, syntax, and external function caller, I am not sure if I dare touch those with the easy work arounds I have already identified above. Not exactly as I envisioned it, but all workable and stable. with these hurtles overcome, next step is to slap together a quick VB6 gui to act as the debugger interface and see what it takes to get it to play nice. Not sure if I want to stick with the socket based example, or manage it through a hardcoded API of call backs. Once I can fully flesh that out and get something I am happy with, then I will circle back and do some COM object tests. If thats successful, then I can begin work on weaving it all together using the scivb.ocx syntax highlighting control based on scintilla. Its all within reach, were still on track and I have wanted an embeddable script control that supports single stepping, variable inspection, and general debugging for a long time! Comments: (2)On 01.31.20 - 4:44am Peter Verhas wrote:
On 01.31.20 - 6:07am Dave wrote:
|
About Me More Blogs Main Site |
||