X server in 5000 lines of Common Lisp

https://github.com/pyb/zen

by luu • 13 years ago

136 66 13 years ago

github.com

apetresc• 13 years ago

One of the prerequisites for using this is, apparently, an already-running X server.

dman2• 13 years ago

Can this restriction be removed using EGL ?

pyb4• 13 years ago

In principle yes

bane• 13 years ago

So by implementing none of the hard bits, LISP wins again!

dman2• 13 years ago

Lisp featured support for Garbage collection, exceptions done right, macros, optional typing, native compilation. In fact I would argue that many in the lisp community were so obsessed with the hard bits that they overlooked building simple things that see everyday use in the real world.

juliangoldsmith• 13 years ago

It's not that it doesn't implement the hard bits, it just re-implements the hard bits on top of the hard bits. It requires an OpenGL context, which generally requires you to have an X server running.

pubby• 13 years ago

It should have been written using lazy evaluation. That way, it could use itself recursively as its own X server. /sarcasm

jfoutz• 13 years ago

I think Haskell has the market cornered on tying the knot. http://www.haskell.org/haskellwiki/Tying_the_Knot

hga2• 13 years ago

Well, according to the Readme, it's a "decent OpenGL driver" which then means "unfortunately, a running X server :) (to create a GLX context)"

aidenn0• 13 years ago

Apparently this is 3 years old.

ritchiea• 13 years ago

Cool though it's going to be egg on OP's face when someone else implements this in 12 lines of Javascript

kursiv• 13 years ago

and subsequently in 0 lines of js.

girvo• 13 years ago

The OP was already in 0 lines of js.

nl• 13 years ago

VNC in JS is done[1] (the VNC display is ~700 lines), so X might actually be doable...

[1]https://github.com/kanaka/noVNC

10098• 13 years ago

Wait, you need an X server to run it? What's the point then?

_delirium• 13 years ago

It looks like it just uses an existing X server as a way to create an OpenGL context, not as an X server per se. Perhaps it would be possible to port it to some non-X method of producing an OpenGL context, such as EGL.

pyb4• 13 years ago

Yes that's the idea

OGC• 13 years ago

So its a really hard way to run an X server on top of an X server?

dmytrish3• 13 years ago

Because this glosses over the really complex parts. Still, if they are written in Lisp, this would comprise a complete self-sufficient X server (how many lines of code this would take though?).

elwell• 13 years ago

Isn't Lisp really hard to understand? Or is it just because I'm unfamiliar with the syntax?

S4M2• 13 years ago

I guess it's you who is just unfamiliar with the syntax. Do you find (+ 2 2) harder to understand that 2+2?

If the code is well indented, IMHO it's quite understandable. For example, what do you think of this Lisp code snippet (it's not the best possible code, just some stuff I have at hand to show without you needing to know the context):

    ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0]
    ;;l1[1] l2[1] ...)
    (defun mix (l1 l2)
      (if (null l1) nil
          (append (mix (cdr l1) (cdr l2)) (list (car l1) (car l2)))))

EDIT: formatted the code as per gcr suggestion.

gcr3• 13 years ago

In HN, use four spaces to indent code blocks, like this:

    ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0]
    ;;l1[1] l2[1] ...)
    (defun mix (l1 l2)
      (if (null l1)
          nil
          (append (mix (cdr l1)
                       (cdr l2))
                  (list (car l1)
                        (car l2)))))

(Also, for the record, you should say (append (list ...) (mix ...)) or else you'll reverse the result list, which I don't think is your intent)

jwmc• 13 years ago

German is really hard to understand. I imagine the user lispm would have something to say about that.

phaer2• 13 years ago

It's easy, the trick is to learn it as your first language ;)

cjo• 13 years ago

I think it's easier to reason about in the long run although the initial period of wondering why you don't just set up a data structure and bang on it in place is a little bumpy.

The syntax is always[0] (procedure argument-1 argument-2 ...) where the procedure is applied to the arguments.

about half-hour in to this lecture the syntax is explained: http://ocw.mit.edu/courses/electrical-engineering-and-comput...

[0] - almost always. Macros look the same and often get treated the same but they are very different.

ufo• 13 years ago

LISPers know the syntax is clunky but they are OK with it because it makes it super easy to create macros.

agumonkey2• 13 years ago

I never found it clunky, at worst blurry (only one visible syntactic marker) but it was pretty beautiful and timeless.

Beside macros, with non string-buffer editors, you get very very fast and calm typing or I should say low level refactoring.

Finally it has this weird quality of really looking like static data (relation v1 v2 v3) most of the time and really not like a cryptic (by the number of delimiters {} () , ; ) state dependent imperative notation. Makes you really think about how to interpret data rather than send commands to a machine.

f7t7ft7• 13 years ago

No, you just have to try...and of course practice if you want to get any good at it.

agumonkey2• 13 years ago

Also building many things on top of ~persistent cons cells / linked lists. Found it quite awkward the first time I saw it.

dmytrish3• 13 years ago

The syntax is very minimalistic at cost of much more semantical burden. Parsing Lisp code for humans often relies on conscious understanding the words and AST structure, not on reflexes tied to a visual memory of characters and indents. So I think that Lisps are at odds with human perception (someone may consider this an advantage: this repels people who code with their cerebellum instead of cerebral cortex). But once you have a picture of what is the code about in your head, it's not a big deal.

SimHacker2• 13 years ago

Lisp's syntax is the easiest thing about it to understand. In fact, Lisp's syntax is so easy to understand, that even Lisp can understand its own syntax.

daemonize• 13 years ago

Good luck groking that mess.

gcr3• 13 years ago

It's hard to grok low-level code like this in any language. I'd take common lisp over heavily-templated C++ or freestyle Perl any day.

koenigdavidmj• 13 years ago

Banging on file descriptors looks pretty much the same no matter what language you do it in. I expect that a Python equivalent would be pretty much the same length.

pyb4• 13 years ago

I actually left this project alone after I got the very basics running... It's very very slow and rather buggy. I guess a profiling run could help a lot though.

sytelus• 13 years ago

To me 5000 lines of C code is a LOT of code. Linus's first release of Linux was only 10,000 lines of code. Given much higher expressiveness of Lisp, I think 5000 lines of List code is not all that to boast about. I can't pull a reference here but according to one of the studies, the productivity of some of the well known programmers was measured at 10K LOC/year (yes, it's very loose measure of "productivity"). So writing 5000 lines of good code may require ~6 months, i.e., not a trivial amount of work. Although I agree it is cool to have X server in Lisp.

varjag• 13 years ago

5000 lines isn't really a lot for a real-life project in any language. Besides, a lot of the code here seems to be in the data.

E.g. https://github.com/pyb/zen/blob/master/data/request-specs.li... describes X spec request syntax, accounts alone for nearly 1000 lines, and it's not really possible to trim down.

dmytrish3• 13 years ago

Agreed, I was surprised how many code Slime implementation has, there are source files about several kloc in size. From what I saw I can say that "lisp expressiveness" did not helped much there.

qbrass• 13 years ago

Here's Xorg's nested X server if you want to see how much C code it takes.

http://cgit.freedesktop.org/xorg/xserver/tree/hw/kdrive/ephy...

X server in 5000 lines of Common Lisp

Related Stories