One advantage of using XML is that one can rely on good support in libraries for functionality. When parsing XML, one does not have to take care of the syntax, and focus on the data and its semantics. This comes at the expense of verbosity, though, but having the ability to express semantics explicitly is a huge benefit for flexibility.

11 years ago, a day more or less, I bought an the special issue of CHIP which shipped Debian 1.3.1. I think I’ve tried SuSe and RedHat earlier that year, but this Debian release made me switch away from proprietary products 98% (taxes I still had to do with Windows98). Right now, I am mostly running Ubuntu, which leans heavily on the work of the Debian project.

The reason why I have not blogged in more than two weeks, was that I was hoping to blog about the CDK 1.2.0 release. This was originally aimed at September, slipped into October, November and then December. There were only three show stoppers (see this wiki page), one of which the IChemObject interfaces were not properly tested.

Peer review is an important component of open source development, and recently there was the discussion the other way around, if open source is required for peer review.

Yesterday’s blog about Who says Java is not fast?!? caused quite some feedback (thanx to all commenters!) with several good points. Of course, a table like that in the cinfony paper (see also the comments in the blogs by Noel (the author) and Rich). Many things determine why the CDK might be fastest in that table for SDF iterating. Suggestions have been that OpenBabel and RDKit may be doing much more than simple reading;

While performance tests actually show that for even core numerical calculations Java is at par with C in terms of speeds, and sometimes even hits Fortran-like speeds, people keep think that Java is not fast. I only invite you to test that yourself.

… a source code reviewer nightmare. The must-read lwn.net ran a nice open letter to a Linux kernel developer.

Some time ago, I added parallel building targets for CDK’s Ant build.xml. Now that I am setting up a Nightly for the jchempaint-primary branch, and really only want to report on the CDK modules control and render, I need the build system to use a properties files to define which modules should be compiled.

it provides a recipe to approach (scientific) questions let’s you cook up a (scientific) answer you can use it as a black box (like an orbitrap) you can refine existing methods (well, some can, others don’t) it has an error (but I do not believe it is normally distributed)

Today and tomorrow, Stefan, Gilleain, Arvid and I are having a JChemPaint Developers Workshop in Uppsala, to sprint the development of JChemPaint3, for which Niels layed out the foundation already a long time ago.

I am working on converting Jean-Claude’s Solubility data to RDF (after Pierre’s model, see here, here, and here, here for first data exploration), so that I can integrate it with data from DBPedia, Freebase, rdf.openmolecules.net, etc. Bioclipse will be the workbench in which this will be visualized, and just got graph depiction online using Zest.