Older blog entries for ingvar (starting at number 269)

Ooops. Seems I over-wrote the 0.4 version of my image library. Not to worry, there's a 0.5 out and the main difference is an added dependency on Xach's ZPNG library and it now has the ability to write PNG files (mainly added because I found myself needing to write an image with 372 different colours and it was easier adding PNG support than to write something that intelligently coerced different pixels together with minimal degradation to image quality).

I also suspect there's not that many actual users, so the impact should be minimal.

Slight distress. The latest Debian packaging of SLIME+Swank is kinda broken. I prodedd at it this morning, trying to make it behave, but I did (alas) not have great luck.

There's two obvious-from-start problems, "directory" is spelled either as "dir" or as "directory". Quite easy toi fix, unfoirtunately, it gets worse from then on. Fix those and yoiu hit a "Package SWANK does not exist". That's because it's defined in the file swank-new.lisp and that's (in the package) not loaded by default. "Oooops".

Smack in loading of "swank-new" and "nregex" (load "nregex" first), and you land in more-interesting-problem-land.

I'll probably have another look either tonight or tomorrow, as having a non-functional SLIME is oddly crippling (now that I'm used to it). Maybe I should stop grabbing my SLIME from Debian and go back to having it from version control? But, then, I don't like running "infrastructure" from version-control checkouts, it's not nearly as convenient as running it from well-managed packages.

Also scribbled together an essay last week, as I was finding the whole "Jimbo Wales is $ADJECTIVE" quite, ah, well, something. Amusing, more than anything else. So, interspersed into last week's training course ("Implementing Qos", thanks for asking), I wrote Behaviour and effects (Jimbo was, really, just a convenient hook to hang things off of).

It just struck me, the web equivalent of incremental development is probably the Wiki. A big ball of mud you add things to and occasionally reshape.

If that is indeed so, CLiki is probably a ball of mud, on top of another ball of mud, though I can see that this analogy is now starting to muddying the waters...

Ooops! I am, as they say, an idiot.

Yesterday's tar ball is a wee bit lacking in essential files, as it were (the slight restructuring saw some functions being broken out into helpers.lisp and I wasn't packaging imports.lisp at all).

In further not-really-news, clast and Zaitcev have been discussing FizzBuzz (basically, count up from 1, for each n == 0 MOD 3, say Fizz, for each n == 0 MOD 5 sau Buzz and if both, FizzBuzz). Dividing by 3 and by 5 is, essentially, trivial in the decimal system. I first encountered this as a drinking game, with the addition that any 3 in the decimal expansion was also a Fizz and any 5 in the decimal expansion was a Buzz (and again if it's both a Fizz and a Buzz, it's a FizzBuzz).

This variety is slightly harder, in that you end up with 8 Fizz and 2 FizzBuzz between 29 and 40. Surprisingly hard, once you get into drinking game territory, around 2 AM.

It is longer than usual since the last post. January has so far been full of hectic (including, but not limited to two long-running faults coming to a clench at the same time as I was away for Cisco Networkers).

There is a new version of my image library out. It is, as these things go, not nearly as ambitious as what other people write, but as-is, it provides assorted drawing operations on a canvas, with back-end export to (at the moment) X11 or GIF files (via CLX and Skippy, respectively). In its latest incarnation, it also has the ability to load GIF files (no X11 image loading, yet).

There is, as usual, far too much WIP to even consider mumbling about it, most waiting for one thing or another before I forge ahead and finish off some more.

