Life in the old dog yet…

Contradicting my earlier assertion that “it's only when you want GUI that you have to get off the fence.” — I've built the Java 1.0-based Gadget Windowing Toolkit against JVM for Java 5 and (with just a little added C#) CLR.

It might not be “teh shiny”, and won't give you mouse wheel events, but it's the fastest way to a common GUI toolkit for both VMs.

Weaning it off the Java 1.0 event model that it uses inside a 1.1 emulator, and using Container instead of its own Gadget class (written because Container and Component had protected constructors at Java 1.0) would make it a lot leaner, and more robust, but it's not a simple matter of mechanically replacing the classes. There is a lot of code dedicated to managing focus and graphics contexts — including managing the masks and offsets — that would have to be carefully moved across.

And of course, there's only the one huge demo/test, rather than unit tests.

Smelling the coffee…

… before work goes crazy in the 4 weeks left to holidays — a first drop of angerona.redcoffee.zip; what may (ha! ha!) become a hybrid Java/Ruby CTClib equivalent for both JVM and CLR.

This contains code for various symmetric crypto algorithms, strong hashes, erasable big numbers and Zlib compression (based on JZlib 1.0.7); it contains some initial JUnit tests aimed at JUnit 3.8.2 in NetBeans 6.0 (currently using RC1). It also contains a project to build JUnit 3.8.2 (almost) as a J# project generating a command line executable (.exe also included). The "almost" is because the assertEquals() methods for Double and boolean have been taken from 3.8.1 to permit them to compile under J#.

The NetBeans project has been amended to use cobertura 1.9 to perform coverage analysis as the unit tests are run -- assumed to be in C:\cobertura-1.9, adjust build.xml to fit your location; or use it as a prototype for other projects. The VS 2005 solution builds the JUnit ~3.8.2 executable, the angerona.algorithms.dll library, and the unit tests as three projects; and as a post-build step for the last runs the tests under NCover (assumed to be installed to directory C:\Program Files\NCover) -- I'm using 1.5.4, having had some problems with 1.5.8 run over managed C++ code not contained in gc classes.

Also included is an FxCop project; I shall be using that run manually, and PMD as a live plug-in while the code is being groomed; they will get incorporated into the build process later when the noise level has been considerably reduced.

Note that the two build environments are set up to use the same source file structures, though J# has to be hand-held to point it at the files that NetBeans just picks up automagically.

The only files in any sort of stable state at the moment, the proofs of concept, are SHA0.java and SHA1.java, which have unit tests based on the FIPS PUB 180-1 test vectors. These tests all pass and give 100% coverage (including branch coverage) to the base SHA class and the two wrappers. The first phase will be getting the state of no PMD warnings, no FxCop warnings (except where naming conventions are involved, and there, Java conventions set out by PMD will win if there is a conflict), unit tests with ideally 100% coverage; this will overlap with doing some refactoring.

Then with a stable foundation, the plan will be to gradually migrate the rest of CTClib, primarily to Ruby, but probably with a few Java interface types to make the external interface more easily usable by other JVM or CLR projects.

Archive is 257,055 bytes; MD5 7335e89a 171560f3 003f225e d97a3b3c & SHA-1 4d421c00 d4b3b45d be0244e3 649b19bd 04923a94.

Shaking some dust off…

After a long distraction by paying work, I'm starting to turn attention back to projects. The IronPython FTP client still needs wiring up (and bug fixing), but a few developments in recent months -- JRuby, and now Ruby.Net 0.9, have led me to turn my attention once again to taking my old PGP-emulator library, currently languishing as 'C' and a number of abortive ports, out of the 1970s.

I have several key bits -- crypto algorithm implementations I rolled myself, and, now the JZlib port of the key ZLib component (for reasons best known to PRZ, the version in PGP 2.x uses an 8k window, and no standard APIs give you control over that so as to be able to emit compatible compression) -- in Java. But now I could build the rest of the system in Ruby and build it to the CLR as well as the JVM.

Then it's only when you want GUI that you have to get off the fence.

Of course, uploading the library will mean I shall want to have completed my improved FTP client, so win-win,… or something

Meanwhile a long term-goal for self-development stuff at work will involve some F#…