Older blog entries for ingvar (starting at number 276)

One of my co-developers raised an interesting point in a mail to the dev mailing list today.

How do other monitoring toosl deal with "configuration for lots of almsot identical objects"? I mean, say you have a really big cluster of (say) linux boxes, where the only difference between them is their name?

The current noctool solution is: (cluster ("machine-%d" 1 800) (machine name linux-host ... more config here ))

This will generate 800 copies of the (machine ...) config snippet, with the name changed (if you prefer a place- holder other than "name", you can specify another one, it you want a format string suitable for CL:FORMAT, you can have that, too). However, as always, it's interesting to see how other have solved the same problem (or, indeed, not solved it, as the case might be).

I just built a litte add-on, to help me package things up (see, it seems I occasionally forget that I add files to projects and then they won't get packaged when I tell the project to package itself).

From that was born the ASDF-TOOLS package (designed to work in conjunction with my build-asdf-package shellscript). It has two exposed function calls.

ASDF-TOOLS:CHECK-PACKAGE goes through the ASDF system definition and checks that the files specced there exist in .filelist and similarly for any file you explicitly ask to have packaged; differences are printed to *STANDARD- OUTPUT* and if there are files that are needed for building that are unlisted in the packaging file information, the function returns NIL.

ASDF-TOOLS:PREPARE-PACKAGE goes through the ASDF system definition and all extra files you specify, then dump this data to .filelist, it also updates the .version file.

Obvious extensions from here: An :around method on ASDF:PERFORM that handles the "incorrect FASL version" condition and forces a recompile of the component, then continues. A function that grovels through an ASDF system and deposits a gzipped tarball in the right directory. I have a vague memory of having seen an ASDF component class that is neither compiled nor loaded, if I use that to replace .filelist, I should in principle be able to move my packaging from a unix shell script to lisp code. Neat, in a way.

I told a lie, unintentionally. There is anon CVS available. There's also a web-CVS interface..

So far, I've had a bunch of emailed queries. I haven't responded to all, hopefully I will.

I don't think I posted about it, at the time. However, NOCtool now has a common-lisp.net project thingie. No public CVS at the moment. NOt even tarballs ready to snag. However, it's there and tehre's mailing lists and stuff. If you want to help, give me a shout.

I found a way of testiung Hunchentoot handlers from the REPL. Unfortunately, it only works with a non-mod-lisp instance. It also relies of having the server instance to be tested in *hunchentoot* (not a problem for me, but you may want to check that). I'll have a rummage through the Hunchentoot source at some point and see if I can get it to work when mod_lisp is involved.


(defun hunchentest (uri)
  (let* ((hunchentoot:*server* *hunchentoot*)
         (hunchentoot:*reply* (make-instance 
'hunchentoot::reply))
         (hunchentoot:*request* (make-instance 
'hunchentoot::request
                                               :uri uri)))
    (funcall (essay-dispatcher hunchentoot:*request*)
             hunchentoot:*request*)))

Found the problem. Old, stale, flexi-streams installation. Snagging a new one and recompiling meant that (setf flexi- stream-bound) suddently was in existence and my faffing around now works. Thanks for the clues, Robert!

4 May 2008 (updated 4 May 2008 at 17:15 UTC) »

I had planned on doing a quick web-related project, to get started with Hunchentoot, since it seems to be the lisp- based web server of preference. Unfortunately, I seem to be made from fail. I can get it to listen to a port, but I cannot, however much I try, make it send anything back.

The docs indicate taht if I start the server and then point a browser at it, I should get a short info page back. Unfortunately, all I get is "nothing". I've even whipped out a Wireshark to confirm. Ah, well, maybe it'll be obvious, at some point.

Of course, trouble-shooting this is a bit more difficult than it could be, since it's a threaded server and it's harder than "trivial" to get tracing and the like to work.

As and when I get a bit more round tuits, I'll probably go check the hunchentoot mailing list archive, I doubt I'm the first person to run into this.

Hmm, looking at this again, the server replies and immediately closes the connection.

16 Apr 2008 (updated 16 Apr 2008 at 13:20 UTC) »

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...

267 older entries...

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!