It’s sad that there seem to be more people interested in vandalism than contribution these days, but nevermind. I’ve deleted all user accounts since most of them were probably signups from spam-bots or hacking attempts.

If your account got deleted too, and you had a sincere interest in the project, I apologize for this inconvenience. In any case I can be reached by email. It should be shown somewhere on the ‘Need Help?’ Page above.

• Functions
• Classes
• Interfaces
• Delegates
• Co-functions
• Hybrid classes
• Weak references
• Exceptions

For something a little more complex:

• Cosporen applet

Bugs fixed

hybrid and interface

A compiler bug has been fixed that prevented you from using the hybrid keyword together with an interface identifier.

interface IFoo { }
class Foo hybrid IFoo    // did not compile
{
}

Creating a hybrid class from an interface can be quite useful, so this has now been fixed.

operator typeof and this

A compiler bug has been fixed that prevented the expression typeof(this) to compile.

class Foo
{
    method Foo() { }
    method int GetType() { return typeof(this); }    // did not compile
}

For detailed information what has changed since the last public release (0.9.2.4), see this post.

If you would like to see and test a demo-application, I have also released the JILRunOnly command-line tool. This tool is a simple console applicaton written in ANSI C that demonstrates how to embed the JewelScript library in an application.

A project and solution for VC 2008 Express is included in the package, users of other platforms unfortunately will need to create their own project / makefile. Simply do a search for all “.c” files and put all of them into the project. Set the include pathes to all directories that contain “.h” files.

When you’re done and it works, you can send me the file so I can include it in the next distribution.

The JILRunOnly source package contains everything you need to build the program, including the JILRuntime 1.0.3.0 sources. You can download the JILRunOnly package here.

Please report any bugs, problems or errors you may find.

Enjoy!

The documentation is complete, though there still might be some corrections to it if something pops up.

Source code documentation

The plain HTML version (ZIP archive) can be downloaded here.

The compiled HTML version (.chm) can be downloaded here.

Language documentation

The language documentation (.pdf) can be downloaded here (right-click to save).

However, seeing how long it has been since I’ve released an update to the project, I really want this version “out of the door” soon now.

After the first release of 1.0 on sourceforge.net, I’ll subsequently update PCalc, NetRadio and AppletForge on the main site, which is only accessible through the “old site” link above at the moment, because it is hopelessly outdated.

Then I’ll also update or remove the old JewelScript material on that site. I’m planning to move most of it to the blog, because it’s easier to update posts here, than the HTML pages there.

Last but not least, the source code documentation and the JewelScript reference PDF have to be updated, so yeah, I guess even with 1.0 stable and released, it will still keep me busy for a while. ;-)

Well, the first question is answered rather easily. Just make a file, or a set of files, that use all possible kinds of language constructs – then compile them. If you don’t get an error and it runs, it’s an indicator that the tested features work.

I have collected a set of 60+ test scripts for exactly that purpose. They are automatically compiled and run by a command-line version of the JewelScript runtime, and I use it frequently after having made changes to the compiler, just to verify that everything still works like it should.

But there’s a slight problem: You just cannot think off all of the possible combinations of expressions and other language elements, so you have to generalize and simplify. Therefore, if your set of files compiles, it is only an indication that the features work. Sometimes just exchanging a discrete type declaration by a typeless one somewhere can make a big difference. Or a type-conversion invoked that you haven’t tried.

Therefore I have a few applications, real life ones, not ones written for the sole purpose of testing, that actually use JewelScript for some purpose. These are very important, especially to test the runtime environment, but also to proof the language.

These applications are for example PCalc, a programmable calculator, NetRadio, an internet-radio where JewelScript handles the GUI, and AppletForge, a “2D game construction kit” if you will. Its an application that offers graphics and sound / music services and allows to program applets in JewelScript – for example games or any other graphical application. All of these applications use the runtime in a different way and therefore test a different set of features.

Like I said, testing if something works is rather easy, you can just try and see what happens. Testing if something does not work, because it shouldn’t, is a whole different story.

It’s a bit trickier to verify, that doing something that shouldn’t be possible, really results in an error – and the correct one. This is mainly because JewelScript will stop compiling after the first error. So you would have to make an own test script for every single expression or statement you want to fail-proof.

For cases like that, JewelScript has an internal self-test statement. Basically it allows me to have the language compile a block of code and then compare the actual result with the one I expect. Here’s a code example:

__selftest 0    { s = "hello"+"bye".toUpper(); }    // must compile to pass
__selftest 0    { s = ("hello"+"bye").toUpper(); }  // must compile
__selftest 1216 { i = ++1; }                        // must result in error 1216
__selftest 0    { i = {10,20,30}[1]++; }            // must compile
__selftest 0    { return {10,20,30}.format("%d,%d,%d"); } // must compile
__selftest 1216 { return 1++; }                     // must result in error 1216

Dependent on the result, the compiler will notify me if the test passed or failed, but it will not stop compilation on such blocks. So all I have to do is compile the files and look at the log-output to see if everything has a PASS.

It doesn’t tell me all the combinations that someone somewhere probably might come up with, though. I still don’t have an automated solution to solve that problem, but i’m working on it. ;-)

In the new version, there is basic support for exceptions, which means there is now a throw statement that lets you throw an exception.

There is also a built-in interface for exceptions.

strict interface exception {
    method exception();
    method exception(int error);
    method int getError();
}

In order to throw an exception, you’ll have to make a class that implements this interface. After that, you can use the throw statement to throw an instance of your exception class. Needless to say, you can add any amount of additional members to your exception class.

