Older blog entries for maelstorm (starting at number 2)

Peeve of the day: Java doesn't provide an easy way (or even a one off) of introspecting into any publicly exported classes to find out whats there at runtime.

I suppose the reason for this is that it might be seen as a potential security violation. After all, your program should know exactly what it's dealing with.

The task I wanted to accomplish was the automatic detection of all implementers of a certain interface for report generation at runtime in order to build a composite report and another for finding all batchable tasks in the jar. There are other, more specific ways of doing this, that also require more code management -- I could add a static set of calls in the class declaration of the various implimentors that automaticly registered the class with some singleton management class. I could use a property file with a list of class names of reports that I wanted to generate (or tasks that I wanted to have run). It was suggested that if I knew the jar file name, I could also suck out the class names from the Manifest (haven't looked into that option yet).

Any other suggestions?

31 Jan 2001 (updated 7 Feb 2001 at 16:50 UTC) »

Spent my evening after work playing with Coldstore's Chaos language. While it already works, it's all direct interpretation, and only minimal error checking for stack depth requirements. So I spent the evening extending the primatives list to include stack information.

Next will be some decisions on how to do bytecode representation, and a seperate version of the lexer that emits the bytecode, rather then direct interpretation.

Looked at a RPN based functional language called Joy -- there's definitely some interesting concepts that could be borrowed from it, and it's one of the reasons for adding the stack effects notation to the current set of primative operations. I think in a later iteration, I'll try to use that to guess 'correctness' of procedures and stacks.

And spotted a scary thing on comp.lang.functional: Scheme implemented in JavaScript.

I've been spending the past few weeks trying to understand functional programming, especially OCaml. From what I've read, it's supposed to be one of the fastest functional programming language implementations (and corrispondingly, one of the fastest ML implementations) out there.

It took a few years for it to start to crystalize for me. I think I first started looking at SML around 1996, and tried to convince, without success, one of my Math/Com Sci instructors to assist me in a independent study exploration of it. His reasoning was that: 'At this point in your degree, you should be able to pick up any programming language'.

I guess the only thing he really didn't count on is that ML requires a different mindset then the imperitive programming languages that were pretty much the standard. I had taken some LISP with him, but the approach there was limited to symbolic manipulation for simple AI stuff, like eliza, deeply recursive functions, and information space searching.

Thats all well and good, but it still didn't prepare me for actually having to worry about domain mapping, and something so well and thoroughly steeped in the lambda calculus, and side effect free coding.

But it's finally making sense. I kinda wish I had a project to use it on.

The big reason I'm looking into functional programming right now is that I'm hoping to figure out some of the nifty implicit typing rules for Coldstore's second programming language, freon.

New Advogato Features

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!