Miscellaneous

GDB 6.2 is out finally and so is Linux Kernel 2.4.27.


(Originally posted on Advogato.)

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!


(Originally posted on Advogato.)

"Effective C++"

I read this book by Scott Meyers this weekend and grew even less fond of C++! I mean, it's almost as if this language goes out of its way to ensure that you end up with several "gotchas" to worry about in addition to what you set out to code in the first place!

(Originally posted on Advogato.)

"Keeping Programming Fun"

I came across an Ask Slashdot question that touches upon something that has really been bothering me lately - as a professional programmer, how can you keep programming fun enough to dabble in your favourite Free or Open-Source or personal project after work at home?

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:

• Work for a company that will actually pay you for your work on your favourite project. Not everyone can be so lucky and sometimes there are other factors (location preference, desired minimum salary, etc.) which make this impossible. In addition, I have this weird problem where a thing becomes totally uninteresting to me and a chore the moment I am asked or expected to work on it by someone else. :-(


• Work for a company where the day job is not so taxing (usually) on your creative juices, yet pays you well enough to bring food to your table and to pay for your loans (mortgages). In Bangalore, this is a possibility. ;-)
• 
  Switch professions - get a job that does not involve programming. The problem with this, apart from the need to be educationally qualified to do such a job, is the danger of the job getting too boring or too interesting - the former can be disastrous while the latter saps into your creative juices just the way a programming job does.
  


• Forget about personal projects for a while, concentrate on your job, wait for the Peter Principle to take effect and get promoted into management - you will then have more money as well as a job that does not involve coding. Personally, this will profoundly depress me, killing all the enthusiasm I have.
  

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?

(Originally posted on Advogato.)

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.

(Originally posted on Advogato.)

No News is Bad GNUs

What's up people? There haven't been regular updates on Planet Classpath from a lot of you for a long time... Get off your Glutius Maximii and tell us what you have been up to recently!


(Originally posted on Advogato.)

GCJX

I am playing with Tom's GCJX now whenever I get some time, trying to understand it and see if I can contribute a little to add in some of the missing pieces. Last weekend I contributed JAR/ZIP reading. It turns out that this is a bit slower than reading from expanded folders containing the compiled classes.

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?

(Originally posted on Advogato.)

GCJX

I started tinkering with Tom's
GCJX project this weekend. On a cursory perusal, it definitely seems
more accessible to ordinary mortals than the current GCJ front end. It
is written in C++, a language that I am not too comfortable with, but
that should not be an insurmountable problem.

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:

#!/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

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!

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.java

This 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:

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

"-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").

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.


(Originally posted on Advogato.)

Bootstrapping

My understanding of the bootstrapping process.

(Originally posted on Advogato.)

Bytecode Verification

I was able to track down and fix PR 5537 with a simple patch, but fixing it exposed other problems in the front end bytecode verifier that cause failures in the libjava testsuite and in the Mauve verifier testsuite.

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?


(Originally posted on Advogato.)