Older blog entries for rmathew (starting at number 115)

Madness
After "7/7", Britain seems to have gone bonkers just like the US did after "9/11". If you have access to the latest issue of The Economist, also read "Conference kick-out" in the "Britain" section. Sheesh!
Mauled in ICFPC 2005
Our entry in ICFPC 2005 was mauled by just the judges' cops! Looking at the playback of the robber's performance, I want to hide my head in shame.
Bangalore Computer Graphics Group
Anirban Deb, who is a colleague of mine, has started the Bangalore Computer Graphics Group along with like-minded enthusiasts, which aims to bring together people in Bangalore who are interested in computer graphics (not the Photoshop or Maya stuff). If you are interested in such things, or know of someone who is, spread the word. Their initial plan is to meet at least once a month to discuss interesting stuff and to get to know like-minded people and to eventually become the local SIGGRAPH chapter.

In other news, look who's blogging! Now that Andrew and Tom are blogging, Bryce is the only one in the Red Hat GCJ Triumvirate who doesn't. Who wants to persuade him to blog?

23 Sep 2005 (updated 23 Sep 2005 at 09:05 UTC) »
Miscellany
I have been granted write access to the CVS repositories of GNU Classpath and Mauve. I have also started messing with GCJX (again) that was started by Tom Tromey. It has come a long way since the last time I had taken a look, but it sure can use some help from willing hackers. Would you like to help develop a first-class Java compiler?

By the way, Tom has become one of the Java front-end maintainers for GCC.

13 Sep 2005 (updated 13 Sep 2005 at 17:59 UTC) »
C++ Madness
Compile the following program with "g++ -fno-implicit-templates foo.cpp" and admire the error message that you get. Just how is a mortal programmer supposed to make sense of this?

#include <string>
#include <map>

using namespace std;

int main( void)
{
  map<string,string> foo;
  return 0;
}

The example might look bogus, but consider this: you have been told that explicit template instantiations can some times considerably speed up your build process, not to mention save space used up by the object files, so you begin by creating an explicit instantiation file that you try to populate with template instantiations that are actually used by your program. You compile all other source files using "-fno-implicit-templates", but not the one special file. If you have not caught all template instantiations however, you will hit the monster of an error message that I sought to show per missing template instantiation. You are supposed to then figure out from these error messages which of the template instantiations you have missed out. Should anyone be surprised if you lose all hope at this point and just ditch the idea?

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.

106 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!