As it seems kind of long to keep using 'BaCon 2.0 build 1 patch 3', I think we might just as well start talking about BaCon 2.1.3 instead.
For sake of clarity, what do the numbers mean:
The first number indicates the main release. This relates to the core implementation of BaCon, its fundamental design, its memory management, its logic, and so on.
The second number indicates the build number. This relates to new features or enhanced statements, improved performance and functionality.
The third number indicates the patch level. This simply relates to bug fixes in the current release and build.
Main releases and build numbers will be announced on the website, but BaCon patches can appear any moment in time. The reason for this is, that previously, a lot of times packages and repositories for Linux distributions take the latest 'stable version' as a base, even though we knew this contained bugs for which the fixes would become available in the next stable release after a month or two (or longer).
So by applying fixes for bugs right away, we can keep BaCon actual and up-to-date.
Sound like a great plan moving forward. Hard to believe BaCon has caught up to the SB current release level. A fine job with BaCon on your part. I still wish you would create a generic FFI out of GTK-Server like what Charles did with DLLC.
DLLC is the replacement for DYC. It is a FFI, allows defining and accessing structures, handles creating and access to BSTR's and allows direct access to COM. (bypassing iUnknown) Recent enhancements have been multi-threading where not only can a SB script be run as a thread, that thread can run DLL functions as threads. Direct C callbacks to script functions are supported with up to 32 parameters. IUP is able to run threaded (not thread safe by design) with the SB binding as the message loop is managed/shared by all threads solving the issues IUP has running threaded. As icing, the MT shared variable/session extension module used with the SB HTTP multi-threaded web/application server works with scriba threads.
My point about GTK-Server and DLLC was not for BaCon but for interpreters and scripting languages running under Linux. I'm not saying GTK-Server can't be used as a generic FFI interface but it would be nice to lose the Gtk clothes it wears.
I'm not saying GTK-Server can't be used as a generic FFI interface but it would be nice to lose the Gtk clothes it wears.
The only 'GTK clothes' is in the name. The GTK-server can be compiled without any dependency to a library whatsoever (run './configure --with-console'), and the resulting binary can open any other C based library. There are examples on the website for XForms and Mikmod, and the GTK-server package itself contains examples for nCurses as well.
Needless to say that BaCon can access these libraries also