My espresso cup...

...is ticking.

Space cadets

μ
The last two weeks I was space-caddetting to rewrite something at work: taking the existing code of an OA service (~45 klocs C++ math engine, ~55 klocs Java framework for UI, persistance, web services, ~100 klocs model-generated-java for data classes to feed the math (there's lots of junk to make the thing understand units, so for each value you end up storing the value, the units, and the value in SI so the simulation math works), ~100 klocs model-generated-JNI to hang them together) and capturing the C++ as UXF (more human precursor of XMI) + MathML, so all the model-specific code is generated from the XML model, and we can trim the JNI baggage. This is for a simulation and optimisation package for operational analysis.

λ
I think I'll see if I can either release the non-restricted parts, or update the kin system along a similar line; I certainly want SystemESP's MOF implementation to be compatible. It's relatively easy to get a decent math model out of MathML by using XSLT to transform it into Java. The question is can I get the reverse engineering aspect I've been using for my lighter-weight ASN persistance to hook into it; if so you can get nice persistance + object browser tool.

τ
Last weekend I got round to reading Cryptonomicon.

Need more sleep.

And to resist urge to join the SoJ.

Ω
Haven't heard from Malvern yet either, though MathWorks is advertising for senior Java engineer for visualisation. Unfortunately, that's in the USA, and I doubt they'd want a teleworker.


TME

Over the hills and far away

I went to a job interview in Malvern Thursday, as it's close to my sister and a nice area (I like my current job, but the place I live in is a bit flat). I don't think I'll get the job I applied for as I didn't see eye-to-eye with the manager for the project I'd be joining, but I spent the weekend with my sister and her family which was good.

TME

Real paper

Every now and then I get an urge to update a graphical editor I've had kicking around my drives for years, and sometimes start working on it again (actually most times I end up with a 99% re-write). Currently the working title is 'System Engineer's Sketch Pad', or 'SystemESP' for short.

Thing is, most of the notations I scribble in my sketch pad (A4 hardcover 150gsm acid free cartridge paper) aren't formal or semiformal things like Concept Graphs or UML, but are simple box-and-line graphs with locally defined semantics.

It's very hard to write a GUI that's as usable as paper, and very hard to find use cases that require machine capture of early design drafts. As I've got sketch pads going back over a decade (and occasionally refer to them), and the paper is acid free, but don't have any files that old, I'd also be worried about putting anything into a machine unless I had a very big gain that would outweigh the risk of information loss.

But it's fun tinkering with UML tools.

Hmm.

Maybe that explains a bit of the problems with the software industry. Everything seems to be going into two camps- the agile camp and the MDA camp.

The MDA have prettier tools, the Agile say make it work on paper.

So how about agile tools? The notation I was sketching with earlier was to do with the parser:

each box denotes a parser state.
if the box is to the right of another box, it means that box indicates the next state, which is chosen when the.
above or below indicate options. options shifted to the right are not chosen as often as those to the left

In the time it's taken to blog an example, I've almost written the CLCE specification for the notation, and I didn't even mean to.

That might be a better way to go than a 1200 page UML spec.


TME

PackRats

What I've been doing lately is a parser.

I don't like the idea that you have a write grammar-generate code-compile loop each time you want to add something to a grammar, and you have to rewrite grammars to suit parsers. There seems something wrong with a system that doesn't allow new rules at runtime, and means that you end up with several thousand lines of code for what should be a simple part of a tool.

Therefore I've been playing with something like the Pack Rat technique, but using a 2-3 tree for forward parsing and a stack for backtracking over possible terminals (this is to allow only one subtree- that found by the tree- to need to be stored, but have the capability of going back to previously not explored subtrees whitout such a large table of possible states).

There are three design aims-

1. to allow grammars that are simple mappings to abstract syntax


2. to allow the grammar to be extensible at runtime (allowing new abstract values for metadata constructs)


3. to allow the current parse state to be used for structure aware autocomplete

This is part of an on-going metadata driven toolset for Java programming.. more later.

TME

Begin

What is it all about, any way?

OK, begin at the beginning...
there was the logos and the logos was with god and the logos was god

no, not that one, try again...

I make tools. Tools are a big thing in my life. Some of my earliest memories are of my father teaching me to use wood working tools, as his mother's father had done for him, and father's fathers before him. They were tinkers, itinerant craftsmen working wood and soft metal, or sharpening tools.

Whilst my ancestors' tools were steel with ash handles, the tools I create are software.

But they still must have an edge, be small and light enough to be wieldy, and forgiving in the hand.

Tinkering is live and well in the 21st century.

And the tools we create are based on logic, and creating through the word.


TME