Archive for October, 2005

Frysk

I haven’t seen much hype for frysk, though it certainly
deserves some. (And, by the way, no, the “K.” mentioned on that page
is not Franz Kafka’s compiler-writing alter ego. Though, to be sure,
there are parallels between programming and The Castle.)

Having a programmable monitor and debug tool would be super handy.
There’s a kind of convergence here between tools like valgrind,
simulators, LLVM, and now frysk that is worth some investigation… it
is a rich period for execution tools, just as it is for
next-generation version control systems.

The other day I thought of an odd frysk application: sandboxing.
The idea is that you could run untrusted executable code under frysk.
frysk intercept system calls and force failures for those you want to
disallow. I picture it as being a bit like the java sandbox, where
you could configure the wrapper program to allow or disallow certain
events (allow X connections, disallow other network connections, allow
file reads, disallow writes outside of pwd, etc). The UI would be a
bit like valgrind: sandbox --whatever program arg arg.
Think of it as SELinux on the cheap.

Come to think of it, this would be very useful for testing as well
– you could easily do controlled failure of certain system calls;
e.g., inject EIO at certain points of the test.

Trying out KDE

I had a few frustrations with Gnome after upgrading my main
machine to FC4, so I’ve been giving KDE a try this week.

I have to say, amaroK is very
nice, the best music player I’ve tried. I find, to my surprise, that
I love all the weird little gui things they do. I don’t understand
why the panel part of it shows up in the notification area though; I’d
rather have a full set of player controls directly on the panel.

It also seems like the KDE panel is a bit more configurable — it
can act the
way the Gnome panel could before FC2
.

On the other hand, in some ways KDE seems less nice. The KDE
terminal doesn’t to turn URLs into links (that I can see). The KDE
panel sometimes moves applets around without my intervention (this one
seems to be a plain old bug). I had to install kbiff separately (the
whole point behind this exercise), and it is kind of clunky.

I was pleasantly surprised to find that the x-chat notification
thing I have also works in the KDE panel. I guess freedesktop.org is
earning its keep :-).

In general the two desktops feel pretty similar, much more than I
would have thought.

Anyway, I think I will switch back. I’m more used to gnome, and
now that I found out about mailnotify, my most
pressing irritation has gone away. I really wish Gnome had just
automatically run this applet for me instead of giving me a useless
error about the mailcheck applet going away. I literally went for a
couple of weeks thinking that they had simply dropped a useful applet
without providing a replacement. Foolish me, I guess, for not reading
the release notes; though honestly I think this easily falls into the
“just works” category. I usually put off upgrades because history has
taught me that in amongst the new goodies will be some unexplained
deletion of a feature I rely on. Upgrades are a fact of life,
handling them with some grace will make people happier.

Japi Update

A quick update on Classpath… a few days ago we hit 96%
of 1.4
without much fanfare. Seeing as we were at 92% just a
month ago… you do the math.

Of course, that is 1.4. How are we doing against 1.5, the target
that really matters these days? That is harder to say. Comparing
cvs head to 1.5
shows us at 87%, while comparing
the generics branch
shows us at 85%. These measure different
things, though — the latter includes generics information in its
comparison, but on the other hand the trunk tends to have fewer
missing methods (most development takes place there and merges to the
generics branch are relatively infrequent). I’ll take another look at
this after the next merge. Note also that one of the biggest “red”
chunks for 1.5, javax.management, is implemented by mx4j (at least, for the
purposes of folks who don’t mind mixing the Apache and Classpath
licenses).

Tools Matter

gcjx is a moderately-sized C++ program, 73,000 lines as counted by
wc. On this machine, even when taking advantage of g++’s
precompiled header feature, it takes 14 minutes to build.

By way of contrast, using jikes to build the 900,000 lines of java
code in Classpath takes 15 seconds on the same machine.

Now, in some ways this is not a fair comparison. Although I
compiled gcjx with -g and thus avoided many
optimizations, it is still more expensive to generate object code than
bytecode. Also, as plenty of people will tell you, C++ is a more
expressive language than Java, and so you should expect to pay for
that. Nevertheless we’re talking about a more than 650x slowdown for
using C++.

For me there is no question: the added power of C++ does not come
close to compensating for the time spent waiting for my builds to
complete. Some changes will introduce a 10 minute bubble into my
workflow — this has a noticeable effect on my concentration.

On the other hand, when working on Classpath and Mauve in Eclipse,
my changes are essentially ready immediately. For the last buglet I
worked on, I would simply work on the code in Classpath, or the test
case in Mauve, save my changes, and then, without pausing, switch
windows and run jamvm on the test.

I’m not really familiar enough with other C++ compilers on other
platforms to know where the fault for this lies — maybe other
compilers are a lot faster than g++. Though once you fix g++ you also
have to look at the linker, which seems to be another big time waster.

Naturally, tool performance is just one part of the whole
productivity story. That said, fast tools matter a lot, a lot more
than I used to think.

Lint

“Civilization is the agreement to have gaps between wars,” writes
Jeff Lint, subject of the biography Lint. This is an unusual
book that I picked up at the library on a whim. Parts of it are
outrageously funny, for instance the whole “Belly” sequence, Lint’s
cartoon TV show, and the description of his proposed Star Trek
episode. At the same time parts of this book disturbed in a way, as
though reading the description of someone unknowingly in the midst of
a mental breakdown, and then slowly realizing that, hey, maybe that is
me.

In any case, I think Aylett has achieved something remarkable
here, in that he was able to write a “writerly” book which did not
make me want to retch. While at times the relentless
other-worldliness and just-barely-incoherence of Lint was tiring, at
other points I was struck by the sustained creativity that was
required to have written this book — like a sci-fi version of The
Passion
, only not so deep. Several times I thought, “I wish I
had thought of that.”

I recommend reading this book, though I wouldn’t classify it as
an SF essential (say, The Female Man or so).

Oh, by the way, due to this book otters have now been added to the
list of animals which may no longer be used in jokes. You may
remember that penguins, platypuses, weasels, and newts are already on
this list.

gcjx marches on

Ranjit has
done some nice work on gcjx
recently, adding visitor methods to the model and writing code to
print the AST — in a lispy format, no less.

I’ve also been hard at work on gcjx. I set up a special install
tree so that I could test gcjx-compiled object code against a
known-to-work libgcj. This let me quickly find a number of bugs in
the tree-generation code. At this point most of the libgcj test cases
now work when compiled with the new front end.

This weekend I spent some time working on the type inference code,
and last night gcjx was able to compile its first generic method
invocation.

Qwest

Yesterday my DSL router suddenly and mysteriously stopped working.
After some futzing about, and a realization of the strange fact that
lack of internet access translates immediately into a sense of
isolation, I called Qwest. I was expecting an irritating hassle, but
instead they overnighted a new router to me. Thanks Qwest! I’m a
whole person again.