BASIC Developer & Support Resources > Compilers

OxygenBasic embeddable scripting interpreter

(1/6) > >>


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,
--- Quote ---Why would that make sense?
--- End quote ---
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.



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.


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.


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.


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?


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.



[0] Message Index

[#] Next page

Go to full version