blank?

XPath for GWT

2009-08-25T10:51:00.000-07:00

Node selection in XML on the client
As an AJAX toolkit Google Web Toolkit is supports retrieving XML documents from the server, and supplies an XML parser to obtain information from those documents. However, using the DOM to navigate the XML tree can be annoying. Some sort of selection functionality would be useful.

GWT provides an XML parser, but does not provide an XPath selection API. However, most browsers implement XPath selection. Searching for an XPath library for GWT turns up jaxen4gwt and XSLTForGWT. jaxen4gwt seems to be incomplete and is not a wrapper around the browser implementation. This means that it will have relatively poor performance ( see Eric Bessette's XSLTForGWT blog post ) compared to a browser native XPath implementation. XSLTForGWT instead wraps the Sarissa Javascript library in GWT. Sarissa in turn wraps the native XPath implementations ( with XSLT as a bonus ).

The Problem
Sarissa is successful at wrapping *most* oddities among the browsers, by requiring some extra configuration for IE (from the HOWTO):

Actually IE also needs the proprietary setProperty method for it's XPath implementation to work.

To demonstrate:

oDomDoc.setProperty("SelectionLanguage", "XPath");
oDomDoc.setProperty("SelectionNamespaces",
"xmlns:xhtml='http://www.w3.org/1999/xhtml'");

The namespaces used in the XPath query must be declared prior to executing the query. These functions are no-ops for other browsers, resulting in cross-browser support. The HOWTO continues:

Mozilla does not need any of the above. DOM L3 XPath is always available and namespaces are resolved err... automatically.

This is not quite true. If the namespaces are declared inside the XML in the root node Mozilla will resolve them automatically. However, if a namespace is declared in a lower scope and is used in the XPath query, the following cryptic error appears in the Javascript console:

Error: uncaught exception: [Exception... "An attempt was made to create or change an object in a way which is incorrect with regard to namespaces" code: "14" nsresult: "0x8053000e (NS_ERROR_DOM_NAMESPACE_ERR)" location: "sarissa_ieemu_xpath.js Line: 159"]

Namespace used in query that are auto-detected by Mozilla:

<exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist"   xmlns:tei="http://www.tei-c.org/ns/1.0">
<tei:test></tei:test>
</exist:result>

Searching for "/exist:result/tei:test" correctly returns the single node "tei:test". However, in the following case, the very same query will result in an error on the console.

<exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist">
<tei:test xmlns:tei="http://www.tei-c.org/ns/1.0"></tei:test>
</exist:result>

An XPath query on the above XML that uses namespace "tei" results in cryptic error NS_ERROR_DOM_NAMESPACE_ERR.

Solution

Turns out, Mozilla provides similar functionality to IE's "SelectionNamespaces" property, and this is wrapped in Sarissa.setXpathNamespaces() and works in a similar manner as IE. However, the Sarissa documentation seems to incorrectly indicate that it is unnecessary except when the "document features a default namespace", because "moz will rezolve non-default namespaces by itself". Using this function to explicitly define the namespaces fixes the error and returns the result of the selection.

I therefore modified the Eric Bessette's GWT wrapper library to take an string of namespaces to be used, and use the setXpathNamespaces() function (which seems to cover for IE's "SelectionNamespaces" property as well).

Alternative Methods of Selection
Aside from using XPath, there are other selection/querying methods I considered.

GWTQuery
While researching selection solutions, I considered using GWTQuery. GWTQuery is a neat library which mimics jQuery syntax for selection. Incidentally, it uses XPath where available. Unfortanately it is made for HTML and doesn't seem to support XML too well.