I have, recently, seen a more sophisticated version of "there are no libraries for Common Lisp" (there's quite a few). THis more sophisticated version does have something going for it, at that. Paraphrased, it is "There are very few Common Lisp libraries that have a bus number higher than one".

For those of you who haven't heard of the term "bus number" as it applies to projects (IT projects, I think, specifically), it is the number of key people that need to be hit by a bus to make the project grind to a halt.

An inactive project obviously has a bus number of zero (it can't really progress any slower). Most projects that are driven by a single person have a bus number of one. Most of the libraries I am responsible for is in this category (though I shroud myself in the comfortable illusion that at least GENHASH is sufficiently well documented that most anyone with a few spare hours should be able to whip up a library with the same API).

To an extent, I think there's something to that view (that is "language X is riskier than language Y, because a% of LangX libraries have a bus number <=1, whereas only b% (where b << a) of langY libraries do"), but at the same time, I do wonder if it's such a massive risk. After all, most CL libraries are distributed as source and that means "developer killed by bus" is no worse than "no more updates". Any and all bugs can (and if the library is "big" and "important" enough, will) be fixed, one way or another. Maybe with some initial forking, before consolidating itself.

It would be interesting to know to what extent this is just a perceived problem for Common Lisp contra other languages. At least I know there's now several libraries with multiple committers, so with any luck, this problem will solve itself, given time.

A delayed"is Emacs large?" essaylet has, after languishing unloved and beign ignored for quite a while, finally been finished off.

The quick answer is "maybe", it's all a bit relative. With a default Debian install, GNU Emacs 21.4 has almost half the files of a similar Vim installation, but consumes more disk space.

I found it quite interesting that the difference between a "only compoiled emacs-lisp" emacs and a vim installation were fairly small, since "emacs is so large!" has been a common complaint, for at least as long as I have used emacs (about 18 years now). Curiously, it seems like quite a few who champion vi-like editors over emacs are indeed vim users. At least now, there's some not-entirely-soft numbers showing ath while emacs isn't small, it's not exceedingly large, either.

Hah. Managed to find a timesink extraordinaire, Project Euler. I have, so far, solved just over 20 problems, out of the 166 listed.

Others have posted about how they use emacs when developing COmmon Lisp code. I, too, use emacs (it has been my primary editor since 1989 or so) and one thing I do find exceedingly useful is only tangentially related to development at all.

It is a well-known fact that many emacs users accumulate tweaks, config changes and small pieces of utility code. It got to the point that I found the sheer size of my .emacs file annoyingly huge and hard to manage. So I decided to do something about it.

These days, my .emacs file consists of 7 statements. First, I change the auto-save prefix, then I extend the load-path (where emacs finds its libraries) to include $HOME/src/ elisp (where I keep my private libraries), I then load one of those libraries and call a function from it. There's two additional forms, to allow the auto-management of the customize subsytem.

The library loaded is einit.el, a small library that allows you to splitr your configuration into multiple files, with load- order imposed on them. It will load files from (by default) $HOME/.emacsdir/ and it does take some care to only load files that are named ei-something (the convention I use is eiNNsubsytem.el). Using this, it is quite easy to find configuration for specific subsystems, keep a load-order for subsystems that depend on each other and (if needed) disable the setup for a specific system without any code modification (simply rename the file that loads the system or delete it if you are sure you won't want it, ever again).

Ugh, there's a horrible misfeature in the latest version of SLIME. I am, of curse, talking about slime-highlight-edits- mode, an abomination that colourises your edit buffer. I honestly don't know how peple can stand colour changes in their edit buffers (I have less of a problem with it in an interaction buffer or when reading mail/news). But any highlighting in a buffer where I constantly need to look at more than just "the next thing along text-reading forward" is distracting and when I don't know how to switch it off somewhat stressful.

I suppose there's enough pepople taht want that sort of thing, though, because they do seem to pop up with distressing regularity.

Not that the feature it intends to provide is bad (it is, effectively, highlighting forms that have yet to be compiled). I would, however, much prefer a key combo I can press to see if the current top-level form has been evaluated or compiled since it was last edited (notice that I did say "evaluated or compiled", not just compiled; I am usually bitten by "forgot to press C-x e" and going "butbutbut, that should work! oh, it's only in the editor, not in the image, duh." than I am having done that and get bitten because things haven't been compiled (I am sure that I've been bitten by compilation, but that has mostly been "this is way slower than it should've been, it's exactly the same speed as the naive proof-of-concept code! oh... wait.. it's interpreted" than "it doesn't work!").

As luck has it, it is indeed activated from slime-mode- hook, so deleting it out of there fixes it for this emacs process and there might be a permanent fix in my slime- stuff file.