We Give and We Take

Nothing to Grouse About

2009-01-10T13:53:00.004-05:00

You'd think that when my mountain ash, which has been suffering at the hands (beaks?) of woodpeckers and bugs for the last ten years, is attacked by a marauding grouse, I would be upset.

Right?

Well, not when he looks so innocent:

Don't let this handsome fellow fool you, though. He's on a mission, and it's serious.

It's a raid!

The last thing this tree needs is to have those juicy, tasty leaf buds taken in the middle of Winter:

When I confronted him about it, this grouse didn't have much to say. He's excellent under pressure, well trained by whatever spy agency sent him into our country. He just sat there, challenging me with his cold, hard stare until I had to back down.

Makes me appreciate how trivial my daily struggle with certain complex software systems really is, in the big picture.

Old-Fashioned Prognostication

2009-01-02T11:18:00.004-05:00

No, I'm not making predictions for the success of Eclipse or any technology in 2009.

Another new year has arrived, and to usher it in I once again engaged in the timeless German tradition of Bleigießen: the divination of one's future (for the coming year) in the pouring of molten lead.

The idea is simple: you cut a length of lead solder and heat it, in a steel spoon, over a candle or other tabletop flame, thus:

Once the lead is completely molten and flows freely, you pour it quickly into a bowl of cold water to chill it instantly. In the resulting sculpture, you see a shape, figure, or other graphic indication of what the year holds in store for you (rather like cloud gazing):

As you can see, my first attempt didn't show much and was actually spoilt by pouring too rapidly. Am I having puppies? Or are these tears? As this attempt failed due to a bad pour, I tried again, with a smoother and steadier hand:

That's more like it. I can read something into this! I see ... on the right-hand side ... a frog? Yeah, a frog. It's sitting on a stick, readying to jump into the water. The stick is jutting out of the water from right to left, like in so many creek-paddle scenes from my canoe tripping.

Looks like Mother Nature has another great canoeing season in store for me!

Directions to Keyboard Heck

2008-12-22T09:48:00.006-05:00

Have you ever wondered where Keyboard Heck is to be found?

I think I just took the short-cut. So to speak.

I use the two-handed Dvorak keyboard layout because I like it:

I also use a MacBook Pro because I like it.

This week-end, I upgraded my OS X to version 10.5.6, because Apple told me it was a good idea.

Well, now text editing in the Eclipse workbench has gone all to pieces.

What has happened is that the following Mac-standard keystrokes still work as expected:

Command-Q to quit
Command-, for preferences
Command-W to close window (which closes the internal editor in Eclipse)
Command-S to save

but most others require combining the Command key with the letter key where it would appear on a Qwerty keyboard:

Command-; to undo (Dv ; is where Qw Z is)
Command-R for an outline (Dv R == Qw O)
Command-Shift-U to format (Dv U == Qw F)
Command-J to copy (Dv J == Qw C)
Command-K to paste (Dv K == Qw V)

The most frustrating point is that to cut (Command-X) I actually would have to hit Command-Q because the Dvorak Q is where the Qwerty X is, but Command-Q "works" in the Dvorak layout and closes my workbench! I have to do Command-J to copy, then delete, then Command-K somewhere else to paste.

I mustn't be as smart as Pavlov's dog, because I still find myself closing my workbench occasionally despite that it isn't the natural keystroke on this keyboard!

My next step was, when last I posted this message, to try this out on the Cocoa port of SWT. Well, it turns out that the Cocoa port does not have this problem. Keys all work like the rest of my Cocoa apps. The new problem is that Eclipse doesn't run, yet, with the Cocoa SWT. It crashed the first time I tried to save a Java editor and now it crashes before I can begin working with any editor, on every launch. That's no better than hitting Command-Q to cut ;-)

Target Definition to the Rescue!

2008-12-18T14:14:00.008-05:00

Congratulations to the PDE team for saving my day!

I just switched my day-job development from Windows to Linux. I use IBM Rational® Software Modeler™ every day for its various advanced features, and among other things the software that I develop extends some of its features. Therefore, I self-host my PDE.

As it happens, my software project also depends on other Eclipse-based components that are not included in RSM. So, I install them into my RSM workbench. On Windows, this works fine because I am an administrator of the system and p2 installs the stuff into the shared bundle pool.

