UPS Woes
My UPS by APC was out of action and at a service centre this weekend - it switched off while I was working on my computer and then started emitting these highly irritating beeps that I couldn't quite do much about (it being 11PM in the night). To add insult to injury, the service centre guys apparently kept it under observation for two days and did not find any problems with it whatsoever!
Miscellaneous
GDB 6.2 is out finally and so is Linux Kernel 2.4.27.
Many a time, I am just too mentally tired to do any useful programming work at home on weekdays and I would like to keep the weekends free for other non-programming activities (reading books, socialising with friends, watching movies, etc.). So where is the time for a poor hacker to work on his favourite projects?
Some of the possibilities:
The comments in the Slashdot article linked above provide some more options, but there is nothing that really helped me.
How do you cope up with it?
SQL and PL/SQL
After almost a decade of "abstinence", I am finally attending a training course on learing SQL and PL/SQL. Two of the big products that I have been involved with at work (at my current as well as previous employer) have had almost all of the core business logic in PL/SQL, so saying "I'm a Java programmer - I won't look at that!" doesn't quite work that well when it comes to understanding these systems.
My fears and reluctance in learning these earlier were mostly unfounded - these are not that bad to learn and to use, though it seems that elegance is something that their designers didn't particularly have high on their minds.
By the way, GCJX is most definitely much easier to understand and tweak than the current GCJ front end. It also uses standard STL containers instead of the ubiquitous GCC trees or hash tables.
A disturbing thing that I discovered was that GCJX compiled with debugging information is around 48.5MB(!) on my machine and when stripped, comes down to somewhat reasonable 1.5MB. Could it be that we need to exorcise the Template Instantiation demon?
I built and ran GCJX against the current GCC mainline. I normally do not actually install a newly built mainline GCC snapshot after the GCC build process is complete, so using this compiler is a bit different than normal - I used the following script to build GCJX using such a GCC:
Compiling C++ programs that use STL with GCC can be quite slow, so I am glad that newer GCC versions have pre-compiled header (PCH) support. The script above uses PCH to build GCJX - on my little machine, the total build time is reduced from 12m 2s to 6m 32s and an additional 11s to build the PCH itself. That's quite an improvement!#!/bin/sh# Build GCJX
GCC_SRC_DIR=/extra/src/gcc/gcc GCC_BLD_DIR=/extra/src/gcc/build GCC_BLD_TGT=i686-pc-linux-gnu
BLT_CXX="$GCC_BLD_DIR/gcc/g++ -B$GCC_BLD_DIR/gcc/ \ -I$GCC_BLD_DIR/$GCC_BLD_TGT/libstdc++-v3/include \ -I$GCC_BLD_DIR/$GCC_BLD_TGT/libstdc++-v3/include/$GCC_BLD_TGT \ -I$GCC_SRC_DIR/libstdc++-v3/libsupc++ \ -L$GCC_BLD_DIR/$GCC_BLD_TGT/libstdc++-v3/src/.libs"
make CXX="$BLT_CXX" typedefs.hh.gch
make CXX="$BLT_CXX" want_pch=yes
Since GCJX does not come with its own class libraries, I used GNU
Classpath 0.10 sources appropriately updated
(create "gnu/classpath/Configuration.java" and copy over classes
under "vm/reference/" into the top folder) for use with GCJX.
After this, I could compile simple programs as:
lextest /path/to/classpath-0.10 . -- HelloWorld.javaThis parses the given file and all files from the Java runtime (quite a lot) needed for a complete closure and writes out class files (and CNI header files) to "/tmp/gcjx-out" (which I had to create beforehand). Note that I had to update LD_LIBRARY_PATH to point to the folder containing the libstdc++.so file from the GCC build folder as "lextest" depends on this library.
Compiling so many of the Java runtime classes over and over again every time I want to compile a source file is a little wasteful, not to mention quite slow, so I started giving the path to the libgcj build folder from the GCC build folder and this speeded things up considerably.
My next task was to check GCJX against the Jacks testsuite. I had to create an appropriate Jacks "gcjx_setup" file. Mine looks like this:
"-jacks" is a temporary flag that causes GCJX to suppress most of its pedantic warnings and causes it to write out classes to the current folder (instead of "/tmp/gcjx-out").set JAVAC /extra/src/gcjx/lextest set JAVA /extra/src/gcc/build/i686-pc-linux-gnu/libjava/gij set JAVA_FLAGS "-mx=64m" set JAVA_CLASSPATH "" set JAVAC_FLAGS {/extra/src/gcc/build/i686-pc-linux-gnu/libjava . -- -jacks} set JAVAC_DEPRECATION_FLAG "-deprecated" set tcltest::testConstraints(assert) 1
I got 4302 PASS-es, 541 FAILs and 76 UNTESTED out of a total of 4919 Jacks testcases. This is not as good as what Tom reports, so I have to see what has gone wrong - but in any case, it is much better than what the current GCJ front end gives.
Great work Tom!
I want to see if I can add JAR/ZIP reading support to GCJX. This looks doable and Tom already has most of the framework ready.
So now I need to go after these bugs before I can submit a patch.
~sigh~
(Why do such things always happen to me?)
I found an interesting presentation (PDF) by Gilad Bracha (a "Computational Theologist" in Sun) on bytecode verification. I found it interesting because he says that Sun went with load-time bytecode verification to reduce run-time verification overheads and had to introduce strict definite (un)assignment as a mandatory feature of the language to be able to carry out proper type inference during verification! The other interesting bit was that they went with type inference (instead of type checking) to reduce the space used by class files at the cost of increased complexity, memory usage and speed - they later found out that type checking would have meant faster and simpler code at the cost of only a little extra space (5-10%)!
"Premature optimisation is the root of all evil!"
By the way, JDK 1.5 will have class data sharing to reduce startup times. So should libgcj use prelinking?
Bootstrapping
My understanding of the bootstrapping process.
For some time now however, the "crown jewel" of LWN, "The LWN.net Weekly Edition" has been immediately available only to subscribers (though it is made freely accessible to everyone else after a week) as even the LWN guys need to feed themselves, just like everyone else. So I decided to subscribe to it, if nothing to show my support for these wonderful guys, but found out that except for the "starving hacker" level of subscription, everything else would be a bit of an indulgence for me when the fact that a US Dollar is around 45 Indian Rupees is considered. So that is what I opted for and now I get all the LWN stuff as soon as it is published. Cool!
GCC and C++
The GCC Steering Committee published its decision (and that of RMS) on Nathan Sidwell's proposal to rewrite GCC in a useful subset of C++. In short, they have turned it down though they are open to the idea of making GCC sources compile correctly with a C++ compiler. What I didn't quite get was this:
In addition, RMS stated that the use of C++ was unacceptable for the GNU Project, at least for programs that are presently written in C.This is quite weird and without more of the context in which this was uttered or clarifications, I don't understand this at all. In particular, this doesn't bode well for Tom's rewrite of the GCJ front end in C++, which by the way, is coming along pretty well for a one man project.
RMS also considers GCJ's capabilities to compile Java bytecode bad, considering it a way for malicious vendors to bypass GCC's GPL to use it as a compiler backend!
Whatever...
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!