Vexi Updates

Lots of new features have been added to the JavaScript-like VexiScript over the past year. We need to get a web page up detailing them all.

Importantly, our documentation tools have come a long way and there is now a reference generated directly from the Core source. The website is on my radar, and is in the process of a (slow) transition to a newer version of MediaWiki.

We at Web Enable IT are having great success using Vexi for our Emanate5 platform.

Vexiscript Destructuring & Iterating Values

I have made a couple of improvements to vexi script (our dialect of javascript).

1) Destructurings

Destructurings in Vexscript are the same as those introduced in Mozilla Javascript 1.7.

//Useful for swapping values
var a = 1;
var b = 2;
[a,b] = [b,a];

// Or for handling multiple returns
var a,b,c;
[a,b,c] = f();


2)Improved for-in loop

Its pretty straightforward

var o = {a:3,b:2,c:1};
for(var k,v in o){
    // ...
}

// one might use this convention for an array
var arr = ["a","b","c"];
for(var i,v in o){
    // ...
}


This is not the same as any of the methods (there are at least 2) you can use in mozilla javascript. They support the form for(var [k,v] in o), which is unfortunate at is makes it an ambiguous syntax. It could be seen as a destructuring of just the key (so its not usually possible to have an array as a key in javascript, but its still not a very good choice in my opinion).

The other method is for each(var v in o), here the each key word just changes the behaviour of the loop. This is not really ideal as it is not useful if you need both the key and the value (which is the case perhaps as often as not).

Vexi Docs Preview

Courteousy of Mike and his inginuity:
http://vexi.sourceforge.net/docs/3.0/

It is in need of improvement and organisation but it's starting to look good and proving useful already to those of us who need it.

Vexi 3.0 build 3539 and VexiDev 0.3.5 Released

I uploaded a new build of Vexi, revision 3539 which has a slew of minor improvements and bugfixes.

Release announcements: Sourceforge, Freshmeat

Mike also updated VexiDev 0.3.5 last week after we discussed there were some issues with the update site for 0.3.4 preventing it installing.

Release announcements: Sourceforge

Vexillology

Vexillology is the scholarly study of flags... and nothing to do with the vexi platform. I hope that clears things up!

Vexi Website Updates

A long overdue update is in now occurring.

The Vexi forum and blog are now mostly done. The wiki will take a bit longer (moving from Mediawiki 1.6 to 1.14).

A more unified web presence and a better homepage should help Vexi retain the visitors to the website that don't seem to stick around at the moment.

Tip: never return in a 'finally' block

This one has had me a couple of times. When you return in a finally block, Vexi will not log the exception because the return indicates that the function or trap has concluded successfully.

The symptom is code not being executed fully - a premature stop somewhere. The premature stop to the code path is caused by an exception, e.g. accessing a property on a null object.

var somefunc = function() {
    var nullobj;
    nullobj.foo = "bar"; // error!
    return true;
}

/** misguided function to return true on success, false otherwise */
var sometest = function() {
    var ret = false;
    try { ret = somefunc(); }
    finally { return ret; }
}

Of course the above code path does look, as described, misguided. However in more complicated scenarios, especially when working with RPC, it can be easy to forget the intended notion of a finally clause - to clean up necessary resources - and slip in a return. Mostly it will be harmless but on the occasions that the code path embedded in the try clause throws an error, you'll find yourself dumbfounded as to why your code path is not completing and why there is no indication of the problem.

There is a simple rule to follow to avoid this problem (which can take hours to diagnose!) and that is to either A) never 'return' in a 'finally' or B) always preceeded a 'finally' with a 'catch(e) { vexi.log.info(e); }' to make sure the error is logged.

HTH!

Debugging Vexi Applications II

As we've used Vexi over the last year, we have added little features here and there to help us get the most of out it.

I'm always mindful of performance, so I don't like to use the 'try/throw/catch' method from the previous debugging tip in production code. However chopping and changing code in a complex environment can be a pain, especially when you are working with code that has a far reaching impact and you want to be able to get a general sense of what is happening as you use your application.

For this, I added the 'vexi.debug' property. A simple boolean on the Vexi object, which can be enabled by either running vexi with the '-debug' flag or by putting 'true' or 'false' to the 'vexi.debug' property.

This way, we can wrap fairly complex debugging operations in an if statement and avoid them in normal running. For instance, we introduced 'vexi.js.stringify(arg)' which takes a JS object and returns it as JSON. Doing this in heavily run code can be a bit of a waste of CPU power, but at the same time JSON is much more useful for debugging than the type/hash representation (e.g. object$1ab23e) of non-primitives.

if (vexi.debug) {
    var o = anExpensiveOperation();
    vexi.trace(info);
}

Also, there is the call to vexi.trace which is another new function. It is shorthand for:

vexi.log.info(vexi.js.stringify(o));

Of course, the ideal way to avoid days of debugging headaches is to do proper unit testing. It takes time to get it right, but once you have a non-trivial application, a suite of tests can save you no end of trouble and make sure your application remains solid after major changes to the code. See the VUnit documentation for more information on how to create tests.

Marketing Vexi

A revamp of the marketing message for Vexi is long overdue. At the moment, the front page of the Vexi website is just a bit of a technical mess. I need to work out exactly how to portray Vexi as a useful tool in today's market which is very favourable to Web 2.0 and not so favourable to technologies that fall outside of this misguided "inside the browser" paradigm. The message has to be much more subtle than simply stating that we believe everybody else is wrong, but it has to assuage that conclusion upon a visitor.

Technical advantages: integrated unit testing (VUnit), trap model, box layout, browser independence (Java 1.4 compatible), enhanced JavaScript (VexiScript), sandbox security, complete UI control, intuitive syntax, and more.

We can put these in a giant list and they'll appeal to some people, but to those whose mind is already made up, a different approach is required - illuminating the benefits brought to application development using a platform with the aforementioned technical advantages. Of course, examples are always good, and we have something major to show the world Real Soon Now (tm).

To be continued...

VUnit Explained

It has been said that languages without type verification don't need it because ultimately its just a limited form of testing and unit tests are a better way of doing things. Its fair to say that the argument is losing ground as people such as mozilla are looking at static type checking. Ultimately type information is much more than that, its also a way to navigate code. In any case Vexi ought to have its own testing framework, and as it turns out it does in VUnit, just not much had been written about it and how to use it. This is no longer the case, as i've updated the wiki with an explanation.

Vexidev 0.3.2

The latest release of the imaginitively titled eclipse plugin and vexi development environment 'vexidev' is now available. The new features are

• vunit launching

• library management

Bench marking vexi javascript

Out of curiosity I decided to benchmark the javascript in vexi. The first benchmark i found was on a blog called celtickane.com. I am not entirely convinced by the methodology or the naming of the tests (error handling did not seem to have handling exceptions as its bottleneck), but it will do as a first effort.

Below are the results for the benchmarks that I could run substantially unchanged in Vexi. All values are time in ms. Everything was run on my fairly old T30 thinkpad.

	Vexi 3 build 3385	Firefox 3.06	IE 7.0.5730.13
Array object	210	25	80
Error handling	401	55	181
Math object	120	49	230
String object	560	221	160
Regex object	521	65	711

Remarks

The string object benchmark is essentially testing the performance of the replace method. The reason it might be running slowly in Vexi is that it always is interpreted as a regular expression, but this does not appear to be the case in the browsers. Perhaps this is something that should be corrected.