OKit Virtual Machine / News: Recent posts

Well... the title says it all. OKit 2 is now available

After two weeks of intensive testing (done partly on version 2.0.0, never released), OKit 2 seems stable. If further performance improvements are probably possible, it is already 10% faster than the last version of OKit 1, due to a different list structure.

Among the new features:
_ Simpler object model (any object is now a generic object too)
_ Faster list methods
_ More flexible instruction set definition (suporting multiple sets and dynamic definition)
_ Merged Code and Bltn types, to provide parametrable instructions
_ More object parsing tools (parsing from files and streams)
... and many more improvements related to speed and memory management.

Today was released the LAST version of OKit 1. I think much of the bugs remaining in 1.0.1 were fixed. I do not have the resources to continue to bugfix the 1.x versions, as I am moving on OKit 2. If you want the bugfixes (and improved performance...) move to OKit 2.

Expect a release of the first stable version of OKit 2 (2.0.1) within the next few hours.

After so much silence, a final version of OKit 1 is coming, somewhen around 11/11 or 11/12. This will be 1.0.4. Why 'final'? Because OKit 2 is close behind, with almost everything changed.

This final version is for you developpers who do not want to move your applications to OKit 2, but need a close-to-bug-free version of OKit. For those who only use the interpreter, a - final, too - version of OKeval 1 is coming along, with an extended instruction set (most importantly, the MAP instruction will speed your Lists processing).
Also, these last version integrate the use of the DbgLog library, at last providing a serious attempt at standardized error logging.... read more

As announced, GOKe (the Gtk version of OKeval) is out: version 0.1.0. (See the OKit homepage for screenshots)

Warning: as the OKit API changed a little, and OKeval was divided in an executable and a lib, you should get both a new version of OKit and of OKeval before trying to install GOKe.

There were two (0.0.1 and 0.0.2) prior version (never released ;^), but my early attempts at a practical interafce were none too successfull.... read more

I just released the 1.0.1 version of libOKit.
There are few improvement over 1.0.0: two
list manipulation methods, and one minor bug fix.

What is important is a global API names modification.
As I received reports of type and method names conflicts with other packages (most of all with the List type and methods), I decided to suscribe to the standard, and include the package name in types and symbols. This will impose rewriting your code making use of libOKit, but in a very simple way ('sed' filtering should be enough). I have simply prefixed every type and method name with the "OKit_" string.

I am now working on a Gtk version of the OKit interpreter, OKeval. That means dissociating the Built-in set, and the interpreter itself, that was until now a command-line program.

So the first step will be to repackage OKeval to have a libOKeval, with the instruction set, and an OKeval command-line interpreter, making use of the library. This should come before the end of the week, OKeval v 1.0.0.

Next step, make a nifty Gtk interface (almost done, thanks Glade ;) and plug the libOKeval in it. Expect a working version before the end of the month.

With the 1.0.0 release, the OKit library has reached a turn.

There is room for improvement in the interpreter, and the instruction set. But the library, at least in my mind, is quite complete from the functional point of view. I fail to think of something that would be needed and is not already included, apart from cosmetic and modularity changes.

As for platform/os porting, I have successfully compiled the library under Visual C++, on NT4,
with very minor code changes (one included header file replacement). So this isn't an issue now.... read more

Yep! the 1.0.0 version is finally good and done. As I had announced, the 0.6.1 is functionally quite similar, since it was a pre-1.0.0.
"Only" differences are... a clean code, up-to-date documentation, a whole series of minor but unnerving bugs corrected, and a clean treatment of escaped characters in strings.

With the exception of multithreading, of which I am not so sure for the moment, there is everything I have though you could want in the field of concatenative code execution.... read more

As promised. OKeval v 2.4 is out, and works with libOKit 0.6.1.

The documentation, practically inexistant, and obsolete anyway, has been updated and completed. All you need
to install and use these interpreters should be at hand. (Nevertheless, if you encounter any problem, please report it so I can complete the doc.)

As libOKit 0.6.1 is a pre-1.0.0, a new version (3.0) of OKeval should come soon after libOKit 1.0.0, to make use of the new functionalities.

