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

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

(Originally posted on Advogato.)

Emaciated, yet Emancipated

Linux Weekly News (LWN) is an online resource of superb quality - dare I say it is The Economist of the Free Software journalism world - well researched and mostly thorough articles, quite up to date and fairly balanced content and a simple yet effective layout. I have enjoyed it for quite some time now and would highly recommend it to anyone who cares to listen.

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!


(Originally posted on Advogato.)

Contributing to GCC

Roger Sayle sums it up nicely. I agree with him 100%. Even though I am a fringe and quite erratic contributor to GCJ (much less the core GCC), it has helped me immensely as a software developer. To paraphrase Calvin's Dad, "It helps build character".


(Originally posted on Advogato.)

C++

Nathan Sidwell is on the laudable mission of introducing statically typed trees to GCC replacing the much abused and overloaded "tree" structure. Some people were of the opinion that it might be much better to just write a front end in C++ or at least a reduced subset of C++ ("C with classes"?). Some though were a bit apprehensive of the idea, saying that once you let in a bit of C++, there will really be nothing stopping developers from bringing in all of C++ and then you'd find yourself in a nightmare of trying to support all those C++ compilers on all supported platforms that differ sometimes subtly, sometimes not quite so in their interpretation of the language standards.

Tom has rewritten the GCJ front end in C++ and has done awesomely well and quite a lot in such a short period of time.

Looks like there's no escaping it now...

But...

I have never been able to bring myself to like this language. There is no one thing that I can point to nor can I write detailed and knowledgeable analyses like this or this, though I do agree completely with a lot of points raised in these.

Perhaps it is because of the boring and overly complex book on the language by Stroustrup that happened to be my first introduction to C++ (in a sharp contrast to that masterpiece of brevity, accessibility and utility that was written by Kernighan and Ritchie). Perhaps it is because of the mind-scarring error messages spewed by the versions of the IBM xlC compiler on AIX containing literally two to three lines of mangled names of instantiations of templates. Perhaps it is because of the fact that GCC is so slow compiling programs using the STL. Perhaps it is because I found that as a programmer I had to know so many things about the nuances of the language just to be able to program anything with a semblence of confidence.

I really like object-oriented programming, but I find Java to be way better and much simpler in expressing myself than C++. I would not at all mind if GCC were to be rewritten in Java, though I'm not at all a Java fanboy.

I just want a natively compiled, simple programming language without many "gotchas", that lets me easily express decent object-oriented designs and that comes with a standard and fairly comprehensive runtime library. Perhaps I should take a dekko at Objective C.

(See? This is what happens when Advogato comes back up online after a long time.)

(Originally posted on Advogato.)

"Things a Computer Scientist Rarely Talks About"

My friend Ananth has just gifted me a copy of "Things a Computer Scientist Rarely Talks About", a very different book by Donald Knuth. Having admired and being in awe of most of Knuth's work and being an atheist, this book should make some interesting reading for me.

Other recently acquired books on my "reading pending" list (besides almost the whole of my library) include "The Art of Unix Programming" by Eric Raymond and "Five Point Someone" by Chetan Bhagat, a novel about life in an IIT.

(Originally posted on Advogato.)

Advogato Is Back!

Finally!


My inane ramblings can now resume.


Mwahahahaha!!!


(Originally posted on Advogato.)