FOSDEM 2018

2018-02-06T09:36:00+00:00

I've just returned from a weekend in Brussels for my first ever FOSDEM - the Free and Open Source Developers, European Meeting. It's been on my list of conferences to go to for some time and thanks to getting my talk accepted, my employer financed the cost of travel and hotels. Thanks to the support of the Université libre de Bruxelles (ULB) the event itself is free and run entirely by volunteers. As you can expect from the name they also have a strong commitment to free and open source software.

The first thing that struck me about the conference is how wide ranging it was. There were talks on everything from the internals of debugging tools to developing public policy. When I first loaded up their excellent companion app (naturally via the F-Droid repository) I was somewhat overwhelmed by the choice. As it is a free conference there is no limit on the numbers who can attend which means you are not always guarenteed to be able to get into every talk. In fact during the event I walked past many long queues for the more popular talks. In the end I ended up just bookmarking all the talks I was interested in and deciding which one to go to depending on how I felt at the time. Fortunately FOSDEM have a strong archiving policy and video most of their talks so I'll be spending the next few weeks catching up on the ones I missed.

There now follows a non-exhaustive list of the most interesting ones I was able to see live:

Dashamir's talk on EasyGPG dealt with the opinionated decisions it makes to try and make the use of GnuPG more intuitive to those not versed in the full gory details of public key cryptography. Although I use GPG mainly for signing GIT pull requests I really should make better use it over all. The split-key solution to backups was particularly interesting. I suspect I'll need a little convincing before I put part of my key in the cloud but I'll certainly check out his scripts.

Liam's A Circuit Less Travelled was an entertaining tour of some of the technologies and ideas from early computer history that got abandoned on the wayside. These ideas were often to be re-invented in a less superior form as engineers realised the error of their ways as technology advanced. The later half of the talk turns into a bit of LISP love-fest but as an Emacs user with an ever growing config file that is fine by me ;-)

Following on in the history vein was Steven Goodwin's talk on Digital Archaeology which was a salutatory reminder of the amount of recent history that is getting lost as computing's breakneck pace has discarded old physical formats in lieu of newer equally short lived formats. It reminded me I should really do something about the 3 boxes of floppy disks I have under my desk. I also need to schedule a visit to the Computer History Museum with my children seeing as it is more or less on my doorstep.

There was a tongue in check preview that described the EDSAC talk as recreating "an ancient computer without any of the things that made it interesting". This was was a little unkind. Although the project re-implemented the computation parts in a tiny little FPGA the core idea was to introduce potential students to the physicality of the early computers. After an introduction to the hoary architecture of the original EDSAC and the Wheeler Jump Mary introduced the hardware they re-imagined for the project. The first was an optical reader developed to read in paper tapes although this time ones printed on thermal receipt paper. This included an in-depth review of the problems of smoothing out analogue inputs to get reliable signals from their optical sensors which mirrors the problems the rebuild is facing with nature of the valves used in EDSAC. It is a shame they couldn't come up with some way to involve a valve but I guess high-tension supplies and school kids don't mix well. However they did come up with a way of re-creating the original acoustic mercury delay lines but this time with a tube of air and some 3D printed parabolic ends.

The big geek event was the much anticipated announcement of RISC-V hardware during the RISC-V enablement talk. It seemed to be an open secret the announcement was coming but it still garnered hearty applause when it finally came. I should point out I'm indirectly employed by companies with an interest in a competing architecture but it is still good to see other stuff out there. The board is fairly open but there are still some peripheral IPs which were closed which shows just how tricky getting to fully-free hardware is going to be. As I understand the RISC-V's licensing model the ISA is open (unlike for example an ARM Architecture License) but individual companies can still have closed implementations which they license to be manufactured which is how I assume SiFive funds development. The actual CPU implementation is still very much a black box you have to take on trust.

Finally for those that are interested my talk is already online for those that are interested in what I'm currently working on. The slides have been slightly cropped in the video but if you follow the link to the HTML version you can read along on your machine.

I have to say FOSDEM's setup is pretty impressive. Although there was a volunteer in each room to deal with fire safety and replace microphones all the recording is fully automated. There are rather fancy hand crafted wooden boxes in each room which take the feed from your laptop and mux it with the camera. I got the email from the automated system asking me to review a preview of my talk about half and hour after I gave it. It took a little longer for the final product to get encoded and online but it's certainly the nicest system I've come across so far.

All in all I can heartily recommend FOSDEM for anyone in an interest is FLOSS. It's a packed schedule and there is going to be something for everyone there. Big thanks to all the volunteers and organisers and I hope I can make it next year ;-)

Looping in LISP

2010-08-10T09:04:00+01:00

Loops are a fairly important part of any programming language and fairly fundamental to a language that is purported to be all about manipulating lists. However it's not something I use that often in my .emacs code so I thought it might be useful to discuss the various options with some examples.

Problem: I run emacs on a number of machines, each with a different set of sound sets. I want to set up set up a valid sound for erc but I don't want an overly verbose set of cases depending on what machine I'm on. Instead a given a list of sound files I want a function that will return the first one that actually exists.

This problem can be easily generalised into return the first valid path from a list of paths.

First version: pure emacs lisp

; the 'elisp' way
(defun find-valid-file-elisp-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (let (r '())
    (mapc '(lambda (f)
             (if (file-exists-p f) (add-to-list 'r f)))
          list-of-files)
    (car r)))

First impressions aren't good. The lisp parenthesis do seem to get in the way of making what is happening clear. However it's using one of common mapping functions you see a lot of in lisp. A mapping function essentially takes a list, applies a function to each element of the list and eventually returns a result. The most common of the mapping functions is mapcar which returns a modified list as a result. In this case that isn't what we want so we use mapc where the only value that is built up is the result r as we identify each valid file. The final return value is just the first entry in that list. This does mean we have processed the whole list of alternatives which is sub-optimal.

Second version: Common Lisp Version

(defun find-valid-file-clisp-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (loop for path in list-of-files
        until (file-exists-p path)
        finally return path))

This version probably is the easiest to read for people familiar with other programming languages. The intention of the code jumps out at you. However the actual implementation is done with a macro. If you look at the help for loop you'll see it can take a number of different forms - follow that to the code and you'll see a fairly complex elisp implementation. However to my mind still easier to follow than the pure elisp version with mapc.

Third Version: Using the dolist macro

; using 'cl-macs
(defun find-valid-file-dolist-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (dolist (f list-of-files)
    (if (file-exists-p f)
        (return f))))

This is yet another version using an LISP macro but this one has considerably less potential forms to cause confusion. It's fairly comprehensible what is going on and even follows the traditional parenthesis happy form. It also takes advantage of the common LISP return to early return from the loop when we detect a valid file. If it makes it to the end of the list it evaluates the 3rd optional form to calculate the result which in this case will be 'nil.

So what do you think? What version do you prefer? Where does the balance lie between writing code is LISPy ways and for code comprehension? Are there any other ways to solve this particular problem? I'll be looking forward to your comments.

Alex's Adventures on the Infobahn - lisp

FOSDEM 2018

Looping in LISP

First version: pure emacs lisp

Second version: Common Lisp Version

Third Version: Using the dolist macro