Since the last release of libOKit (v0.6.1) a few days ago, I am working on the OKeval intepreter. A version compatible with libOKit.0.6.1 should come along in a few days. In fact, it actually works just now, but I must run a few tests, and completely rewrite the documentation that is a long way obsolete (it dates from v1.2). Expect a workable version (thought I can't guarantee it to be totally bug-free by then) around the end of this week (07-20), with a (for once) usable documentation.... read more

OKit is en route for a big revision of its source code architecture: the infamous gigantic blob of the Object definition is definitely going to be no more than a bad memory.

As for the new 0.6.1 release, better modularity is on the way, and improved API symbols, with coherent naming conventions. Also improved is the IO set of methods, with user-definable formats everywhere.

In preparing that big cleanup of the library source code, I realized the current version system was impractical: there was not enough room for small updates. So the x.y version will from now on become 0.x.y, waiting for a 1.0.0...

Following libOKit 6.0, and taking into account the exec scheme change introduced in libOKit 5.0 (not too soon, you could say... sorry for that), here comes OKeval 2.3.

It does not makes use of the new Code spec justifying the release of libOKit 6.0 (and probably never will, since this feature is there to allow the end user to have more control on objects handling).

Today is coming a new version of libOKit.
Apart some API fixups, including new utility methods to improve access to some objects fields, the main changes concern the Code type.

Remember, that Code type you never knew how to use, because parsing was not implemented, and it was useless anyway? Well, its purpose is now clear, and you can make something with it.
It is a specially (in a parametrable way) handled object, parsed as '<MYCODE:[ "some" "objects" ]>'
When executed, the '[ "some" "objects" ]' list is given as arg to a handler you specified.... read more

`o' WARNING! -- Versions 4.x had a tremendous
>@< BUG. The context-passing scheme of which
/ \ I was so proud made the lib not reentrant.
-----------------------------------------------
This is corrected in version 5.0, among other
non-important subtleties. Anyway, this method
was not more efficient that the old one.
There are improvements in the over-all accessibility of objects' internal data, a new
error logging system with debug levels, and
a whole lot of other details of this brew.
A version of OKeval compatible with the revised
context-passing method will soon follow.

Strange things happen when you start writing code for optimization. My new context passing shcheme for OKit (see last news entry -- "LibOKit 4.0 is out"), via globals instead of the system stack, didn't derogate.

First, shopping through compiler optimization options (gcc) did lead to counter-intuitive results, such as -O4 resulting in poorer performance than -O3. Then I realized that -fomit-frame-pointer did... nothing at all, the code remaining unchanged wether I used it or not, though I had many void *(void) routines. And finally I tried inlining as much functions as possible, without any result. The inlined function were probably too complex... Globally, this scheme was counter-productive by a 12% factor on Pentium-class processors.... read more

Eureka! I finally solved my context-passing problem. Here is a brand-new, faster and cleaner version of libOKit, with an upgraded List execution system.

Alas, that was an inavoidable source of compatibility problem with earlier versions.

[So if you plan to use it as a complete bundle, with the OKeval executables, then check out the updated version OKeval 2.0]

--

To enter the core of the problem, context-passing (telling actual Built-in and Code implementations where to find the variables and stack) was up to this version implemented by simply passing these informations as arguments, thus using intensively the system stack. It is now implemented putting these datas at fixed places, that is, global variables. It is both faster and safer. It also makes developping your own built-ins simpler, since getting the context is now just a matter of using the right macro.

I released yesterday the 1.2 version of the interpreter build on top of libOKit.
Okeval comes in two forms: command line interpreter, and file interpreter (batch-mode).
All the planned built-ins are implemented and working, and the batch interpreter has some nifty features added, like the display of embedded help in the source files, or multiple verbosity levels.
Waiting for your feedback...

I have set up a survey to know you better, and to be able to react to your expectations about theOKit project. This will provide insight on
the directions this project should take, and
how YOU would like to be able to use it.
Please take it, it is very short but will provide me nonetheless with invaluable information: http://sourceforge.net/survey/survey.php?group_id=10996&survey_id=10967

The new (redesigned) version of the library is out (v3.0).
Beware that it is incompatible with older versions, both in API and binary formats (thus the major number change).

---

Despite what I announced in the last news, there is no change in the built-in call system. One thing at a time, because that problem is much more complex that I thought.

And yes, I will complete some day the docs on the Object API...

I am working on a complete cleanup of the OKit API, to make lists work better, in a more coherent way. I am also trying to push up the speed of the VM, through the use of a more efficient call mechanism.
All in all, this should result in SEVERE INCOMPATIBILITY with the earlier versions (1.x and 2.x), both in object binary structure and method calls, and in built-in call system.
As we did for the 1.x->2.x change, earlier versions will remain available, though not supported.
Check back in a few days on the project page to see what should be version 3.1, hopefully with major speed and reliability improvements.

After 3 months of development, and several working releases, we are happy to bring libOkit to the Open Source community, sharing development, steering and support among fellow developpers.
Hoping to make it into a powerfull Object Coding tool...