-k.

Occasionally I like to dabble with parser generators. Today I came across VisualLangLab which claims to be a Visual IDE-Style LL(k) Parser Generator that uses an editable tree with icons for tokens and non-terminals to represent the grammar symbols and grammar rules.

The tool is completely interactive. Errors in the grammar are indicated by adorning the affected icons as the rule-tree is edited, and the generated parser code is displayed in an adjacent pane so the effect of edits on the rule-tree can be immediately verified.

The visual tree representation of grammar rules completely eliminates the need to use and understand cryptic specifications as used in YACC, ANTLR and JavaCC. The grammar is saved to (and read from) data files using pure-Java mechanisms.

The built-in scanner can also be customized for the application via the GUI.

Now I just need to find a reason to try it out

The first public release of Necessitas is now available.

Necessitas is an Eclipse plug-in that adds a class-path container to manage a projects jars using the ivy dependency manager. In short it gives you many of the advantages of ivy without leaving eclipse.

What it does now

• Downloads the declared dependencies to the ivy cache
• Adds the downloaded jars to your class-path
• Can be configured to update the jars each time the ivy.xml file is updated

Still to come

• The ability to specify an ivy config file to use
• The ability to specify the module configuration to use
• Maybe, the ability to automatically download and associate source files

I’ve found a couple of issues in the way that ivy exposes information about what is in the cache, what it needs to download etc. None of these are irresolvable they will just take some time and co-operation with the ivy crew (who are very responsive)

You can download it via the eclipse update manager from http://eclipse.oneill.id.au/updates/

Generating logging information from the eclipse framework is pretty straight forward. Create an .options file and start eclipse with: eclipse -debug <path to your .options file> -vm <path to your jre>\bin\java. The debug information will be written to the console.

For example an .options file with the following contents would log information on the JDT builders:

org.eclipse.jdt.core/debug=true
org.eclipse.jdt.core/debug/builder=true

Over the last couple of nights I’ve been working to shore up the jacket javadoc and started writing a short introduction / tutorial. I plan to release a new version early next week.

I’m interested in getting peoples opinions on what to do with the fault detail node. At the moment it’s ignored but obviously this can’t go on forever. My initial thought has been to store the StAX events for the node and allow you to access the information via an event reader. What do you think? What features are you looking for?

As a side note I’ve just created a mailing list for those interested in jacket development.

XStream is one of those libraries that you keep asking yourself "what did I do before I used this?" (picocontainer is another one). It's smallish, clean and simple to use. More importatnly it has well defined extension points tht allow you to build additional, more specific code upon. Look for a jacket sample that take advantage of it "real soon now".