Vexi

Nearing commit 4000

2010-12-01T15:00:00.000-08:00

We are fast approaching revision 4000 in subversion, which is quite a milestone. Also, since the project 'reset' it's revision number when moving from Darcs to Subversion, it is spiritually even more than 5000.

Companies Web Enable IT and Rocket Logic continue to develop successfully with Vexi. The short/medium term goal is to update the web presence so others may learn more easily of Vexi's capabilities.

Vexi Updates

2009-11-12T02:25:00.000-08:00

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

2009-08-29T16:18:00.000-07:00

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

2009-08-14T07:34:00.000-07:00

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

2009-07-01T02:45:00.000-07:00

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

2009-06-29T05:31:00.000-07:00

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

Vexi Website Updates

2009-05-18T05:33:00.001-07:00

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

2009-04-30T16:43:00.000-07:00

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

2009-03-09T16:40:00.000-07:00

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

2009-03-09T16:20:00.000-07:00

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

2009-02-19T14:14:00.000-08:00

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

2009-02-19T12:06:00.000-08:00

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

2009-02-14T09:39:00.000-08:00

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.

Debugging Vexi Applications I

2007-09-20T15:04:00.000-07:00

Most scripting languages are very hard to debug, especially as the code becomes complex and the variety of files and structures interacting with eachother becomes somewhat hard to have mapped in the mind.

Fortunately VexiScript has kept some neat features from Java and some features of it's own that make debugging complex Vexi applications fairly easy! For instance, a full stack trace with line numbers always accompanies an exception.

Of course, it may be that you don't want to stop executing code to get an idea of where your code is up to. In VexiScript, we can also throw and more importantly catch exceptions, much like in Java - but in VexiScript these exceptions are really easy to handle - just pass them to a vexi.log function and it will handle the rest.

if (myval != correctval) {

    try { throw "incorrect myval: "+myval; }

    catch(e) { vexi.log.info(e); } // that's it!

}

// and the script continues uninterrupted

It is as easy as that. ;-)

Understanding Event Processing

2007-07-27T18:02:00.000-07:00

Understanding how events are propogated throughout the box model can enable you to pull off a lot of neat tricks when implementing more complicated widgets and user interfaces. This basic template is an interactive demonstration. Add extra traps (blocking and non-blocking) to understand exactly how traps and events work together.

<vexi xmlns:ui="vexi://ui">

    <ui:box tag="outer">

        vexi.ui.frame = thisbox;

        <ui:box id="innerbox" tag="inner" />

        

        var showTag = function(v) {

            vexi.log.info(trapee.tag+": "+trapname);

            cascade = v;

        };

        

        $innerbox.Press1 ++= showTag;

        $innerbox.KeyPressed ++= showTag;

        thisbox.Press1 ++= showTag;

        thisbox.KeyPressed ++= showTag;

        $innerbox._Press1 ++= showTag;

        $innerbox._KeyPressed ++= showTag;

        thisbox._Press1 ++= showTag;

        thisbox._KeyPressed ++= showTag;

        

    </ui:box>

</vexi>

Fortress

2007-07-20T03:39:00.000-07:00

Fortress is a castle building game written in Vexi which is in the early prototyping stages. The game is isometric so a full isometric display engine is being built in Vexi. This showcases the flexibility of Vexi as well as pushing it's performance, and may lead to a number of new features for Vexi as a platform.

Changing Themes

2007-07-11T14:59:00.000-07:00

I just made a change to the surface widget that makes theming really really easy should you want a custom widget theme.

<vexi xmlns:ui="vexi://ui" xmlns="vexi.widget">

    <ui:box theme=".path.to.custom.theme" />

    <surface />

    <ui:box>

        // your app starts here

        vexi.ui.frame = thisbox;

    </ui:box>

</vexi>

If you omit the box declaring your theme, vexi.widget.surface will apply a default theme for you. Nice and simple and no hardcoding - and it even opens the door for individual themes per surface with some more clever updates to vexi.widget.surface and the core.

For the curious, the way vexi.widget.surface automatically handles the theming is rather straightforward. If the theme attribute is defined, it applies to as a trap to the namespace vexi.theme, if not it just applies a default theme to that namespace:

// no theme has been specified by the user

if (thisbox.theme == null)

    theme = vexi..org.vexi.theme.win2k;

// set up the theme

vexi..vexi.theme ++= theme;

// apply the theme surface template

vexi..vexi.theme.surface(thisbox);

Fairly easy, eh? The downside is that you must apply vexi.widget.surface for theming to work but the reality is that few (if any) of the widgets will work without it being applied to the root boxes of your applications.

The Children Trap

2007-07-08T12:40:00.000-07:00

New to Vexi3 is the Children property. It replaces the previous notion of ChildAdded and ChildRemoved events, which were rather weak. Now we can completely control how boxes enter and leave as children of a box or template by placing read and write traps on it's Children property. As ever, an example is the best way to show off how this works.

