pages tagged elsnoteshttp://christophe.rhodes.io/notes/tag/els/notesikiwiki2016-05-07T20:30:37Znot going to els2016http://christophe.rhodes.io/notes/blog/posts/2016/not_going_to_els2016/2016-05-07T20:30:37Z2016-05-07T20:30:37Z
<p>I’m not going to the
<a href="http://www.european-lisp-symposium.org/">European Lisp Symposium</a>
this year.</p>
<p>It’s a shame, because this is the first one I’ve missed; even in the
height of the confusion of having <a href="http://www.teclo.net/">two</a>
<a href="http://www.gold.ac.uk/computing/">jobs</a>, I managed to make it to
Hamburg and Zadar. But
<span class="createlink">organizing ELS2015</span> took a lot out of
me, and it feels like it’s been relentless ever since; while it would
be lovely to spend two days in Krakow to recharge my batteries and
just listen to the good stuff that is going on, I can’t quite spare
the time or manage the complexity.</p>
<p>Some of the recent complexity: following one of those “two jobs” link
might give a slightly surprising result. Yes, Teclo Networks AG was
acquired by <a href="http://www.sandvine.com/">Sandvine, Inc</a>. This involved
some fairly intricate and delicate negotiations, sucking up time and
energy; some minor residual issues aside, I think things are done and
dusted, and it’s as positive an outcome for all as could be expected.</p>
<p>There have also been a number of sadder outcomes recently; others have
<a href="http://mjg59.dreamwidth.org/41948.html">written</a> about
<a href="http://www.inference.phy.cam.ac.uk/mackay/">David MacKay</a>’s recent
death; I had the privilege to be in his lecture course while he was
writing
<a href="http://www.inference.eng.cam.ac.uk/mackay/itila/"><em>Information Theory, Inference, and Learning Algorithms</em></a>,
and I can trace the influence of both the course material and the
lecturing style on my thought and practice. I (along with many
others) admire his book about
<a href="http://www.withouthotair.com/">energy and humanity</a>; it is
beautifully clear, and starts from the facts and argues from those.
“Please don’t get me wrong: I’m not trying to be pro-nuclear. I’m just
pro-arithmetic.” – a rallying cry for advocates of rationality. I
will also remember David cheefully agreeing to play the viola for the
<a href="http://jcms.jesus.cam.ac.uk/">Jesus College Music Society</a> when some
preposterous number of independent viola parts were needed (my
fallible memory says
“<a href="https://en.wikipedia.org/wiki/Brandenburg_Concertos#No._3_in_G_major.2C_BWV_1048">Brandenburg 3</a>”).
David’s last interview is available to
<a href="https://vimeo.com/163698553/10d1bbe16e">view</a>; iPlayer-enabled
listeners can hear <a href="http://www.cl.cam.ac.uk/~afb21/">Alan Blackwell</a>’s
(computer scientist and double-bassist) tribute on BBC Radio 4’s
<a href="http://www.bbc.co.uk/programmes/b0783lqk">Last Word</a>.</p>
<p>So with regret, I’m not travelling to Krakow this year; I will do my
best to make the 10th European Lisp Symposium (how could I miss a nice
round-numbered edition?), and in the meantime I’ll raise a glass of
Croatian Maraschino, courtesy of my time in
<a href="http://ozk.unizd.hr/els2012/">Zadar</a>, to the success of ELS 2016.</p>
els2015 is nearly herehttp://christophe.rhodes.io/notes/blog/posts/2015/els2015_is_nearly_here/2015-03-20T17:32:13Z2015-03-20T17:04:33Z
<p>This year, I have had the dubious pleasure of being the Local
Organizer for the
<a href="http://www.european-lisp-symposium.org/">European Lisp Symposium 2015</a>,
which is now exactly one month away; in 31 days, hordes of people will
be descending on South East London
<a href="http://christophe.rhodes.io/notes/blog/posts/2015/els2015_is_nearly_here/new-cross-gate-01545-750.jpg"><img src="http://christophe.rhodes.io/notes/blog/posts/2015/els2015_is_nearly_here/200x-new-cross-gate-01545-750.jpg" width="200" height="133" alt="New Cross Gate" class="img" /></a>
to listen to presentations, give lightning talks and engage in general
discussions about all things Lisp – the programme isn’t <em>quite</em>
finalized, but expect Racket, Clojure, elisp and Common Lisp to be
represented, as well as more... minority interests, such as C++.</p>
<p><a href="http://www.european-lisp-symposium.org/content-registration-full.html">Registration is open</a>!
In fact, for the next nine days (until <strong>29th March</strong>) the
registration fee is set at the absurdly low price of €120 (€60 for
students) for two days of talks, tutorials, demos, coffee, pastries,
biscuits, convivial discussion and a conference dinner. I look
forward to welcoming old and new friends alike to
<a href="http://www.gold.ac.uk/">Goldsmiths</a>.</p>
reproducible builds - a month ahead of schedulehttp://christophe.rhodes.io/notes/blog/posts/2014/reproducible_builds_-_a_month_ahead_of_schedule/2014-11-10T17:00:04Z2014-11-08T22:38:14Z
<p>I think this might be my last blog entry on the subject of building
<a href="http://www.sbcl.org/">SBCL</a> for a while.</p>
<p>One of the premises behind SBCL as a separate entity from
<a href="http://www.cons.org/cmucl/">CMUCL</a>, its parent, was to make the
result of its build be independent of the compiler used to build it.
To a world where separate compilation is the norm, the very idea that
building some software should persistently modify the state of the
compiler probably seems bizarre, but the Lisp world evolved in that
way and Lisp environments (at least those written in themselves)
developed build recipes where the steps to construct a new Lisp system
from an old one and the source code would depend critically on
internal details of <em>both</em> the old and the new one: substantial
amounts of introspection on the build host were used to bootstrap the
target, so if the details revealed by introspection were no longer
valid for the new system, there would need to be some patching in the
middle of the build process. (How would you know whether that was
necessary? Typically, because the build would fail with a
more-or-less – usually more – cryptic error.)</p>
<p>Enter SBCL, whose strategy is essentially to use the source files
first to build an SBCL!Compiler running in a host Common Lisp
implementation, and then to use that SBCL!Compiler to compile the
source files again to produce the target system. This requires some
contortions in the source files: we must write enough of the system in
portable Common Lisp so that an arbitrary host can execute
SBCL!Compiler to compile SBCL-flavoured sources (including the
standard headache-inducing <code>(defun car (list) (car list))</code> and
similar, which works because SBCL!Compiler knows how to compile calls
to
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_car_c.htm"><code>car</code></a>).</p>
<p>How much is “enough” of the system? Well, one answer might be when
the build output actually works, at least to the point of running and
executing some Lisp code. We got there about
<a href="http://www.advogato.org/person/crhodes/diary/23.html">twelve years ago</a>,
when <a href="http://ccl.clozure.com/">OpenMCL</a> (as it was then called)
compiled SBCL. And yet... how do we know there aren't odd differences
that depend on the host compiler lurking, which will not obviously
affect normal operation but will cause hard-to-debug trouble later?
(In fact there were plenty of those, popping up at inopportune
moments).</p>
<p>I’ve been working intermittently on dealing with this, by attempting
to make the Common Lisp code that SBCL!Compiler is written in
sufficiently portable that executing it on different implementations
generates bitwise-identical output. Because then, and only then, can
we be confident that we are not depending in some unforseen way on a
particular implementation-specific detail; if output files are
different, it <em>might</em> be a harmless divergence, for example a
difference in ordering of steps where neither depends on the other, or
it might in fact indicate a leak from the host environment into the
target. Before this latest attack at the problem, I last worked on it
seriously in 2009, getting most of the way there but with some
problems remaining, as measured by the number of output files (out of
some 330 or so) whose contents differed depending on which host Common
Lisp implementation SBCL!Compiler was running on.</p>
<p>Over the last month, then, I have been slowly solving these problems,
one by one. This has involved refining what is probably my second
most useless skill, working out what SBCL fasl files are doing by
looking at their contents in a text editor, and from that intuiting
the differences in the implementations that give rise to the
differences in the output files. The final pieces of the puzzle fell
into place earlier this week, and the
<a href="http://sourceforge.net/p/sbcl/sbcl/ci/dc73c76ff9fbe44d3a9be5722655ec7ba7af3b92/">triumphant commit</a>
announces that as of Wednesday all 335 target source files get
compiled identically by SBCL!Compiler, whether that is running under
Clozure Common Lisp (32- or 64-bit versions), CLISP, or a different
version of SBCL itself.</p>
<p>Oh but wait. There is another component to the build: as well as
SBCL!Compiler, we have SBCL!Loader, which is responsible for taking
those 335 output files and constructing from them a Lisp image file
which the platform executable can use to start a Lisp session.
(SBCL!Loader is maybe better known as “genesis”; but it is to
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_load.htm"><code>load</code></a>
what SBCL!Compiler is to
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_cmp_fi.htm"><code>compile-file</code></a>).
And it was slightly disheartening to find that despite having 335
identical output files, the resulting <code>cold-sbcl.core</code> file differed
between builds on different host compilers, even after I had
remembered to discount the build fingerprint constructed to be
different for every build.</p>
<p>Fortunately, the actual problem that needed fixing was relatively
small: a call to
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_maphas.htm"><code>maphash</code></a>,
which (understandably) makes no guarantees about ordering, was used to
affect the Lisp image data directly. I then spent a certain amount of
time being thoroughly confused, having managed to construct for myself
a Lisp image where the following forms executed with ... odd results:</p>
<pre><code>(loop for x being the external-symbols of "CL" count 1)
; => 1032
(length (delete-duplicates (loop for x being the external-symbols of "CL" collect x)))
; => 978
</code></pre>
<p>(shades of
<a href="http://www.advogato.org/person/crhodes/diary/12.html">times</a>
<a href="http://www.advogato.org/person/crhodes/diary/57.html">gone by</a>).
Eventually I realised that</p>
<pre><code>(unless (member (package-name package) '("COMMON-LISP" "KEYWORD" :test #'string=))
...)
</code></pre>
<p>was not the same as</p>
<pre><code>(unless (member (package-name package) '("COMMON-LISP" "KEYWORD") :test #'string=)
...)
</code></pre>
<p>and all was well again, and as of
<a href="http://sourceforge.net/p/sbcl/sbcl/ci/80c4401cf00909700fa942cf8bd34de500cbc73b/">this commit</a>
the <code>cold-sbcl.core</code> output file is identical no matter the build
host.</p>
<p>It might be interesting to survey the various implementation-specific
behaviours that we have run into during the process of making this
build completely repeatable. The following is a probably
non-exhaustive list – it has been twelve years, after all – but maybe
is some food for thought, or (if you have a particularly demonic turn
of mind) an ingredients list for a maximally-irritating CL
implementation...</p>
<ul>
<li>Perhaps most obviously, various constants are
implementation-defined. The ones which caused the most trouble were
undoubtably
<a href="http://www.lispworks.com/reference/HyperSpec/Body/v_most_p.htm"><code>most-positive-fixnum</code></a>
and
<a href="http://www.lispworks.com/reference/HyperSpec/Body/v_most_p.htm"><code>most-negative-fixnum</code></a>
– particularly since they could end up being used in ways where
their presence wasn’t obvious. For example, <code>(deftype fd ()
`(integer 0 ,most-positive-fixnum))</code> has, in the SBCL build
process, a subtly different meaning from <code>(deftype fd () (and
fixnum unsigned-byte))</code> – in the second case, the <code>fd</code> type will
have the intended meaning in the target system, using the target’s
<a href="http://www.lispworks.com/reference/HyperSpec/Body/t_fixnum.htm"><code>fixnum</code></a>
range, while in the first case we have no way of intercepting or
translating the <em>host</em>’s value of <code>most-positive-fixnum</code>. Special
mentions go to
<a href="http://www.lispworks.com/reference/HyperSpec/Body/v_ar_dim.htm"><code>array-dimension-limit</code></a>,
which caused Bill Newman to be
<a href="http://www.advogato.org/person/wnewman/diary/21.html">cross on the Internet</a>,
and to
<a href="http://www.lispworks.com/reference/HyperSpec/Body/v_intern.htm"><code>internal-time-units-per-second</code></a>;
I ended up tracking down one difference in output machine code from
a leak of the host’s value of that constant into target code.</li>
<li>Similarly,
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_random.htm"><code>random</code></a>
and
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_sxhash.htm"><code>sxhash</code></a>
quite justifiably differ between implementations. The practical
upshot of that is that these functions can’t be used to implement a
cache in SBCL!Compiler, because the access patterns and hence the
patterns of cache hits and misses will be different depending on the
host implementation.</li>
<li>As I’ve already mentioned,
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_maphas.htm"><code>maphash</code></a>
does not iterate over hash-table contents in a specified order, and
in fact that order need not be deterministic; similarly,
<a href="http://www.lispworks.com/reference/HyperSpec/Body/m_w_pkg_.htm"><code>with-package-iterator</code></a>
can generate symbols in arbitrary orders, and set operations
(<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_isec_.htm"><code>intersection</code></a>,
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_set_di.htm"><code>set-difference</code></a>
and friends) will return the set as a list whose elements are in an
arbitrary order. Incautious use of these functions tended to give
rise to harmless but sometimes hard-to-diagnose differences in
output; the solution was typically to sort the iteration output
before operating on any of it, to introduce determinism...</li>
<li>... but it was possible to get that wrong in a harder-to-detect way,
because
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_sort_.htm"><code>sort</code></a>
isnot specified to be stable. In some implementations, it actually
<em>is</em> a stable sort in some conditions, but for cases where it’s
important to preserve an already-existing partial order,
<code>stable-sort</code> is the tool for the job.</li>
<li>The language specification explicitly says that the initial contents
of uninitialized arrays are undefined. In most implementations, at
most times, executing <code>(make-array 8 :element-type (unsigned-byte
8))</code> will give a zero-filled array, but there are circumstances in
some implementations where the returned array will have arbitrary
data.</li>
<li>Not only are some constants implementation-defined, but so also are
the effects of normal operation on some variables.
<a href="http://www.lispworks.com/reference/HyperSpec/Body/v_gensym.htm"><code>*gensym-counter*</code></a>
is affected by macroexpansion if the macro function calls <code>gensym</code>,
and implementations are permitted to macroexpand macros an arbitrary
number of times. That means that our use of <code>gensym</code> needs to be
immune to whatever the host implementation’s macroexpansion and
evaluation strategy is.</li>
<li>The object returned by
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_by_by.htm"><code>byte</code></a>
to represent a bitfield with size and position is
implementation-defined. Implementations (variously) return
bitmasks, conses, structures, vectors; host return values of <code>byte</code>
must not be used during the execution of SBCL!Compiler. More
subtly, the various
<a href="http://www.lispworks.com/reference/HyperSpec/Body/f_boole.htm"><code>boole</code></a>-related
constants
(<a href="http://www.lispworks.com/reference/HyperSpec/Body/v_b_1_b.htm"><code>boole-and</code></a>
and friends) also need special treatment; at one point, their host
values were used when SBCL!Compiler compiled the <code>boole</code> function
itself, and it so happens that CLISP and SBCL both represent the
constants as integers between 0 and 15... but with a different
mapping between operation and integer.</li>
<li>my <a href="http://christophe.rhodes.io/notes/blog/posts/2014/still_working_on_reproducible_builds/">last blog entry</a> talked
about constant coalescing, and about printing of <code>(quote foo)</code>. In
fact printing in general has been a pain, and there are still
significant differences in interpretation or at least in
implementation of pretty-printing: to the extent that at one point
we had to minimize printing <em>at all</em> in order for the build to
complete under some implementations.</li>
<li>there are a number of things which are implementation-defined but
have caused a certain amount of difficulty. Floating point in
general is a problem, not completely solved (SBCL will not build
correctly if its host doesn’t have distinct single- and double-float
types that are at least approximately IEEE754-compliant). Some
implementations lack denormalized numbers; some do not expose signed
zeros to the user; and some implementations compute <code>(log 2d0 10d0)</code>
more accurately than others, including SBCL itself, do. The
behaviour of the host implementation on legal but dubious code is
also potentially tricky: SBCL’s build treats full
<a href="http://www.lispworks.com/reference/HyperSpec/Body/e_warnin.htm"><code>warning</code></a>s
as worthy of stopping, but some hosts emit full warnings for
constructs that are tricky to write in other ways: for example to
write portable code to handle multiple kinds of string, one might
write <code>(typecase string (simple-base-string ...) ((simple-array
character (*)) ...)) (string ...))</code> but some implementations emit
full <code>warning</code>s if a clause in a
<a href="http://www.lispworks.com/reference/HyperSpec/Body/m_tpcase.htm"><code>typecase</code></a>
is completely shadowed by other clauses, and if
<a href="http://www.lispworks.com/reference/HyperSpec/Body/t_base_c.htm"><code>base-char</code></a>
and
<a href="http://www.lispworks.com/reference/HyperSpec/Body/a_ch.htm"><code>character</code></a>
are identical in that implementation the <code>typecase</code> above will
signal.</li>
</ul>
<p>There were probably other, more minor differences between
implementations, but the above list gives a flavour of the things that
needed doing in order to get to this point, where we have <em>some</em>
assurance that our code is behaving as intended. And all of this is a
month ahead of my self-imposed deadline of SBCL’s 15th birthday: SBCL
was <a href="http://sbcl10.sbcl.org/sbcl-0.0">announced to the world</a> on
December 14th, 1999. (I’m hoping to be able to put on an sbcl15
workshop in conjunction with the
<a href="http://www.european-lisp-symposium.org/">European Lisp Symposium</a>
around April 20th/21st/22nd – if that sounds interesting, please
pencil the dates in the diary and let me know...)</p>
european lisp symposium 2014http://christophe.rhodes.io/notes/blog/posts/2014/european_lisp_symposium_2014/2014-11-08T22:38:14Z2014-05-14T11:23:23Z
<p>My <a href="http://christophe.rhodes.io/notes/blog/posts/2014/on_my_way_to_els2014/">train ride to Paris</a> was uneventful, and I
arrived at my accommodation only several hours after bedtime. I <em>did</em>
manage to write my talk, and it was good to discover the number of
<s>obsessive</s> <a href="http://planet.lisp.org/">planet.lisp</a> readers when I
showed up to register – “good to see you again. How’s the talk?” was
the median greeting. For the record, I had not only written my talk
on the train but also had a chance to relax a little. Go trains.</p>
<p>The conference was fun; gatherings of like-minded people usually are,
but of course it takes substantial effort from determined people to
create the conditions for that to happen. Kent’s work as programme
chair, both before and during the conference, came with a feeling of
apparent serenity while never for a moment looking out of control, and
the groundwork that the local organizing team (Didier Verna, Gérard
Assayag and Sylvie Benoit) had done meant that even the problem of the
registrations exceeding the maximum capacity of the room – nice
problem to have! – could be dealt with.</p>
<p>I liked the variety in the keynotes. It was very interesting to hear
<a href="http://www.dreamsongs.com/">Richard Gabriel</a>’s talk on his research
in mood in Natural Language processing and generation; in many ways,
those research directions are similar to those in the Transforming
Musicology world. The distinction he drew between programming for a
purpose and programming for exploration was very clear, too: he made
it clear that he considered them two completely different things, and
with my hat as a researcher on I have to agree: usually when I'm
programming for research I don’t know what I'm doing, and the domain
of investigation is so <em>obviously</em> more unknown than the program
structure that I had better have a malleable environment, so that I
can minimize the cost of going down the wrong path.
<a href="http://www.p-cos.net/">Pascal Costanza</a> gave a clear and detailed
view of the problems in parallel programming, drawing a distinction
between parallelism and concurrency, and happened to use examples from
several of my previous lives (Smooth-Particle Hydrodynamics, Sequence
Alignment) to illustrate his points.
<a href="http://quotenil.com/">Gábor Melis</a> talked about his own learning and
practice in the context of machine learning, with a particular focus
on his enviable competition record; his call to aim for the right-hand
side of the curves (representing clear understanding and maximum
use-case coverage) was accompanied by announcements of two libraries,
<a href="https://github.com/melisgl/mgl-pax">mgl-pax</a> and
<a href="https://github.com/melisgl/mgl-mat">mgl-mat</a>.</p>
<p>My own presentation was, I suppose, competent enough
(<a href="http://christophe.rhodes.io/notes/blog/posts/2014/european_lisp_symposium_2014/slides.pdf">slides</a>). Afterwards, I had a good talk with my
previous co-author in the generalizes research line, Jim Newton, about
the details, and Gábor told me he’d like to try it “on by default”.
But the perils of trying to get across a highly-technical topic
struck, and I got a number of comments of the form that the talk had
been enjoyable but I’d “lost them at
<a href="http://mop.lisp.se/dictionary.html#compute-applicable-methods-using-classes"><code>compute-applicable-methods-using-classes</code></a>”.
I suppose I could still win if the talk was enjoyable <em>enough</em> for
them to read and work through the paper; maybe next time I might risk
the demo effect rather more than I did and actually do some
programming live on stage, to help ground the ideas in people’s minds.
I did get a specific request: to write a blog post about
<a href="http://www.lispworks.com/reference/HyperSpec/Body/s_eval_w.htm"><code>eval-when</code></a>
in the context of metaobject programming, and hopefully I'll find time
for the in the next few train journeys...</p>
<p>Meanwhile, highlights (for me) among the contributed papers:
<a href="http://enlivend.livejournal.com/">Nick Levine</a> driving Lispworks’
CAPI graphical user interface library from SBCL using his
<a href="http://www.nicklevine.org/claude/claude-1.0.2/manual/">Common Lisp AUdience Expansion</a>
toolkit (preaching to the choir, though: his real target is Python
developers); <a href="http://fare.livejournal.com/">Faré Rideau</a>’s description
of a
<a href="http://fare.livejournal.com/176185.html">decade-long exploration of defsystem design space</a>;
François-Xavier Bois’ demonstration of
<a href="http://web-mode.org/"><code>web-mode.el</code></a>, an Emacs mode capable of
handling CSS, Javascript and PHP simultaneously; and two talks
motivated by pedagogy: Pedro Ramos’ discussion of the design tradeoffs
involved in an implementation of Python in Racket, and the team
presentation of the approach taken for a new robotics- and
Scheme-oriented undergraduate first-year at Middlesex University, on
which more in a subsequent post.</p>
<p>Lightning talks of particular note to me: Martin Simmons talking about
<a href="http://www.lispworks.com/">Lispworks</a> for mobile; Didier Verna and
Marco Antoniotti talking about their respective
<a href="https://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt">documentation</a>
<a href="http://helambdap.sourceforge.net/">generation</a> systems
(<a href="https://twitter.com/ascii19/status/463347894326939648">my response</a>);
Mikhail Raskin’s argument about the opportunity to push
<a href="http://julialang.org/">Julia</a> in a lispy direction; and probably
others which will come back to mind later.</p>
<p>I was also pleased to be able to contribute to the last full session
of the symposium, a workshop/panel about Lisp in the area of music
applications: an area which is serendipitously close to the day job.
I worked on getting a version of audioDB, our feature-vector search
engine for similarity matching, built and working on my laptop, and
finding a sufficiently interesting search among my Gombert/Josquin
collection to demo – and I also had the chance to talk about
<a href="http://research.gold.ac.uk/9547/">Raymond Whorley’s work</a> on using
multiple viewpoint systems for hymn harmonizations, and what that
teaches us about how people do it (<a href="http://christophe.rhodes.io/notes/blog/posts/2014/european_lisp_symposium_2014/music-slides.pdf">slides</a>, for
what they're worth). Other systems of interest in the session
included <a href="http://repmus.ircam.fr/openmusic/home">OpenMusic</a> (of
course, given <a href="http://www.ircam.fr/">where we were</a>),
<a href="http://www2.siba.fi/PWGL/">PWGL</a>,
<a href="http://repmus.ircam.fr/omax/home">OMax</a>, modalys, and
<a href="http://overtone.github.io/">overtone</a>; there was an interesting
conversation about whether the choice of implementation language was
restricting the userbase, particularly for tools such as OpenMusic
where the normal interface is a graphical one but a large fraction of
users end up wanting to customize behaviour or implement their own
custom patches.</p>
<p>And then it was all over bar the dinner! On a boat, sadly immobile,
but with good conversation and good company. The walk home in company
was fun, though in retrospect it was probably a mistake to stop off at
<a href="http://www.larhumerie.com/">a bar</a> for a nightcap... the train
journey back to the UK the following morning was definitely less
productive than it could have been; closing eyes and letting the world
go past was <em>much</em> more attractive.</p>
<p>But now I'm on another train, going off to record the complete works
of Bernadino de Ribera. Productivity yay.</p>
on my way to els2014http://christophe.rhodes.io/notes/blog/posts/2014/on_my_way_to_els2014/2014-11-08T22:38:14Z2014-05-04T17:48:41Z
<p>After a packed weekend of music-making with
<a href="http://www.deprofundis.org.uk/">De Profundis</a> (go
<a href="http://www.adcticketing.com/whats-on/concert/weeping-in-sharps-and-flats.aspx">buy tickets</a>!),
I’m now at St Pancras, waiting for a train to Paris to go to the
<a href="http://www.european-lisp-symposium.org/">European Lisp Symposium</a>,
where I’ll be presenting my work (with Jan Moringen and David
Lichteblau) on
<a href="http://research.gold.ac.uk/9924/">generalizer metaobjects</a>. I’m
looking forward to the event: it’s being held at
<a href="http://www.ircam.fr/">IRCAM</a>, which as an institution neatly combines
two of my interests (computing and music) – there’s going to be a
special session on Tuesday on Lisp and composition, though I might try
to participate and broaden it a bit to talk about some of our current
problems and approaches in
<a href="http://www.transforming-musicology.org/">Transforming Musicology</a>.</p>
<p>I’m not (yet) looking forward to my talk. Over the next few hours,
I’m going to be putting to the test my current belief that I am most
productive on trains, because I haven’t yet written my talk, and it
turns out that I am in the first session tomorow morning. (I know, I
know, this is the sound of
<a href="http://boingboing.net/2010/06/05/worlds-tiniest-open.html">the world’s tiniest violin</a>).
2h20 should be enough fo anyone.</p>
<p>The flip side of the stress of being first is the ability to enjoy the
rest of the symposium <em>without</em> the stress of an upcoming presentation
hanging over me – as well as the ability to ask <s>nasty</s> difficult
and probing questions without too much fear of instant reprisal. (I
suppose that by putting this out there before the talk I open myself
up to pre-reprisals; all I can say is that I welcome a constructive
and robust exchange of views: there is definitely more work to be done
in the world of extended dispatch, and suggestions will be welcome.)</p>
<p>And of course it <em>will</em> be good to meet up with a community of
like-minded people; I may not be highly active in the Lisp world these
days (though I have been making an effort to be more engaged with at
least the <a href="http://www.sbcl.org/">SBCL</a> team for more than the one day
a month of release activity, and it’s been fun to watch the
<a href="http://christophe.rhodes.io/notes/blog/posts/2014/just_like_old_times/">ARM port progress on <code>#sbcl</code></a>) but I retain a
good helping of interest in what’s going on, and it will be great to
meet up with old friends and maybe even to make new ones.
(Registration got to the room capacity <em>very</em> quickly, and hopefully
the overflow room will have a good atmosphere too). Hopefully the
conversations I have and ideas generated will mean that I have a
productive train ride <em>back</em>, too!</p>