New Umeta Update-- 071021 (Undoable Threaded Binary Trees)

I finished more code for undoable threaded binary trees. Hopefully, I'm getting close to wrapping this up. It seems like I've been working on nothing but trees for a while now. At the same time, the code does show how general a language JUndo is becoming (assuming anybody is reading it).

Microsoft .NET AJAX ad is Blocking Downloads for JUndo Runtime

I just tried to move a file across using the JUndo Runtime download, and there is an advertisement for Microsoft .NET AJAX on the the download page that is blocking access to the direct download link (it is visually extending outside its bounds and covering the link). Meanwhile the automatic download refuses to proceed. Thus, the Microsoft ad is effectively preventing the JUndo Runtime from being downloaded on Sourceforge. The workaround is to view source on the page, and then use the link tag in the source to manually build the HTTP location for direct download. Thank you, Microsoft.

Update: It's clearly visible when I use the Safari browser. The link for "direct" downloads is on the left of the Sourceforge download page for JUndo Runtime, and the Microsoft ad is on the far right of the page. The ad extends its region all the way to the left (while remaining visually transparent) so that when you click on the direct download link the click activation is taken by the Microsoft ad. Hence, one's mouse click is usurped by the Microsoft ad, and never goes to activate the link. Clicking the area of the link clearly highlights the ad instead.

New Umeta Update-- 071014 (Undoable Threaded Binary Trees)

I put a new Umeta update on Sourceforge for undoable threaded binary trees. I'm trying to get the threaded trees finished as fast as possible so I can start using them in some practical applications. More later.

Binary Tree Traversals in Umeta

I just finished a draft version of the traversal code for the LowLevelBinTree class in the Umeta Sourceforge package of the Jundo Runtime, although I may revise it later.

One change I made in Umeta is that the Callback class from Meta isn't in Umeta and never will be. Umeta uses a different (Jundo-specific) design pattern for traversals. Here is the reasoning. In typical procedural code, a routine traverses a data structure such as a tree, and performs a "visit" on each traversed node. Hence, the logical thing to do is to provide a callback for each visit.

Hence, the typical Java code for using the traversal would be as follows:

Callback x = [Your callback here];
myDataStructure.someTraversal( x );

with the presumption that x would be called on each visit. JUndo provides a select expression syntax that doesn't exist in Java. In JUndo, it makes more sense to take advantage of the selection functionality rather than use a callback. The JUndo equivalent would be as follows (in a seq block):

IteratorFactory fac = myDataStructure.someTraversal();
IteratorFactory fac2 = select [Your callback here] from a : fac where true fi;
Iterator itf = ( fac2.iterator() ).cobj;
IteratorUtils.getLastItem( itf );

The advantage is that more possibilities are available. For instance, the select expression can be changed to:

IteratorFactory fac2 = select [Your callback here] from a : fac where [your condition here] fi;

One can apply arbitrary filters to the traversal, and this provides the ability to traverse a subset of a structure's elements. It's also possible to quantify over more than one IteratorFactory. For instance, one could perform a join between two different traversals. Imagine having a callback that gets invoked when items from two different structures match respective conditions as follows:

IteratorFactory fac2 = select [Your callback here] from a : faca , b : facb where [your condition here] fi;

Your callback and condition code gets access to both "a" and "b" in the select! This has a potentially limitless set of creative uses.

Sun Promotes JavaFX's Declarative Semantics

About a year ago at the last Pikes Peak Java Developer Group (PPJDG) meeting, several people responded as if I was crazy when I spoke about the advantages of declarative languages in relation to JUndo (JUndo has been a declarative language from the beginning). Now more people seem to be getting on the declarative language bandwagon, including Sun Microsystems. John O'Connor has an article on Sun's web site about the declarative nature of the new JavaFX scripting language:


http://java.sun.com/developer/technicalArticles/scripting/javafx/lc/part2/


The similarities and differences between JUndo and JavaFX are interesting. JavaFX provides a declarative user interface to a web application, which presumably has either a server-side file store or a server-side RDBMS as its data model. So one could think of it as a declarative user interface for a mostly imperative data model. JUndo provides a declarative data model that is then wrapped with a imperative Swing interface as part of a Verdantium component. That is to say, the two technologies are opposites in this sense.

JavaFX is a potentially important language, and one that will probably influence other declarative languages in the future. Will GUI code becomes declarative in the future? Perhaps. Only time will tell.

Started Adding Binary Tree Code to Umeta package of JUndo Runtime

I've found threaded binary trees to be a useful data structure on several occasions. That is one of the reasons why they exist in the Meta project. However, I have realized that there is a need for a binary tree that is undoable. That is to say, modifications to the tree can be reversed upon user request. To facilitate this, I have started adding undoable binary tree classes to the Umeta package of the JUndo Runtime Sourceforge project. The code is still in an incomplete state, and it will take some time to get the (non-undoable) Java fully converted to (undoable) JUndo. Once the tree classes are complete, I plan to use them in some Verdantium demo code.

One thing to notice is that the erasure patterns in methods pruneLeft() and eraseAll() differ from those in LowLevelBinTree in the Meta project. In the Java Meta code, pointers had to be assigned so that the identity of the next node would be picked up before the node was disconnected (disconnection deletes this information from the node by setting the node references to null). This creates some code that is tricky and hard to follow. It uses the temporary pointers in some rather complex ways. In addition, the technique for using the temporary pointers varies depending on the data structure. For instance, lists and trees require different temporary pointer techniques.

The new JUndo code for LowLevelBinTree uses a completely different paradigm in pruneLeft() and eraseAll(). The JUndo code traverses the structure in one time stream and disconnects the nodes in a different time stream. In the traversal time stream, the nodes aren't disconnected and hence there is no reason to build temporary traversal pointers such as delTemp. However, the nodes still get disconnected in the other time stream. The disconnection time stream's final milieu is the one that gets returned by the erasure method. This pattern for using multiple time streams makes deletions simpler and more consistent across data structures.