Older blog entries for rmathew (starting at number 141)

ECJ for GCJ?
Tom proposed killing GCJX and replacing it with the Eclipse compiler for Java (Eclipse JDT Core plug-in, known informally as ECJ). He has been almost single-handedly working on GCJX for more than a year and it looks pretty good already, so it is pretty courageous of him to be the one to propose using something else instead of GCJX in the overall interests of GCJ.

ECJ seems pretty good and very actively maintained. It must be one of the fastest Java compilers around and fully supports the new language features introduced in JDK 1.5. So it is a very good move for GCJ.

Using ECJ does introduce GCC bootstrapping issues though. However, it should be possible to easily overcome these issues. The bigger issues are political and legal in nature. Let us hope these are resolved favourably.

I personally feel a little sad though. This removes another "fun" part of GCJ even though it is pragmatically a better thing to do, especially considering the precious little resources that the GCJ project has. I feel that GCJ is becoming more and more an "integration" project combining the best-of-breed in Free software for a given task - the Java language compiler would be ECJ, the garbage collector is Boehm-GC, the runtime library is GNU Classpath and the optmisation and code-generation is done by GCC. Of course, this can hardly be characterised as bad and is in fact quite a sensible thing to do given the limited amount of resources that the Free software world has at its disposal, but...

"Lisp is Sin"
Sriram Krishnan writes an interesting weblog entry on Lisp. As a side-effect, it made me read some of Peter Norvig's essays and mark his book "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp" as well as Richard Gabriel's book "Patterns of Software: Tales from the Software Community" for later reading.

A Non-Invasive and Reversible Pre-processor for Java
I really like Per's implementation of a Java pre-processor.

rmathew.com
I have finally registered the domain rmathew.com for myself. It just points to my site hosted by Hosting Zero. The registration was surprisingly easy and rather quick. Within just a couple of minutes, the domain was accessible and the redirection was working. I chose GoDaddy.com even though they were more expensive for just the registration than Yahoo! because their private registration add-on turned out to be slightly cheaper on the whole than that of Yahoo! - I really do not want random people to access my personal information via a WHOIS lookup.

The "gotcha" about this registration turned out to be the fact that I inadvertently ended up with a pre-approved payment agreement with GoDaddy.com on my PayPal account, even though I had paid all the amount upfront and had marked my domain for manual renewal. Talking to their customer support didn't help much except stuff my mailbox with verbose and heavily graphic HTML messages. I have tried to contain the damage a bit by limiting the monthly outflow to USD 0.01, but I don't think I'll be sticking with them after my domain registration expires.

Profound Statement in Latin
Courtesy Anirban: "Quidquid Latine dictum sit, altum viditur" ("Whatever is said in Latin sounds profound").

Virtual Address Space Randomisation and Debugging
I feel rather silly today. Even though I knew about virtual address space randomisation in newer Linux kernels, it never struck me that I should disable it to get a reproducible debugging session with predictable breakpoint conditionals. My silly workaround was to use this patch:

