Types of arrays in common lisp

Here's a gotcha that I've finally understood (with some hand-holding from stassats on #lisp).

The type of a lisp array describes how specialised it is, not the objects it contains.

How to tell if you're confused in the same way that I was: you think that (simple-array T (*)) should be a super-type of (simple-array '(signed-int 32) (*)). But see here:

CL-USER> (defparameter *x*
           (make-array 5 :element-type '(signed-byte 32)
                         :initial-element 0))
*X*
CL-USER> (typep *x* '(simple-array (signed-byte 32)))
T
CL-USER> (typep *x* '(simple-array T))
NIL

What's going on is that (simple-array (signed-byte 32)) means an array that is specialised to hold 32-bit integers more efficiently. If I was on an old 8-bit machine or was using a less enthusiastically optimising lisp implementation, the make-array call might not have managed to make a specialised array. In which case, it would have fallen back to making a (slower / less efficient) array that can hold any old thing. The resulting object would have type (simple-array T). In fact, the two types are disjoint. The SIMPLE-ARRAY documentation in the hyperspec makes it clear:

The types simple-vector, simple-string, and simple-bit-vector are disjoint subtypes of type simple-array, for they respectively mean (simple-array t (*)), the union of all (simple-array c (*)) for any c being a subtype of type character, and (simple-array bit (*)).

Well, now that makes sense. So what do you do if you want to allow specialised arrays or generic arrays in your type? There's one magic option (also explained in the CLHS at the link above). Use (simple-array *) and it'll match anything.

When libtool's dependency_libs goes weird

I had a strange problem last night where I couldn't build some code I was working on. The program (gpsim) depends on the Gtk stack and the errors I got seemed to refer to a nonexistant libtool .la file:

libtool: link: ar cru .libs/libgpsimgui.a gui_break.o gui_callbacks.o gui_dialog.o gui_init.o gui_main.o gui_menu.o gui_processor.o gui_regwin.o gui_src.o gui_src_asm.o gui_src_opcode.o gui_statusbar.o gui_symbols.o gui_watch.o gui_breadboard.o gui_stack.o gui_trace.o gui_profile.o gui_stopwatch.o gui_object.o gui_scope.o settings_exdbm.o gui_hextable.o preferences.o gui_marshal.o libtool: link: ranlib .libs/libgpsimgui.a /bin/sed: can't read /usr/lib/libgio-2.0.la: No such file or directory libtool: link: `/usr/lib/libgio-2.0.la' is not a valid libtool archive

Now, I'm running an up-to-date version of Debian unstable and I couldn't really believe that a problem that stopped people linking things depending on glib would survive very long. The solution came when I realised that references to /path/to/foo.la come from other .la files. Ahah! So, after some thought, I tried a grep command:

$ locate '*.la' | xargs grep libgio-2.0.la | grep '^/opt' | cut -d : -f 1
/opt/gnome/lib/gtk-2.0/modules/libgtkparasite.la
/opt/gnome/lib/libgpsim.la
/opt/gnome/lib/libgpsimcli.la
/opt/gnome/lib/libgpsimgui.la
/opt/gnome/lib/libgpsim_ds1307.la
/opt/gnome/lib/libgpsim_dspic.la
/opt/gnome/lib/libgpsim_graphicLCD.la
/opt/gnome/lib/libgpsim_lcd.la
/opt/gnome/lib/libgpsim_modules.la
/opt/gnome/lib/libgtkextra-x11-2.0.la

Ahah! The culprit was the last line: gpsim still links against the hideously obsolete libgtkextra and I'd forgotten to rebuild my local copy when upgrading my glib package to one that doesn't ship libgio-2.0.la. Editing the libgtkextra .la file might have worked but I just rebuilt the lot to make sure it worked. Sorted!

Bookmarklet to ease the pain from Warwick Uni Library's E-journal change

The University of Warwick Library no longer allow access to E-journals except after jumping through hoops to access them through the library's web catalogue. This is painful and, although I've now got a plethora of links to various journal home-pages, I still find myself cutting and pasting parts of URLs to avoid some journals' awful navigation interfaces.

But all is not lost! Here's a JavaScript bookmarklet which will open up the current page channelled through Pugwash, which appears to be the library's main server. It seems to work for me, but the "0-" prefix on the URLs looks worryingly magical and I'm not sure whether this is correct for all journals...

To use the bookmarklet on Firefox (or pretty much anywhere else), you can right-click on the link (the "here" above) and select something like "Bookmark this link". If you are (rightly) wary of trusting a random hunk of JavaScript, this is the code:

javascript:(function(){
  var str=location.href;
  if(str.substr(0,7)!="http://") {
    alert("Unrecognised protocol");
    return;
  }
  var ffs=str.substr(7).indexOf("/");
  if(ffs==-1) {
    fs=str.length-1;
  }
  else {
    ffs=ffs+7;
  }
  window.open("http://0-" + str.substr(7,ffs-7) +
              ".pugwash.lib.warwick.ac.uk/"+str.substr(ffs+1));
})()

(It has to be on one line to work, so you'll need to delete a lot of whitespace if you want to copy and paste this).

Gray boxes in evince

If you're having a weird problem with evince showing gray boxes instead of text in some pdfs, the problem could well be a bug in cairo.

After some help from "danigm" on the #evince channel on irc.gnome.org, I found that the bug disappeared on upgrading libcairo to 1.9.8 (which is currently in debian experimental).

Anyway, hopefully the next person who searches google for grey boxes in evince or indeed gray boxes in evince should find the solution!

Huawei E1550 on Debian

If you want to get the Huawei E1550 USB modem working with linux, here's what you need to do, with specific instructions for those on Debian.

modem-modeswitch

This utility is part of udev as of version 145. You need it because the E1550 has a clever double-identity: when you insert it at first, it masquerades as a mass storage device (usb id 12D1:1446). Upon running this magical command, it disconnects and reappears as an "E620 USB modem" (usb id 12D1:1001). Magic eh?

Firstly, you need to get the program. If you have udev 145, life is good. Unfortunately, the current debian unstable package is on version 141, which doesn't have it. Trying to manually install udev 145, I managed to break my X setup quite spectacularly, so I don't advise that. Fortunately, if you download the latest udev source (from
http://www.kernel.org/pub/linux/utils/kernel/hotplug/) and compile it, you'll find that the binary in the extras/modem-modeswitch directory works fine without the rest of udev 145. Note that to compile udev, you'll need some libraries. On debian, an incantation like apt-get build-dep udev should get them. To put it somewhere useful, one option is to run checkinstall from inside the extras/modem-modeswitch
directory and make a fake debian package for the meantime.

Now you've got modem-modeswitch installed, you want to try it! Pull up a spare terminal window and run something like sudo tail -f /var/log/syslog in it. This lets you know what's going on, since drivers tend to report stuff there when they initialise
themselves. Now run the following command /path/to/modem-modeswitch -v 0x12d1 -p 0x1446 -t option-zerocd. On my dongle (courtesy of 3), there's a green LED that flashes at first and then turns blue at this point. In any case, the syslog window should report a USB disconnect and then a new device. Running lsusb should show a line something like Bus 002 Device 003: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem (the first two numbers will probably be different: they're
just to say where it's connected).

If you've got this far, the confusing bit's over. Unplug the device again and we'll set things up to run modem-modeswitch by default.

udev

To do so, we need to create a udev rule to tell it to run when the device is plugged in. Create a file in /etc/udev/rules.d/ called something like 50-huawei1550.rules containing the following line

SUBSYSTEM=="usb", SYSFS{idProduct}=="1446",SYSFS{idVendor}=="12d1", RUN+="/usr/libexec/modem-modeswitch --vendor 0x12d1 --product 0x1446 --type option-zerocd"

This tells udev that when a device with USB id 12d1:1446 gets plugged in, it should run modem-modeswitch to change its mode. (This snippet came from somewhere on the web, but I've lost the reference). You probably need to restart udev here (/etc/init.d/udev restart) to enable your rule. Re-insert the device and cross your fingers... if everything works, it should change mode.

usb-serial

If you're using a distro kernel, you can probably ignore this, but I was running a home-built kernel which didn't have the usb-serial kernel module. You need it.

If you've got stuff right, lines like the following should appear in your syslog:

Jul 31 10:49:03 hake kernel: usbcore: registered new interface driver usbserial
Jul 31 10:49:03 hake kernel: USB Serial support registered for generic
Jul 31 10:49:03 hake kernel: usbcore: registered new interface driver usbserial_generic
Jul 31 10:49:03 hake kernel: usbserial: USB Serial Driver core
Jul 31 10:49:03 hake kernel: USB Serial support registered for GSM modem (1-port)
Jul 31 10:49:03 hake kernel: option 2-2:1.0: GSM modem (1-port) converter detected
Jul 31 10:49:03 hake kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
Jul 31 10:49:03 hake kernel: option 2-2:1.1: GSM modem (1-port) converter detected
Jul 31 10:49:03 hake kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
Jul 31 10:49:03 hake kernel: option 2-2:1.2: GSM modem (1-port) converter detected
Jul 31 10:49:03 hake kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB2
Jul 31 10:49:03 hake kernel: usbcore: registered new interface driver option
Jul 31 10:49:03 hake kernel: option: v0.7.2:USB Driver for GSM modems

Science Education Website

Well, I'm lame and not really updating this. However, my mother has a terribly nice (ahem?) website at WAS Science, which she doesn't seem to be able to get web spiders to notice. It's a site full of science education resources including powerpoint presentations and worksheets.

Maybe some googly goodness from blogger will go her way.

Quick book recommendation

This summer, I've got an undergraduate research bursary at our university's Systems Biology centre, which is wierd as I always viewed myself of more of a pure mathematician, but is absolutely fascinating.

I have jumped in at the deep end, however (my supervisor seems to think I know a lot more than I really do and maybe hasn't realised I haven't done any serious integration/differentiation or ODEs stuff since the first year...).

What I'm actually doing is looking at the response of Neurons to different types of presynaptic noise, which I am slowly learning more about. In particular, noise is random (well, duh) and so all of the models I end up with have Stochastic Differential Equations, which are typically quite unpleasant. For those interested, the toy models I'm playing with end up with Brownian motion in a harmonic potential.

So the book I'm recommending is:

Paul and Baschnagel, "Stochastic Processes, From Physics to Finance"

Don't let the reference to finance put you off - I've found it absolutely fantastic for explaining the basics of Wiener processes, brownian motion and so on. In particular, it is written for the scientist rather than the mathematician and so everything's done in the real numbers, rather than over wierd and wonderful probability spaces. I really believe that even if you want to learn stochastic integration properly as a mathematician, this is a worthwhile read, because you end up for a real feel for what's going on.

The book's published by Springer and is on Amazon here at the terrifying price of about £50 used, so you might want to try a university library!

Now back to work!