Older blog entries for rmathew (starting at number 110)

PGP Public Key
I now have my own PGP Public Key (Key Identifier: 6C114B8F, Key Fingerprint: D6E5 B9C2 5522 ED3D 09DC 3B40 61BD 61C7 6C11 4B8F) that I will try to use with my email messages. Of course, this will not work with the web interfaces provided by Gmail and Hotmail, but it works nicely with Thunderbird using the Enigmail extension. I have published this key to a couple of keyservers. I do not foresee being able to participate in a Free Software hackers' key-signing party any time soon, but I have signed the keys from Mark Wielaard, Michael Koch and Andrew Haley for whatever it is worth.

More on WFL Nodes
I found the original patch from Jeff Law that removed WFL nodes from the rest of GCC and includes an analysis of why WFL nodes are bad. Note in particular his analysis of the Java front-end, where 30% of all generated tree nodes are EWFL nodes! WFL nodes are thus a waste of space and time, not to mention a source of unnecessarily-added complexity in the front-end that ultimately only frustrates hackers. So I repeat my war cry, "Death to WFL nodes"!

By the way, GCJ already gets the column numbers pretty wrong on almost all diagnostics, so it's not as if we lose much by losing EWFL nodes.

n Factor
I just found out that my blog (as well as those of many GCJ/Classpath hackers) is also being aggregated by n Factor besides Planet Classpath.

EXPR_WITH_FILE_LOCATION
I hate EWFL tree nodes in GCJ. So many of the ICEs (internal compiler errors) I have seen in GCJ are because some piece of code expects or doesn't expect an EWFL node. To put it simply, the current front-end wants a WFL-wrapped expression node whenever there is a need to emit a warning or an error about that expression, but not otherwise.

This can easily frustrate anyone wishing to fix some of these ICEs in the hopes of making GCJ better. For example, here I am discovering that many ICEs in the Jacks testsuite are because the body of an empty block ({}) or statement is not being wrapped in an EWFL for diagnostics about unreachable statements, finding that it is trivially fixed and then discovering that doing this creates a whole mess of new ICEs on other tests, which have to be individually addressed in this manner potentially creating yet other ICEs in other places, ad nauseum.

To quote Jeff Law (gcc/ChangeLog.tree-ssa), "Death to WFL nodes"!

GNU Classpath Copyright Assignment
My copyright assignment papers for GNU Classpath were cleared by the FSF today.

R.I.P.: Old Bytecode Verifier
The old bytecode verifier used by the GCJ compiler has now finally been removed. It was a small and straightforward verifier but had a few bugs that made it difficult to use GCJ with random JARs. At the same time, the newer bytecode verifier (written in C++) used by the GCJ interpreter gij had far fewer bugs and could handle almost all JARs found in the wild. Since no one was fixing the bugs in the old verifier, GCJ could not work with many JARs for a long time and thus was unusable for a large number of potential users. Bryce made the new bytecode verifier work with the GCJ compiler to support the work on the new Binary Compatibility ABI. After some time I made the new verifier the default for even the old C++ ABI.

I feel guilty and sad now because once upon a time I had resolved to fix some of these bugs but never actually got around to fixing them. I had studied the source code and had read several papers on bytecode verification, especially some of the excellent ones by Alessandro Coglio, but never implemented any of the techniques. Not good.

Scratching An Itch: Terry Laurenzo, GCJ and Generics
One of the stumbling blocks in supporting generics in native programs created by GCJ is the fact that the C++ method-name-mangling used by GCJ does not encode the return type of the method and thus cannot support the Java 1.5 kludge for implementing generics (PR9861).

Terry was just another bloke who was trying to make his program work with GCJ when he hit this issue. Unlike most other blokes however, he has decided to do something about it. Cool!

Sabbatical
VikGup takes a sabbatical for three months starting next week. I really envy him and I wish I could do the same.

Sabbaticals might be quite common in the west, but here in India they are very rare. Even when people want to take sabbaticals, many a time they are discouraged. I hope more people take off on sabbaticals like VikGup has done so that employers and family realise that it is OK, and actually quite healthy, to take a sabbatical.

Have fun VikGup!

PS: Is Mohan back?

McCarthy-ism
I have been meaning to check out Lisp (or one of its dialects) for a very long time now. I first came across functional languages (via Standard ML) when we studied Principles of Programming Languages (PoPL) at college. PoPL was also responsible for introducing us to declarative programming (via Prolog). I found these two styles of programming very difficult to grasp as I had been programming with imperative languages (BASIC, Pascal and C) for around 4 years by then. The unfortunate part was that by the time we "got it", the semester was over and we moved on to other things. I told myself at that time that I would learn Lisp and Prolog on my own "soon".

Almost eleven years have passed since then and I still have not come around to actually learning these languages and the programming styles associated with them. Lisp at least keeps appearing on my radar every now and then. The urge to learn it becomes particularly strong when I read about the ravings of the early oldskool hackers in Steven Levy's "Hackers" or one of Paul Graham's articles on Lisp or SICP. Tromey's recent blog entries have once again aroused my interest in Lisp.

Instead of continuing to procrastinate, I want to start learning Lisp now. I think I would start by reading "Practical Common Lisp". I also hope to be able to understand the origins of Lisp by reading John McCarthy's original paper on Lisp. I hope to be able to overcome my revulsion for seeing so many parantheses in even the most trivial of programs.

GoF Honoured by ACM SIGPLAN
The authors of "Design Patterns" have been honoured by ACM SIGPLAN this year with the "Programming Languages Achievement Award". I personally think that this award is justly deserved. Their book has had a strong influence on the way I approach designing a program. I would gladly recommend this book to any programmer - you do yourself a disservice if you haven't read this book yet, for whatever reason.

Unfortunately, I see either a rampant abuse of Design Patterns ("Let's see how many design patterns we can fit into our design for this project") or a refusal to accept that they can have any merit besides being useful in impressing your PHB. Whether by diktat or by choice, if you are trying to come up with an object-oriented design for a project, it helps tremendously to know how other people have solved some of the specific problems in a way that allows the design to remain flexible while solving the immediate constraints. The flexibilities are precisely what come in handy in the face of ever-changing requirements. A secondary benefit is being able to use a common vocabulary to describe parts of your design to others, who can then immediately grasp what you are trying to do.

Prelinking
I have now become yet another fan of pre-linking. It works wonders on the startup times of most applications. Many thanks to Jakub Jelinek for creating prelink for Linux.