Index: tree-ssa-operands.c
===================================================================
--- tree-ssa-operands.c (revision 109196)
+++ tree-ssa-operands.c (working copy)
@@ -1460,6 +1460,16 @@ get_call_expr_operands (tree stmt, tree
   tree op;
   int call_flags = call_expr_flags (expr);

 +  if (strcmp (lang_hooks.decl_printable_name (current_function_decl, 2),
+              "of") == 0)
+    {
+      const char *called_f
+        = lang_hooks.decl_printable_name (TREE_OPERAND (TREE_OPERAND (stmt, 0),
+                                                        0), 2);
+      if (strcmp (called_f, "_Jv_ThrowBadArrayIndex") == 0)
+        printf ("Hello \"_Jv_ThrowBadArrayIndex\"!\n");
+    }
+
   if (!bitmap_empty_p (call_clobbered_vars))
     {
       /* A 'pure' or a 'const' functions never call clobber anything.

 

and then put a breakpoint at the "printf" to get the debugger to stop the compiler process while processing the operands for the statement I was interested in.

Thanks to Mike Stump, we now have a page in the GCC Wiki that explains this problem and how to avoid it. Putting in the desired breakpoint is very simple now and avoids unnecessarily kludgy patches that contaminate the tree:

(gdb) b tree-ssa-operands.c:1463
Breakpoint 1 at 0x80d1f3f: file /extra/src/gcjx/gcc/gcc/tree-ssa-operands.c, line 1463.
(gdb) cond 1 stmt==0xb7c27fc8

Cool! Now all that is left is to use this breakpoint to figure out what the actual problem is that caused us to fire up a debugger.

Confessions of a TAB-hater
I do not like it when people put TAB characters in their source code for indentation. I prefer to use spaces instead of TAB characters to indent my source code. Jamie Zawinski has written a nice document that clearly explains the problem. Note that I am not against using the Tab key as a quick way of indenting, but putting in actual TAB characters (ASCII character #9) in the source code. Different people set tabstops differently, so what looks good to them looks terrible to others. These characters also mess up the indentation in patch diffs.

VIM has an unfortunate optimisation that replaces consecutive spaces with as many TAB characters as possible and if you "set expandtab", then even desirable TAB characters (in Makefiles for example) are replaced by spaces. Yes, I know of using the Ctrl-V + Tab sequence to insert an actual TAB character in this mode, but it is painful. So I have ended up putting the following in my ".vimrc":

set shiftwidth=2
set tabstop=8
inoremap <Tab> <C-V><Tab>
autocmd BufNewFile,BufRead *.java setlocal expandtab
autocmd BufNewFile,BufRead *.c setlocal expandtab
autocmd BufNewFile,BufRead *.cc setlocal expandtab
autocmd BufNewFile,BufRead *.cpp setlocal expandtab
autocmd BufNewFile,BufRead *.h setlocal expandtab
autocmd BufNewFile,BufRead *.hh setlocal expandtab
autocmd BufNewFile,BufRead *.hpp setlocal expandtab
autocmd BufNewFile,BufRead *.xml setlocal expandtab
autocmd BufNewFile,BufRead *.sql setlocal expandtab

If I were to design a programming language, I would seriously consider not allowing TAB characters to be counted as whitespace. It would make source code use up a few extra bytes compared to what it would if consecutive spaces are replaced by as many TAB characters as possible, but I would trade that off for overall sanity.

By the way, I consider it really silly that the authors of make chose to make TAB characters so important, when they are virtually indistuingishable from spaces when you inspect Makefiles. Their mistake has cost the software world the creation of the monstrosity named Ant.

The Etymology of "Foo"
RFC 3092 is devoted to explaining how "foobar" came to be used so much in software code and documentation.

"A Practical Sanskrit Introductory"
Thanks to Anirban Mukherjee, I came across a nice document (2.5MB PDF) written by Charles Wikner containing introductory lessons for the Sanskrit language. Just take a look at the first chapter to see why I personally consider the phonetically precise Devanagari script to be far superior than the utterly challenged and much abused Roman script, even at the risk of appearing jingoistic.

Twenty Years of comp.compilers
comp.compilers has turned twenty. It is one of the few USENET newsgroups that I try to read regularly and whose moderator John R. Levine has done a rather fine job over the years of keeping the signal-to-noise ratio high enough. He is also known to put in editorial remarks, almost always at the end, in many a post that either answer a question outright or contain pointers to useful material or contain quirky and mostly amusing remarks. Kudos to him and the community that sustains this awesome resource.

"The Perils of JavaSchools"
It is not often that I fully agree with an article written by Joel Spolsky, but this one is an exception. As someone who has been interviewing people for his employers for over eight years, I can attest to the steady deterioration in the quality of candidates I talk to and the depressingly continuous lowering of my expectations over the years when I walk into the interview room.

Hacks
Yumpee pointed me to an old story about a guy who used a BBC Micro monitoring a decaying prawn sandwich to tell the time!

Jockey is a cool user-space program execution recording and replaying library for Linux. It actually scans the code page of a process to recognise system call instructions and rewrites them to jump to a trampoline instead.

By the way, my favourite Free 3D modelling tool Blender has reached version 2.40 featuring tonnes of cool improvements.

Terrorists Strike in Bangalore
Terrorists opened indiscriminate fire and killed at least one person and seriously injured four to six others yesterday. What was particularly appalling was their choice of the Indian Institute of Science (IISc) and researchers attending a conference on Operations Research as the target!

StanChart Sees the Light
Among the financial institutions I deal with and whose online facilities I use regularly, Citibank India, HDFC Bank and ICICI Bank have had great support for Firefox. The only exception was Standard Chartered India who did not seem to want to support anything other than IE or Netscape Communicator 4. I had pointed this out to their Customer Service several times and even pointed out where in their JavaScript code they were making the mistake, but I was always presented with a verbose, albeit nicely written, message asking me to just use the supported browsers and stop ranting. Needless to say, I was irritated and frustrated.

To my pleasant surprise, I discovered last week that they had silently started supporting Firefox as well. Perhaps it came about because a lot of their developers themselves use Firefox; perhaps a lot of customers actually complained; perhaps they saw that by most accounts, Firefox has around 8-10% of the "browser marketshare". Whatever be the reason, I am happy. It is also heartening to note that a lot of sites these days increasingly seem to just work with Firefox instead of requiring IE.