

Installing Clozure Common Lisp on the Raspberry Pi - jk4930
http://lispm.dyndns.org/ccl

======
ChuckMcM
This is really nice. It would have been even cooler if it was running on the
HDMI attached monitor, and then massively cooler if you could write list
primitives that would let you draw on the screen, then you create an entire
environment written in lisp (or smalltalk, or forth).

If you are reading this and you work for Broadcom of have some sway there, why
not encourage them to make that possible by freeing the GPU from its
proprietary bindings.

~~~
jsnell
[https://plus.google.com/101473924494271635476/posts/2LDwW4xz...](https://plus.google.com/101473924494271635476/posts/2LDwW4xzaJf)

(CCL mapping the framebuffer into memory, using existing Lisp libraries to
draw graphics into it).

~~~
ChuckMcM
From: Hans HübnerSep 10, 2012 (OP of that G+ post)

 _I have not looked into OpenGL, but it'd certainly be good to have a faster
way to draw on the screen. VECTO and bitmap copying is not suitable for
anything that is supposed to move.﻿_

This is my experience as well. You can mmap /dev/fb0 and draw on it, and you
can use something like directfb or even Cairo if you're not into lisp, but if
you want to do even trivial 2D acceleration you are out of luck.

~~~
jsnell
Re-rasterizing and blitting the whole screen on every change is clearly
unacceptable, but there's a large gap between that and outright HW
acceleration. Being smarter about redraws gets you a long way. I have used
things like web browsers on unaccelerated X11, and it's been totally usable
even on ARM.

~~~
mhd
But apart from educational purposes, why would you do that? Sure, the graphics
driver is an ugly blob, but if you care that much about libre
hardware/software, it would be odd buying an Raspberry Pi in the first place.

Granted, "for educational reasons" is a valid subject for the Pi. Get that old
Abrash book out and let the OpenGL-spoiled kids feel the pain.

------
sedachv
CCL also runs on Android:
<http://thread.gmane.org/gmane.lisp.openmcl.devel/7511>

David Lichteblau got it and Hemlock (an Emacs in CL) running on a tablet:

[https://twitter.com/i/#!/lichteblau/media/slideshow?url=http...](https://twitter.com/i/#!/lichteblau/media/slideshow?url=http%3A%2F%2Ftwitpic.com%2F9b2drs)

Althought he said that Hemlock on a tablet wasn't particularly useful, when I
asked him about it.

------
dschiptsov
This is what brilliant design is all about.

This lisp system has a small kernel, and almost entirely written in Lisp, so
it is extremely efficient and portable.

SBCL and MIT Scheme has a similar architecture and could be easily ported.

Now, what about rebuilding openjdk-1.7.0?)) And then run, say, mvn install
clojure?))

~~~
jsnell
A SBCL port to a new architecture is far from easy.

Portability might have been a design goal, but ease of porting wasn't. The
amount of platform-specific code is only small in relation to the system as a
whole. In the classic paper describing CMUCL, Rob MacLachlan has a great line
about "porting taking 2-4 wizard-months". Things have progressed a bit since
then, so you don't need a wizard. But the time estimate is probably still
valid.

So why is it a non-trivial task? Well, first of all you'll need to add
instruction descriptions so that the table-driven assembler and disassembler
work for that new arch. There might be regularities in the instruction set
that make this easier, but on the other hand any mistakes will make debugging
much harder than you'd like.

Then you get to translate 5k-10k lines of assembler templates from whatever
existing backend you decided to start from. That's actually just tedious, not
hard, unless none of the backends is really close. My understanding is that
ARM has lots of warts about e.g. which values are easily representable as
immediate values. Some parts of this work will be trickier, like adding the
support for the platform's native ABI.

That gets you far enough to theoretically compile the system. It will almost
certainly crash on startup, before it has even managed to load enough of the
state required for debugging itself. So the workflow will consist of figuring
out where something odd is happening, and then collecting and cross-
correlating various bits of information (single stepping in gdb, gdb
disassemblies, annotated assembler code from the compiler) around the
problematic bit of code.

There will be dozens of bugs like that between this stage and a working Lisp
prompt. The first time floating point code gets used, or the first time the
compiler is called during the startup, the first explicit call to C code, the
first call the garbage collector (or rather what happens sometime right after
the first call, when e.g. the GC has mangled some relocations), etc. Doing the
bring-up for a merely compiling SBCL port was probably the hardest programming
I've ever done.

I'd bet that none of the CCL ports were just "easy" either.

~~~
dschiptsov
Thank you for a detailed reply, nice to read.

A small hack could be using a very modern sophisticated clang compiler, to
produce an optimized assembly for an idiom you need, coded in C. Like clang -S
a.c then you change and hard-code what you like.

Yes, it is a non-trivial task, so, it might make you much better engineer,
like a difficult journey into unknown improves you.

------
larme
I don't have a Raspberry Pi to test it. But I think ECL may fit better because
of its small footprint: <http://ecls.sourceforge.net>

~~~
lispm
Clozure CL does fine. This the CCL process which runs the CL-HTTP web server
on my Raspberry Pi:

    
    
        PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
       6573 pi        20   0  546m  36m 7580 S   1.6 19.8   1:55.26 armcl

------
rogerclark
what about installing Clojure on the Raspberry Pi, or what about installing
Google Closure on the Raspberry Pi

~~~
jrockway
Yes, it's certainly a popular programming language name. Clozure does predate
both of the others, however.

