OxygenBasic embeddable scripting interpreter

[JRS]

Charles,

We may be looking at this from the wrong angle. Embedding SB into O2 would give you much more control and transparency with the interface.

Back to the future

I think showing O2 spawning SB scripts in threads and using shared memory for variable sharing between the two would be a nice example.

You might be thinking,

Why would that make sense?

and my response is that I could use O2 for framework and OS interfacing SB doesn't provide and use SB for the business logic side of the application.

John

[cevpegge]

Yes John, this would be simpler to implement I agree.

The Windows message loop is the dominant issue. Embedding Oxygen in ScriptBasic would require multithreading or some kind of context switching to break out of the loop to hand control back to SB periodically.

With ScriptBasic embedded in Oxygen, this complication is avoided - ScriptBasic functions are called when needed depending on events. This fits in perfectly with the Windows way of doing things.

Charles

[JRS]

That's great Charles. I agree that this will be a much better way.

The SB embedding API should have everything you need. You may want to have a peek at the SBHTTPD (multi-threaded webserver) as a guide. (ignore CGI & running as a service code) The MT shared memory interface for the script and the embedding API thread functions supporting it should be all that is needed with no new code to write. As I see it, this is Plug N Play.    & you already made the effort to create the .bi include for ScriptBasic embedding.
 

John

FYI The word embeddable ain't in the Microsoft encarta dictionary. My Firefox spell checker and Google doesn't seem to have a problem it being a valid word.

[JRS]

Charles,

I thought I would try and put a set of OxygenBasic scripting extension function concepts together to discuss. Each SB script runs in it's own thread but in the same process as O2. Variable sharing (locking supported) between O2 and scripts running in threads will be handled by the existing SB API.

• SB_Run() - This loads and runs a SB program (first checking if a pretokenized version of the script exists) and returns a valid thread session ID.
  
• SB_Load() - This only loads a SB program allowing O2 to call functions and subs setting / retrieving SB specific variables if needed.
  
• SB_Debug() - This loads the SB script, opens a console windows and allows interactive debugging (single stepping through the program, breakpoints, ...)
  
• SB_Call() - This allows calling SB functions and subs using the load script option.
  
• SB_Session() - This returns status info about the SB thread. This function could be used to also manage static session variables between iterations.
  
• SB_SysVar() - This allows setting/getting shared memory variables (this is where locking comes into the picture) all threads and O2 have access to.
  
• SB_End() - This initiates a process wide graceful shutdown of all active threads and any shared memory that may have been defined. (O2 gets an application termination request from the user)
  

If you create a SB.DLL interface or SB.LIB interface with the above functionality, I think the application programmer would have enough tools to work with to design a multi-threaded application framework with a high level scripting interface to give it life.

I'm unsure if it makes sense to give SB any direct access to O2 defined controls. If in O2 you define a script function to react to an event, then that function should service any request to the O2 framework within it's definition. SB should be easy to use in O2 but shouldn't steer the ship.

The other question I have is it possible to call a SB function if the script is load as a thread?

[JRS]

Charles,

I have given the SB embedded in O2 concept more thought and this is what I have come up with. I want to use O2 for my application launcher which will be a spiffy navigation system and dashboard front end to SB based master file maintenance, transaction entry, reporting and utilities. I had hope that Armando was going to complete and offer the source to the IUP GUI he was playing with but that looks like a lost effort. Peter's Gtk-Server is a nice second choice and if the Gtk DLLs are preloaded for the process when the O2 based front end is started, SB usage of those DLLs will be more responsive. I was going to use the SB multi-threaded HTTP application server running as a service and start application threads using the CGI protocol for a localhost centric client / server environment until O2 came along.

If I can have something like the SB called functions described above, I should be able to get the best out of both language environments.


John

[cevpegge]

John,

Threads are not intrinsic in Oxygen. We would use the Windows kernel thread functions directly. Do you want to initiate the threads in Oxygen the get them to do sb_load / sb_call operations? Just to get a clearer picture.

Charles

[JRS]

SB includes an API for pthread for threading and supports shared/session variable memory management. The MT extension module is the interface for the SB script side and the embedding API has the functions for creating SB aware threads and memory management. (why recreate the wheel?)

The main reason for the request to embed SB in O2 is a host compiler to spawn threads and provided OS based functionality not available at the SB script level.

[cevpegge]

Does this mean Oxygen would not need to deal directly with the threading aspect, making normal calls to SB?

[JRS]

The ScriptBasic embedding API has everything you need to do the integration. I thought it would be best to make the SB interface an O2 DLL or linkable library and keep O2 pure.

You may want to have a peek at the SBHTTPD (multi-threaded webserver) as a guide. (ignore CGI & running as a service code)

The sbhttpd httpd multi-threaded server is a C based host embedding SB in a threaded way. Add running as a service and http/cgi support and there you go, a web server in ScriptBasic. The server application is fast and resource friendly.

[cevpegge]

Thanks John,

Were you able to make any sense of my source code BTW

Charles

[JRS]

Were you able to make any sense of my source code BTW

I'm thinking James Fuller is already converting it to BCX. 

[JRS]

Charles,

Can you offer the option in the SB_Run() and SB_Load() calls to not create a console? I think as part of the embedding interface STDIN/OUT is an argument.

John

[cevpegge]

John,

I remember working on this before - being able to control the presence or absence of the console. I think the client program has to set up a console before loading Scriba.

Charles

[JRS]

Charles,

Take a look at these SB embedding function calls.

You can call this function to define a special standard output function. This pointer should point to a function that accepts a (char, void *) arguments. Whenever the ScriptBasic program tries to send a character to the standard output it calls this function. The first parameter is the character to write, the second is the embedder pointer.

If the standard output function is not defined or the parameter is NULL the interpreter will write the normal stdout stream.

void scriba_SetStdout(pSbProgram pProgram,
                      void *fpStdoutFunction
  ){

You can call this function to define a special standard input function. This pointer should point to a function that accepts a void * pointer as argument. Whenever the ScriptBasic program tries to read from the standard input it calls this function pasing the embedder pointer as argument.

If the stdin function is not defined or the parameter is NULL the interpreter will read the normal stdin stream.

void scriba_SetStdin(pSbProgram pProgram,
                     void *fpStdinFunction
  ){

This function should be used to set the embed pointer.

The embed pointer is a pointer that is not used by ScriptBasic itself. This pointer is remembered by ScriptBasic and is passed to call-back functions. Like the standard input, output and environment functions that the embedding application may provide this pointer is also available to external modules implemented in C or other compiled language in DLL or SO files.

The embedder pointer should usually point to the struct of the thread local data. For example the Windows NT IIS variation of ScriptBasic sets this variable to point to the extension control block.

If this pointer is not set ScriptBasic will pass NULL pointer to the extensions and to the call-back function.

void scriba_SetEmbedPointer(pSbProgram pProgram,
                            void *pEmbedder
  ){

I think the client program has to set up a console before loading Scriba.

If the Oxygen program is running in a console then SB should use that for STDOUT. I see no reason to mess with STDIN.

If the Oxygen program is running in a GUI window then SB sends STDOUT to null. (unless SB_Debug is used to run the script or load a library of functions and executing through the debug preprocessor)

[cevpegge]

Good info John,

We could make a GUI console available to communicate with SB. This has the advantage of full integration into a GUI based application. SB could also have more than one console panel in the User Interface.

Charles