However, on Linux, the picture turns out to be a very different one. I installed RSM as root but I run it as a regular user. It seems that some kind of funky extension to Equinox causes p2 to install my extra features into my home directory, and the launcher finds its configuration there instead of in the main product installation location. Very cool! Great for a multi-user environment.

However, not so great for my PDE target. PDE only recognizes the plug-in locations installed in the product, not this extra location in my home directory. Enter the PDE Target Definition.

drum roll ...

I use the New Target Definition wizard to create a new PDE target, and it creates one that includes my current Eclipse configuration by default. Then, I add another location in which it will find plug-ins. I could even, if I wanted to, add plug-ins from my workspace, although this seems odd because the workspace generally is implicitly in the target, anyhow.

With one click in the top right corner of the editor, this target is installed in my PDE environment and it now finds every plug-in that I need. It's too easy!

Who Knew? Comparing Directories in Eclipse

2008-12-10T18:40:00.001-05:00

Well, isn't that a pleasant surprise to follow a rather unpleasant one.

After having spent much of the day working on OSGi-bundle-izing Apache Batik 1.7 in the Eclipse Orbit project, I discovered that the re-distribution of the W3C CSS SAC 1.3 API that is included in Batik 1.7 is, in fact, the real original content as provided by W3C.

"Great!" you might say.

No. The reason I know this is that what I actually discovered is that the re-distribution of the SAC 1.3 library in Batik 1.6 was a modification of the original W3C code, that I had bundled in Orbit way back when. Mostly, the changes are either just in the CVS ID in the header comment (Apache and W3C both checked the sources into CVS) or fixing typos in the doc comments.

My heart sank when I saw that one class, the CSSException, actually had functional changes. A bunch of its code was removed by the Batik team. Ugh. So, now the Orbit bundle that for so long has been touted as "the" W3C CSS SAC 1.3 API in fact isn't, and I have to figure out what kind of version number to apply now to make the new bundle look like the real deal over the old one. The org.w3c.css.sac_1.3.0.v200803081811.jar bundle is not authentic.

Anyhow, the real point of this blog is not to complain but to congratulate the Eclipse Team Team (tee hee). I had always used BeyondCompare to diff directory structures, but I don't have it on my current system and I was impatient, so on a lark I thought "Hey, let's see if I can do Compare With -> Each Other..." on directories in Eclipse. Well, of course I can! That's how I found my little Batik/SAC conundrum:

I should know by now just to assume that Eclipse can do these things. Silly me.

Good work, Team people! This is one more task that I don't need to escape my cozy workbench for.

OCL: Who Cares?

2008-11-20T09:39:00.000-05:00

This week, the OCL 2.1 RTF has had to re-launch the voting on its first ballot, because it failed to reach a quorum. With a 10-member voting list, 2 votes just didn't cut it. And these were the two companies that put some effort into resurrecting this specification by addressing a substantial number of issues.

It's disappointing to see that there is so little interest from the OMG membership in the health of this specification that should, and I think was intended to be, a cornerstone of the the MOF architecture. There is still interest in the user community, judging by the continued influx of issue reports.

No metamodel is complete without constraints that specify the well-formedness of instance models. And OCL could be a key tool in that department, if it can keep up with the evolution of MOF and UML. Indeed, it already seems to be an important part of several Eclipse modeling technologies, as I hope to demonstrate at EclipseCon 2009. However, the current state of the specification makes the implementation of conformant tools difficult and interchange of OCL models impossible, because the language is imprecisely and inconsistently specified (some bits aren't really specified at all).

A few of us are working hard to reinvigorate and reform this specification, but we need help. With just two OMG members involved at this point, it is difficult even to get through a vote, and I worry about how relevant the product will be that results from such a small collaboration. So, pitch in with your time (it doesn't take much) and elbow-grease to make OCL succeed! Let's not let this thing go the way of the dodo.

And Now I Lay me Down to Sleep ...

2008-11-18T00:11:00.000-05:00

Well, it looks like it must be winter, because I see Orion high in the sky outside my window. I don't know how it is, but there is something comforting about the onset of this season, and those early nights when the great Hunter rises to watch over those of us that dwell in the northern hemisphere. I can almost feel his presence.

The fire in the grate dims, and even Tess has stopped purring and is huddling close for warmth. I ask myself, What have I done for her lately? Dished out a can of wet food, cleaned the litter pan, washed the water fountain. And what has she done for me? Only offered me the simple, unconditional, absolute affection of one of nature's most perfect animals. I feel that I have got the better part of this exchange.