If you throw, the whole stack will automatically be unrolled to the most recent native entry-point. The JILCallFunction() method will return the handle to your exception object instead of the function’s result.

You can use the NTLHandleToError() function to test whether the result is an exception object or a regular function result. The function will actually call the getError() method of your script object and return it’s result as error code to the caller.

There is no way of catching exceptions from script code, yet. And I doubt there will be any for the release of version 1.0. However, I’m planning to add support for try / catch in a later release.

You probably wonder now what’s the use of the throw statement then. Well, it allows you to instantly end a call from the native world to the script world and pass an error object, no matter how deep inside nested function calls you currently are.

Of course this also works with multiple nested native -> script -> native -> script calls, as long as the involved native code properly propagates the error status up to their caller. Therefore this is also useful to exit delegates that are executed from native type functions.

For an example, see this small JewelScript file.

Personally, I never liked the idea of a language that “cleans up after the programmer”, and in regard to JewelScript, it was always my opinion that with a bit of discipline and the correct use of weak references, reference cycles – the only way to create memory leaks in JewelScript – could be avoided.

Just to recap, JewelScript uses reference counting to “know” when an object or value is no longer used and can safely be destroyed. However, the crux with reference counting is that you can create reference cycles. This happens when e.g. object A has a reference to object B, while object B also has a reference to object A.

In such a case, reference counting is actually useless and the two objects cannot be destroyed, unless one of them uses a weak reference, which is a reference that isn’t counted. So since JewelScript supports weak references, script programmers actually have a tool to avoid memory leaks.

On the other hand, avoiding reference cycles by using weak references or any other method requires that the script programmer actually has some fundamental knowledge of the inner workings of the script language, and that’s exactly the issue why I finally decided to add GC to JewelScript.

Because whether or not the script programmers are skilled and knowledgeable enough to avoid reference cycles, very much depends on the actual nature of application, and the scripting interfaces “target audience”.

For example, you could embed JewelScript in a book keeping or word processing software to allow users to program little automated tasks or “macros”. In such an application scenario, you wouldn’t want to ask that your users know all the finer details of weak references, reference counting, and reference cycles.

And the very idea of a “scripting language” as opposed to a “real” programming language probably is, that it should hide technical issues like that from the user, and make writing programs as easy and failsafe as possible.

Garbage collection in JewelScript

Anyway, so now JewelScript has an integrated garbage collector. However, this feature comes with a price. Because in order to use GC, all native types and, to some degree, also your application code needs to support the garbage collector by responding to it’s MARK message.

JewelScript’s GC is a simple “mark and sweep” garbage collector. The basic working principle is this: When the GC is run, it runs over all objects still on the VM’s stack, in registers and in global memory, sending them the MARK message. This will mark these objects as “still used”. Then these objects will propagate the MARK message down to the objects they still use, and so on. In the end, all of the objects that are still in use somewhere in the application will be marked. The GC will then run over all objects on the heap and find those that are not marked. Those will be considered “leaked” and destroyed.

Obviously, this would end up really messy if only one native type or application class would not propagate the MARK message on to the objects it still uses. This would cause the destruction of objects that are still in use and sooner or later lead to a crash. So if the GC is going to be used, it is imperative that all code properly supports the MARK message.

Note that using the GC in JewelScript is optional, your application is not forced to use it and GC is never run automatically. It is up to the application to decide whether memory leaks can be expected from the user or not. It is also up to the application to decide when it is time to run the garbage collector.

If you don’t want to use the GC, you don’t have to change any code. Note however, if your application should then run the GC, it will fail during the marking process, because your native types won’t respond to the NTL_MarkHandles message. That’s because usually type procs are written to return an error when they receive an unknown message.

If you do want to support the GC mechanism, then all of your native types need to correctly respond to the NTL_MarkHandles message by calling the new NTLMarkHandle() API function for every JILHandle pointer that your native class uses. Obviously, simple native classes that do not store any JILHandle pointers, don’t need to do anything, except return good status on that message.

With that, all native types are ready for GC, but what about your application itself?

There are cases, where one or more of your native C++ classes probably obtain JILHandle pointers from the runtime, but they don’t have a type proc, because they are not a native type for JewelScript. This applies for example to classes that obtain function references from the runtime in order to call script functions, or create script objects and store their reference.

These are classes that have objects from the VM, but they cannot be objects in the virtual machine, because they don’t have a type proc. Therefore, such classes won’t get the NTL_MarkHandles message from the GC. As a result, those JILHandle pointers would not get marked, regarded as unused, and destroyed by the GC.

To prevent this, I’ve added new application side functionality to the API, a mechanism to register for GC events, and unregister from them. Basically, if a C++ class obtains and stores handles from the runtime, it now has to register for GC events in order to get notified about the MARK message.

While I was adapting all my projects to support the GC, I even came across some hybrid types of native C++ classes - classes that have objects from the VM, and can be objects in the VM, because they implement a type proc.

In such a case it is best to handle both the MARK message sent to the type proc, and register for GC events. Because often there is no guarantee that a reference to such a class is currently on the VM’s stack when the GC runs.

As a rule of thumb, you cannot mark an object too often. It’s harmless to try to mark the same object twice, but it is fatal to not mark an object at all.

Subscribing is very simple. Just click on Register in the user block on the right, enter a user name and your email address, and click the register button. After that, you’ll receive an email with your temporary password.

You can change your password and personal profile settings when you log in.

If you wish to be “promoted” to the role of “Author”, to be able to write your own posts, just post a comment and say so.

I kindly ask you to post only in the “discussion” category, and keep the post civilized and on-topic.

Update May 31, 2010: After having been hacked, the blog is no longer open for user subscriptions.