Paraprogramming Dispatches

..there is no shortage of rainy evenings in the rain capital of the world, so I used a few of them to put together this small application that I called (perhaps overly ambitiously) cl-imagenet. It uses a bunch of Lisp libraries: opticl and cl-jpeg for image processing, cxml for extracting bounding boxes from the annotations, cl-fad for filesystem operations, and trivial-channels in combination with clx for streaming to display.

The code tries to detect how many cores the host machine has, then creates the corresponding number of worker units. The workset ImageNet subunits list is built up, which are then assigned to the workunits. Each workunit fetches annotation file, extracts the bounding boxes and image file reference, decodes the corresponding JPEG file, handles processing with OptiCL and sends the result via shared channel to display thread. It is impressive how compact the code can be when leveraging random bits of the ecosystem available through Quicklisp.

In this setup only the luminance component of JPEG is extracted and then thresholded from medium gray. The video is filmed on an old quad i5-2500. On my 8-core i7-6700 box with visualisation off, it averages some 200K processed images per hour.

Tested lightly with SBCL on Linux. One known problem place is the message channel gradually eating up memory with visualization on, but as it’s only used in tests it hasn’t been a pressing need to fix yet.

I’m enjoying my customized mechanical WASD keyboard since last summer:

Its signage and cap colors are inspired by early Lisp machine ‘space cadet’ keyboards. Not anywhere a close functonal match certainly but I do like the looks. And unlike the the original it comes in short, messy-desk-space-preserving 87-key version.

The inscriptions are changed to oldskool. Alt is META, AltGr is GREEK, caps is HYPER and left-Win is SUPER. SUPER is bound to X11 layout switch in my system, GREEK is just the normal European 2nd-level shift. HYPER is remapped to.. well actual Hyper. This adds a bunch of new keybinding space in Emacs:

(when (eq window-system 'x)
  (shell-command "xmodmap -e 'remove Mod4 = Hyper_L' -e 'add Mod3 = Hyper_L'")
  (shell-command "xmodmap -e 'clear Lock' -e 'keycode 66 = Hyper_L'"))

(global-set-key (kbd "H-k") 'kill-this-buffer)
(global-set-key (kbd "H-f") 'find-file)
(global-set-key (kbd "H-h") 'hyperspec-lookup)
(global-set-key (kbd "H-3") 'split-window-right)
(global-set-key (kbd "H-2") 'split-window-below)
(global-set-key (kbd "H-1") 'delete-other-windows)
(global-set-key (kbd "H-0") 'delete-window)
(global-set-key (kbd "H-s") 'save-buffer)
(global-set-key (kbd "H-a") 'mark-whole-buffer)
(global-set-key (kbd "H-r") 'raise-sexp)
(global-set-key (kbd "H-c") 'slime-selector)

Norwegian-based layout is available here.

Among the first computer related-books I read was a PDP-11 programmer’s manual, borrowed in a library. It was a bit too dense for someone who never seen a computer in their life. Save for the random bits like bus arbitrage or advantages of magnetic domain memory over core, nothing stuck really. A bit later came my first real programming experience, a few simple BASIC programs on DVK, a DEC PDP-11 clone, under RT-11.

Then this winter, browsing eBay junkyards, I came across an MS-1201.02: a Q-Bus board at heart of DVK. A couple weeks later, it was on my desk:

Looks like a finest specimen of Soviet electronic manufacture, but robbed of its KM type platinum/palladium capacitors by precious metal scavengers. It’s a wonder that the processor (16-bit K1801VM2) in gold-plated contact CERDIP package wasn’t removed. The CPU has a crack in the package however, which might prevent it’s function.

The board has three jumper blocks for configuration. Or at least it had in theory.. in reality, communist DIP jumpers were so bad the factories stopped installing them after a while. So if you wanted to change a serial port speed or boot address, you had to do it like Real Men do: with bare hands and soldering iron.

The board has 64Kb physical memory, only 56Kb (28 Kwords) of which are however addressable - the upper 8Kb are I/O mappings in PDP-11 architecture.

So as you see, some work to be done here. Immediate plan is:

• Order all the missing caps and repopulate them
• Find a replacement CPU chip and replace if necessary
• Install less manly, capitalist DIP piano switch blocks
• Build a backplane to install the card in
• Build a current loop serial interface to RS-232c converter
• As the board uses two “power good” signals in startup sequence, build a small flip circuit for start-up
• Boot the board to the built in serial monitor prompt

Out of that, the caps, CPU and backplane components already ordered. Schematics are fortunately available on the net.

To be continued.

I’m happy to announce CL-VIDEO, a basic AVI/MJPEG video decoder written in Common Lisp. The library leverages CL-JPEG for frame processing and CL-RIFF for container format handling.

The code has only been lightly tested on SBCL 13.x/Linux x86-64. Some sample files can be found here (the toy plane AVI) and here.

To run it, CL-JPEG version 2.7 is required. Since it’s not in Quicklisp yet as of time of writing, it must be cloned into your local-projects. Then you can load cl-video-player system and run (cl-video::play <your filename.avi>).

The implementation is still very much naive, as expected from a weekend project. There is no support for indexing, and a number of edge cases of legit AVI encodings might fail. The library will decode video frames in the order they occur. No parsing of BITMAPINFOHEADER structures; the assumption is they are MJPG DIB. No audio playback, although the stream is being read and adding at least PCM/WAV playback shouldn’t be too big an effort.The decoder is factored out into independent implementation in cl-video.lisp. A primitive CLX media player is included in player.lisp. Each AVI instance contains one or more (audio or video) stream record objects, which hold ring buffers of frames with read and write cursors. The interaction between the decoder and player frontend runnning in separate threads is done via mutexed access to this ring buffer. The player thread can be kicked off a callback supplied to decode method: it will be called once the header part is parsed.

Since CL-JPEG doesn’t use any SIMD extensions, the performance is modest. On my 6 year old 3GHz i5 (running one core of course) it decodes 480p 25fps file without hiccups, but going beyond that would require implementing multicore support in decode. Still it might be useful as is in applications not requiring real-time decoding performance.