Older blog entries for ingvar (starting at number 114)

OK, seems as if I've managed to whip up a hash table implementation that allows the user to register their own [{eq test}, {hash fn}] pairs (there's four pre-registered, for EQ, EQL, EQUAL and EQUALP). It should be ASDF-installable (package name is "genhash") and there's a CLiki page in the obvious location.

It's not been exhasutively tested, but it does, indeed, seem to work. If a hash/eq-test pair taht doesn't follow "(eq-test a b) => (= (hashfn a) (hashfn b))" things will most probably break in *interesting* ways.

The presentation seemed to go well, as far as I can tell. Lots of intelligent questions and some interesting side-tracks to pursue.

I find myself in the bizarre position of trying to convince myself of not writing CL code for work (production use). I have this binary log format we need to extract data out of. I have at hand Perl, Python and C APIs but Python is definitely too slow. C is fast, but it's not nearly as flexible writing the analysis tools we need in C (implement another generic hash-table? do explorative programming? in C? no thank you). As soon as I've got some speed data out of teh Python code, I'll bash up the equivalent in Perl and check (basically, the speed-test program opens the log, then reads and entry and updates a counter; repeat until end-of-log; print counter).

I'm testing on 2 minutes worth of log, this is around 43 MB of data. In C, just reading it and incrementing the counter takes about 14 s, says time(1). The python version takes 8m14s to process 2m worth of log. This is quite bad for things that we'd (ideally) would want to process in real-time.

OK, I need to whack things a bit before I can speed-test the Perl version. Aha! It's faster than Python, marginally. 6m49s for a 2m log. Still not fast enough.

Good thing I was moving ahead implementing something that may actually be useful, then.

"Ooops".

Seems as if I am persenting a small thing at next week's Scheme UK meeting. Admittedly, I'll be talking Common Lisp, not Scheme. I hope they will forgive me.

All code generation seems sane. This is a step forward. tar-ball downloadable (complete with ASDF system definition) from here (signed MD5-sums here).

Latest little piece of code is "internal use only" (it's a thinge for generating character templates for an RPG I am slowly causing to exist, the latter is not ready for general release and the former is *quite* useless without the latter; there's some possibly-interesting persistence happening, but taht may or may not be generally useable).

Well, seems as if I had managed to mess up quite badly, implementing the code generation for LD, so that's being rewritten. However, I'll probably not manage to finish it all this week (there's bound to be other "interesting" areas of the code generation, see), so I shall simply have to write a sufficiently-ambitious piece of test code (and also try to figure out if I want to do something clever with labels as argumnets to DJNZ and friends).

Hahaha. Haha. Well, indeed, it has not been properly tested. In fact, it's in a bit ofa state, so I am bashing it around as I type. Hopefully, it should be in a state suitable for release later this week.

It is now finished and packaged. Though in some sort of confusion, it's not been properly tested, so a CLiki page will just have to wait.

License still needs to be hashed out. The assembler is mostly done (all the assembly parts are, SNA output nearly there, it needs better docs and some examples, I guess). I'm leaning towards an "implementor's guide" (I mean, as of "right now" it's actually lisp macross that expands into function calls that do some checking and eventually cause side-effects in a global variable that then gets mangled about by an assortment of code until it's done and then passed through and having one GF getting called on each object in the global list so as to hand back the bytes; then passed on to a GF that emits in the right file format).

It's actually quite cute, but I'm not entirely sure I understand how it works, unless I'm hacking on its innards.

Work is proceeding apace. I may be finished earlier than I expected. Now is left only "what license to use". I'm leaning towards either a BSD-style license or just leave it in the public domain. Both will, quite probably, cause comments.

Last implemented instruction generation was for PUSH.

The output and input frameworks are in place and tested. I've decided on a flexible output file format (basically, the method generating the output file is handed a stream and an array where all non-filled-in bytes are set as -1, so there's an option of skipping them past or defaulting them to some suitable value (the SNA file writer will end up emitting NOP for those).

Woohoo. I'm about half-way through the code generation for LD. One slight change of plans. instead of hard-coding the "result file generation" to be whatever-the-format-I'm-thinking-of, it will be suitably pluggable, either by switching a global or by passing a :format :<format&gt: to the assembly function (this, of course, means figuring out how to do proper filename mangling of the input name and generate a suitable outfile, either as two separate functions, with some sort of mechanism to select what should be called; at the moment, I'm leaning towards two EQL-specialized GFs, one for the name mangling and one for the file output).