JsonML
I also considered converting the XML to JsonML. There are two forms of JsonML ( http://en.wikipedia.org/wiki/JsonML#Syntax, http://tech.groups.yahoo.com/group/json/message/1115 ): Array Form and the Object Form. Unfortunately, I found that selection in Array Form is still tedious, as the first two elements might be the tag name and a dictionary of the attributes, but, if there are no attributes, then the second element is already a node. This makes iterator through nodes just as tedious as using the DOM! At the very least, keep an empty dictionary for the attributes, so that I don't have to test every node to see if the second array element is a dictionary ( and thus an attribute ) or an element. Object Form is more explicit, keeping the attributes as a dictionary, and reserving the attributes "tagName" and "childNodes" to contain the name of the node, and an array of the child nodes respectively. In my opinion, a better solution would be that each node should be a dictionary, a tagName entry containing the name of the node, an attribute entry containing a dictionary of attributes, and a childNodes entry, containing an array of children. An example:

{ "tagName": "person",
"attributes":{
"created": "2006-11-11T19:23",
"modified": "2006-12-31T23:59"
}
"childNodes": [
{"tagName": "firstName", "attributes":{}, "childNodes" : ["Robert"]},
{"tagName": "lastName", "attributes":{}, "childNodes" : ["Smith"]},
{"tagName": "address", "attributes":{"type":"home"}, "childNodes" : [
{"tagName": "street", "attributes":{}, "childNodes" : ["12345 Sixth Ave"]},
{"tagName": "city", "attributes":{}, "childNodes" : ["Anytown"]},
{"tagName": "state", "attributes":{}, "childNodes" : ["CA"]},
{"tagName": "postalCode", "attributes":{}, "childNodes" : ["98765-4321"]},
]}
]}

Conclusion
JsonML has the added advantage that all of the processing can be done on the server side (using the handy XSLT transform provided), and I might yet switch to using a modified version of it in the future. It is still good to have XPath support in GWT through Sarissa though. Though Sarissa seems not to be active, it uses feature sniffing, and should thus continue to work in any browser that remains backwards compatible. If GWTQuery gets better support for XML, I would probably use it in conjunction with both of them.

Reinitializing references in C++?

2009-08-21T00:54:00.000-07:00

C++ references are aliases for the value they are initialized with. Once initialized, there is no way to "reseat" the reference to alias a different object or primitive. Right?

Almost. There is a special case that I thought of that allows a reference to be reseated.

Warning: the following is not recommended practice, just theoretical discussion. Don't do this unless you know exactly what you are doing. Really.

The Problem
First, suppose you have a class with a member reference:

class some_object{

public:

some_object( int& some_int )

: some_reference( some_int )

{ }

int& some_reference;

//...

};

Then you can write code as follows:

int a = 10;

int b = 15;

some_object obj1( a );

some_object obj2( b );

some_object obj3( obj2 );

But attempting to do assignment will result in an error:

obj2 = obj1;

GCC gives:

error: non-static reference member `int&some_object::some_reference', can't use default assignment operator

Attempting to supply an assignment operator won't help:

some_object& operator=( const some_object& other ) {

some_reference = other.some_reference;

return *this;

}

Since assignment operators do not have initialization lists, there is no way to "reinitialize" the reference. Therefore, this function will not "reseat" the reference, instead assigning the value of the integer to the other.

An odd C++ idiom
There is an ugly way to almost automatically implement the assignment operator for any class. I figured this out myself in an "Advanced OOP in C++" course, in a Eureka moment. It is also critiqued by Guru of the Week at http://www.gotw.ca/gotw/023.htm. The basic premise is that a quick and (very) dirty way to implement the assignment operator is as follows ( include <new>):

some_object& operator=( const some_object& other ) {

if ( this != &other ) {

this->~some_object();

new ( this ) some_object( other );

}

return *this;

}

Going through this line-by-line

Make sure that the object is not being assigned to itself
Call the destructor on this object
Reconstruct the object, in-place using the copy-constructor ( the default copy-constructor in this case, but any copy constructor can work ), copying the other object
Return a reference to this object

Placement new, as being used here, constructs an object at a specified point in memory. Since the object called its own destructor, that memory is now free, and thus we are free to call placement new, to reconstruct the object on its old memory location. The fascinating thing that occurs, is that the member reference is copied as well ( "reseated" )!

Re-seating or Recreating

Is this really re-seating? After researching this online I found a few discussions around about this "technique". Some argue that this is indeed re-seating, while others say this is recreating the object in-place. Well its obviously both! By recreating the object in-place, an observer outside the assignment operator will assume the reference was re-seated. The method in which the reference was re-seated, is as we know, by destroying and recreating the object.

GWT and regular expressions

2009-08-20T18:41:00.000-07:00

I am working on a transcription framework for the Open Siddur/Jewish Liturgy projects. The framework is being developed as a web application using Google Web Toolkit, which allows me not to worry about writing cross browser Javascript. GWT compiles Java to optimized Javascript and provides a widget framework for making nice web applications.

The project uses the eXist XML database to server and query the data. Some of the data is pointed to by relative URIs, and I needed to resolve those URIs to request the new data.

GWT provides a subset of the JRE, which does not include java.net.URI. GWT does not provide a method to resolve relative URIs AFAIK, and so I decided to implement java.net.URI. Checking up here I found that java's URI doesn't implement the latest specification (rfc3986 AFAIK). So I looked up rfc3986 and found the nifty regular expression that can parse and validate URIs correctly. So now it was simple, right? Just use java.util.regex.Pattern. But of course GWT's subset of the JRE does not include Pattern. So I hunted down a partial Pattern implementation for GWT and found one by Robert Hansen over at http://java2s.com/. Robert's library wraps the Javascript regular expresion implementation.

So now comes the tricky part. Worked fine in Firefox, but as usual there was a problem with IE. This is because the regular expression requires "Non-Participating Groups", and are supposed to return undefined values for a group that aren't there.

From http://tools.ietf.org/html/rfc3986#appendix-B:

      ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
       12            3  4          5       6  7        8 9

      http://www.ics.uci.edu/pub/ietf/uri/#Related

    results in the following subexpression matches:
      $1 = http:
      $2 = http
      $3 = //www.ics.uci.edu
      $4 = www.ics.uci.edu
      $5 = /pub/ietf/uri/
      $6 = <undefined>
      $7 = <undefined>
      $8 = #Related
      $9 = Related

Instead of undefined values, IE returns empty strings, making it impossible to differentiate between an empty value, and a non-existant value. Turns out regular expressions are altogether a mess among the browsers, and not IE alone. Well, this made easy, standard compliant parsing a whole lot harder.

To the rescue comes XRegExp a Javascript library that wraps, fixes and adds functionality to the major browsers' regular expression implementations. So I include the source file in my project, do some manual coding, testing to see if IE returnes the correct values, and lo! it does!

So I run the application again, but no go. It just doesn't work. I spent hours compiling, debugging (it only bugs in IE, so I had to get IE8 for its debugger), recompiling, stepping through, reading through the XRegExp source code, and then GWT's generated source code (not the easiest to read). What XRegExp does to fix the browser's functionality, is to override the String.match() function to its own match() function. For some reason, XRegExp's match() function wasn't getting called at all. I looked at the prototype of String, and it did not point to XRegExp's match(). I finally realized that all of GWT's generated Javascript is executed inside a child frame, and XRegExp only changes the String prototype of the top level frame, resulting in the same output as before.

So I asked for possible solutions to the problem on ##gwt, and was told that all functions that require access to the top-level window should use $wnd to access it. So I fiddled around for awhile and managed to create a create a (deep) copy of the string with the correct prototype and get the match result.

var result = new $wnd.String(text).match(new $wnd.RegExp(regExp));

It was then just a matter of implementing Reference Resolution (http://tools.ietf.org/html/rfc3986#section-5), which I mostly completed, finally being able to resolve relative URIs on the client.

Stack trace from within a program

2008-12-06T22:34:00.000-08:00

Ever coding and want to be able get a stack trace at runtime? Edd Dawson's stack trace source, here, bundles this functionality nicely with C++ with cross-platform support. The MSVC source uses imagehlp.dll or dbghelp.dll to obtain the trace and decipher the addresses to symbol names. GCC/MinGW doesn't produce PDB files which contain the symbol names, which makes it impossible to use dbghelp for the stack trace. To solve this, I have attempted to compile Wine's dbghelp.dll for Windows. Wine's dbghelp.dll is able to interpret dwarf and stabs debugging information, which are produced by GCC/MinGW, and Wine's uses the LGPL license, allowing it to be used in more liberally licensed projects. I started a project on SourceForge to host the code ( basically a makefile to download Wine's source, and compile dbghelp.dll using some modified source files ).

Alchemy and LLVM

2008-11-27T14:17:00.001-08:00

I've just tried Adobe Alchemy, a preview tool that uses LLVM to compile C++ to actionscript. It still has some touching up to do ( see my posts here and here and my experience with alchemy ), but it is very promising. There is even someone working on porting Doom to flash ( here ). This finally opens the door to truly portable binary files. One can now distribute C/C++ applications to anyone as swf files, without requiring the user to compile them. Now we can really have a web-based OS ;) ( kidding ).

Truth is, I've always disapproved of flash, because it seemed to encourage a less semantic web, with many sites just filled with bloated flash. A nice clean web page, with a fallback for no javascript is the way it should be :). But now I just look at flash as another virtual machine, and it can be targeted by LLVM. And so I approve. All we need now is an LLVM JIT implementation of the flash player ;). While your at it, throw in an Actionscript front-end to LLVM.

I hope LLVM grows much more, and solves all of the worlds problems. What will LLVM look like in 5 years? Front-ends, back-ends, optimizations, JIT, etc., I don't see the limit.