Older blog entries for ingvar (starting at number 281)

Here, marnanel writes about early mornings and it resonated.

Due to an assortment of reasons, my primary "I am alone, there is no external pressure" hacking time tends to be from not-too-long after 6 am (depending on how promptly I can get up and go through the normal first-things-in-the- morning routine), until about 07:30, when it's time to finish getting dressed and head towards the train station, for another exciting day in the office.

That's also the first time period of the day when I can check my email and do a brief check on assorted web stuff. Most, if not all, of my coding is accomplished in these 45-80 minutes of the day. At times, I am surprised I get anything finished...

This "paper writing" is both familiar and unfamiliar, in a strange, frightening, way. At least feedback from the first- ish round of independent readers is starting to drop in.

I guess everyone has heard of "the editor wars" (usually simplified to "emacs vs. vi(m)".

So have I. I have one editor I use almost daily, but there are three editors I can actuall use (well, OK, two of them are more "editor families" than distinct editors).

First off, I self-identify as an emacs user. I've used one or another emacs as my primary editing environment for the last 20 years. A new editor would have to be pretty darn astoundingly good for me to change that.

However, if you don't have a favourite editor already, I suggest you try out several different editors. Use them for at least 3-4 weeks and spend a day or two coming to grips with your editing environment. When it comes to editing comfort, first impressions can actually lure you into ditching something that is good and instead make you choose something that is less good. After you become sufficiently used to your editing environment it will be hard to change.

So, why did I end up with emacs-like editors (one of the "editor families")? Primarily thanks to the fact that emacs had a built-in tutorial. Secondarily becaiuse of emacs lisp. I've always liked lisp and lisp-like languages (something that may be obvious, looking back through my Advogato diary entries).

I said I was proficient with three different editors, I better explain taht too. I can (and do) use vi (and vi- heritage) editor(s) (primarily nvi and vim, with a distinct preference of nvi over vim), because I used to earn my living by being a unix sysadmin, occasionally being sent out to clients. You can't really expect to be able to install and compile emacs whenever you hit a new site, it just wastes time. So, learn to use the tools available.

I can also use ed. Admittedly, I mostly use ed as part of shell scripting, but that's because it can trivially be driven via stdin (build edit command using echo, pipe these into ed filename and make sure to finish with wq, stick this in a loop and you're set to do things in sequence, with externally kept state; not pretty, but it does the job).

Somewhat amusingly, I actually used vi before I used emacs, but never really continued with vi (and from there derived editors). I don't know if I'd kept with vi, had there been a good in-editor tutorial (or at least a tutorial docuiment I dcould've played around with). It felt like a struggle, initially. I had some rudimentary ed when I started with vi, but the latter was sufficiently different to cause impedance mismatch between what I knew and the capabilities available in the new environment.

Emacs, on the other hand, was nothing like ed, came with in- editor tutorials, in-editor documentation and a lisp environment to boot. I was willing to invest the necessary time to becxome proficient and have, as they say, never looked back really hard.

Clearly, I have a favourite editor, but I don't think there is such a thing as "one true editor, best for all possible things". I guess the fact that my .emacs contains (setq wq "Emacs, not vi!") to be sufficient proof of that...

ringbark writes:
2. I knowingly travelled on the longest escalator in Europe, at Angel. (Pedants please explain if it isn't.)

It seems to be the longest escalator in Western Europe. But there's one in Moscow, at the Park Pobedy station, that's almost twice the length. Moscow qualifies as being in Europe, I believe.

In NOCtool-related news, the network code has been written, integrated and lightly tested. I believe Jim Prewett is working on at least one UI at the moment. Once I've finished off a couple of other things, I'll look at writing something to integrate Nagios-monitors into NOCtool's infrastructure.

13 Jun 2008 (updated 13 Jun 2008 at 10:05 UTC) »

Another gem (or at least gem-oid).

If you use strings to signify system names in ASDF system definitions, it works just fine. However, it seems as if it interacts weirdly with at least some versions of ASDF- INSTALL.

Due to that, I will be going through my packages and slowly update them to use #:systemname instead of "systemname". On the whole, there won't be much ele updated, though.

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*)))

272 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!