Let's create a basic grid widget. Grids were removed from the core in Vexi2, so this is a useful example - although simplified - of how they are being replaced.

First the basic template structure:

<vexi xmlns:ui="vexi://ui">

    <ui:box>

        <ui:box id="grid" orient="vertical" />

        

        // JS to go here

        

    </ui:box/>

</vexi>

We have to have an inner box - $grid - because we are adding/removing containing rows so this keeps that logic simple, that is we do not have to consider rows in our Children write and read traps. Also $grid has a vertical orient because it is more common to work in rows before columns.

Let's start with the Children write trap which is fired every time thisbox[index] is put to:

thisbox.Children ++= function(v) {

    var i = arguments.trapname;

    var c = i%numcols;

    var r = vexi.math.floor(i/numcols);

    if (i+1 > total) total = i+1;

    while (r > $grid.numchildren - 1)

        $grid[$grid.numchildren] = vexi.box;

    var row = $grid[r];

    while (numcols > row.numchildren - 1) {

        var b = vexi.box;

        b.layout = "absolute";

        row[row.numchildren] = b;

    }

    // remove previous occupant

    if ($grid[r][c][0])

        $grid[r][c][0] = null;

    if (v) $grid[r][c][0] = v;

    return;

}

A few things to notice from the above code:

The index is passed as arguments.trapname
The child (or null if we are removing a child) is passed as the argument to the function
We return at the end because we have already handled the child placement and do not want the core to place the child in the box on which we are trapping
This handles non-null puts to an index with existing child in a different way than the core - the core inserts the new child, whereas this example overwrites the old child with the new one
We are using absolute layout for the cells here to keep the example simple - if we use a packed layout then the columns are not guarranteed to line up if the content size of any cell is significant

So, now we are handling the destination of child boxes of this template, we want to be able to also control how children are accessed as well. So we place a read trap on the Children property:

thisbox.Children ++= function() {

    var i = arguments.trapname;

    var c = i%numcols;

    var r = vexi.math.floor(i/numcols);

    // if the $grid[r] exists so does $grid[r][c]

    if ($grid[r]) return $grid[r][c][0];

    // otherwise we are out of grid bounds

    return null;

}

Simple enough, eh?

Vexi Blog Revival

2007-07-07T05:52:00.000-07:00

There are too many cool Vexi developments to keep this thing closed, so it's coming back. I'm going to be blocking about all the cool things going on around Vexi and lots of cool tricks you can do in it. Look out for more posts in the near future on vexi.blogspot.com! :-D

Vexi website migrates to Wordpress

2007-03-08T08:10:00.000-08:00

The Vexi website has been migrated to Wordpress. That kinda removes the need for this blog which I will leave purely for archival purposes or in case I want to post things that don't belong on the Vexi website but are related to Vexi.

Go there: http://vexi.sourceforge.net/

Vexi2 in Full Flow

2007-01-04T04:56:00.000-08:00

It's going well. Mike and I are just smoothing over any remaining rough edges. Documentation and demos are online although a bit more sparse than is desirable. Now it's just a case of convincing people to use it.

Anyway check out the Sourceforge website which is holding everything at the moment:

http://sourceforge.net/projects/vexi

Vexi2 Ready

2006-09-23T07:40:00.001-07:00

Well Vexi2 is pretty much ready. There's just the demo to put up, more documentation, and a bit of profiling to do.

Of course then the real challenge, the native builds, is up next.

Web Terminal

2006-09-17T13:16:00.000-07:00

OSNews mentions an "AJAX operating system" called AtomicOS. I wasn't very impressed with their version of a terminal, especially when there is a far superior implementation - the JS/UIX terminal which feels much more like a real terminal.

Most AJAX / Web 2.0 applications really don't impress me. If they did I wouldn't be working on Vexi. HTML is a documentation tool, at best a presentation tool. As nice as applications like GMail have become, they'll never be able to match real GUI applications.

The Future of RIA?

2006-09-12T18:10:00.000-07:00

RIA being Rich Internet Applications. Slashdot is carrying some story linking to an article on the future of them. It covers some of the higher profile competing technologies to Vexi.

I wouldn't be working on Vexi if I didn't believe in it. With Mike having done wonders with Vexi2, and me getting my act together on the docs, widgets, and demo, we're in a good position to really push Vexi. We'll see if we can make an impact in the coming year.

The last real key to making Vexi happen is the native launcher and builds. That's where the real expertise comes in though. An activex launcher and Windows build won't happen overnight. I need to start doing some research!

First Vexi Post...

2006-09-12T15:24:00.000-07:00

Well it falls upon me to update the Vexi demo. It's been hanging over my head for what seems like an eternity and I have procrastinated magnificently, but today I started doing.

First up was a clean up of the "text" demo tab and now it's nice and clean. Next up is cleaning up the "other" demo tab which shows off a few of the other widgets.

After that it's emailing Mike to coerce him into posting here too!