I got the information that the branch I used in the previous version is an older one and that I should migrate to the so called thomas branch.

So I did it and now it seems that all examples are working. Ok … the varray example is not working. It somehow is not willing to compile for me and I am too lazy to look into this problem. (perhaps next time)

You can get it here.

Have fun!

I have adapted the cl-opengl bindings so that it runs with the GLUT bundle that is being shipped with mac os x.

Most examples seem to work. The ones that do not work need a more complicated fixing. But the API should run correctly. (I hope so ™)

You can get the first version here.

I will try to continue testing and fixing the bindings. I i do so there will probably be also a repository for it. Who knows … ^^

I have tested it with sbcl 1.0.12 on a Leopard driven MacBook Pro.

Have fun

P.S. Greetings from 24c3 ^^

P.P.S … I made a screenshot that is attempting to proove that it is really working: shot

After a long time finally a new entry here.

Some time ago I owned a Powerbook 15″. This one had a problem with its second ram slot. It was not detected by the system. I called Apple Care but they were not willing to fix that. I really was upset about that because it was a known problem. Still the serial number of my Powerbook was not in the range Apple considered affected by that problem. >_< Now I have a MacBook Pro 17″ and some days ago my battery grew to its double size. Yes just like the one in this article here. I realized that only because my touch pad button was not clicking anymore and when I put my hand near the touch pad it triggered the button. Searching the web showed the article at Gizmodo above. I looked at the back of my laptop and was shocked.

Yesterday I called Equinux and asked what can be done. They checked my Serial number and said that I should bring my laptop over. So directly after work I went there and without much asking they took my battery and said that they will replace it. (That is something that I was not expecting after my experiances with my Powerbook.)

As I was already there I pointed out a little cosmetic problem I had. The band underneath the keyboard weared off and lost its matt look just some weeks after I got my Macbook. (I will post a picture of it later.) They also said with no hesitation that they will replace the whole top if I want to. The problem I have is that I need my laptop all the time for my work so I can not leave it even for a day for fixing. So they said that they will make a appointment with me so I can come over and the technician will replace it in one hour. That is what I call service.

Now they showed me that Apple can also have a very good support as long as you have a guarantee coverage on your hardware. I can only say that I am very happy that I bought Apple Care along with the MacBook. That will save me lots of money and annoyance in the future.

Ok I am back with one more rant on Lisp.

Because of an idea I have, that is not yet ripe for decision, I was trying to get a graphics library that is portable and has a Common Lisp binding. Finally I got stuck on opengl and cl-opengl binding. I had a hard time getting it to run on Mac OS X so I tried it on Linux first where it worked out of the box. It is pretty nice even if making a mistake sometimes kills your lisp.

To install cl-opengl you need a Common Lisp implementation (I use sbcl), cffi (I used cffi 0.9.1), an opengl library (I used the one shipping with Mac OS X) and GLUT (I used OpenGLUT but more on that later).

First I tried to get cl-opengl running with the native Mac OS X GLUT implementation but it did not work. I found information on the cl-opengl list that you need FreeGLUT. The problem with FreeGLUT is that it does not compile on Mac because of some joistick problems.

So… get the source tarball of OpenGLUT.

Untar it and run “CPPFLAGS=”-I/usr/X11R6/include” ./configure”. You need the CPPFLAGS variable because otherwise the build system will not find the right opengl headers.

Now run make and make install. In my case I added the option –prefix=/opt/mine to configure to not taint the running system with self compiled stuff.

Finally you should end up with OpenGLUT libraries.

Now download cl-opengl (probably using darcs “darcs get http://www.common-lisp.net/project/cl-opengl/darcs/cl-opengl/”)

Link the .asd files to your sbcl systems directory:
# ln -s ~/cl-opengl/*.asd ~/.sbcl/systems

The problem with OpenGLUT is that it uses X11 to create windows. So you have to start the Mac OS X X11 server and start sbcl in the xterm within X11.
After starting sbcl you can run at the repl the following:
* (asdf:operate ‘asdf:load-op ‘cl-glut-examples)

That should compile and load the cl-opengl cl-glut and cl-glu bindings and also cl-glut-examples.

Now you should be able to test it running:
* (cl-glut-examples:gears)

on the sbcl repl.

Conclusion:

cl-opengl binding is really nice. It still needs work so that it catches all errors that may occur. Doing something unpredicted with opengl may cause your lisp process to crash.
It also requires at least FreeGLUT that is not willing to compile on Mac OS X but that is understandable because GLUT itself misses some features that are required to create really dynamic applications what is what you want. OpenGLUT does compile on Mac OS X but seems to be pretty old (2005 last release) and just like FreeGLUT requires X11. That is really nasty. I do not want X11 :(

It is usable it is pretty nice but there still is a lot to do! I will for sure dive more into that stuff and try to fix at least some of the problems I found.

But nonetheless thanks OpenGLUT and cl-opengl guys for your fine work! Now I can finally create some nice graphical stuff! Woot!

One more thing… the cl-glut-examples:gears demo gives the following frame rates on my MacBook Pro:
23857 frames in 5.0 seconds = 4771.400 FPS
24407 frames in 5.0 seconds = 4881.400 FPS
24316 frames in 5.0 seconds = 4863.200 FPS
24293 frames in 5.0 seconds = 4858.600 FPS

I think it is amazing! Tell me what framerates you get! ;)

Some days ago I watched some Lisp Machine Videos. These films show what it was like to use a lisp machine and code on it.

I really have to admit that I was not surprised to see what wonderful ideas the guys had back then. Current OS’s still have a long way to go to incorporate (copy) the functionality you had 20 years ago in LispM Operating systems like Genera. Apple as always is on the front line of incorporating this old stuff. For example Time Machine. The new feature that will be there in Leopard (the next version of Mac OS X). The idea of easily going back in time and looking at your files was there 20 year ago.

Still as I now know Time Machine is still far away from the idea the LispM developers had. There you had a filesystem that had versioning built in. You can tell you do not save files just like that. You save patches to your files. That is somehow comparable to having SVN as your filesystem. Just a bit more sophisticated.

Sure that is not the only thing. There are tons of others. Like objects that are mouse sensitive depending on what you are doing. Accessing the displayed object structures that are behind that what you see. And many more…

I do not want to let myself get carried away too much. The condensed idea I wanted to share with you is the following. Genera is amazing. And if you think that any currently known OS is cool then you know nothing. And if you think that Java and Eclipse are cool then you live in the stone age in the matter of knowledge.

Sit down, learn lisp. It may hurt at first, but the freedom is worth it. Others had to pay their lives for freedom and you only have to learn.

Yesterday and the day before Uwe and I were trying to flash an R8C and alternatively an M16C under Linux. We were finally successful using the Flasher from Thomas Fischl. You have to be careful to get the one on his site not the original from Lost In The Ether. The original seems to be somewhat broken.

Still there are some points you should be careful about. First of all the image you want to flash has to be for R8C or M16C respectively. The problem is that the addresses contained in the images have different order (endianes) depending on the chip. The sample srecord image contained in the tarball from Fischl is for _M16C_ and _NOT_ R8C.

Next thing is you should try to use a real hardware serial interface if you get problems with a serial to usb converter. We found out that even if the converter contains a prolific usb to serial chip it does not mean that it will work. We have two cables here and we know that Sitecom works.

We will probably write a patch for the flasher program containing some additional documentation and some checks and timeouts. The checks should validate the addresses one wants to flash are valid for the chip, and the program should timeout if it does not get data back from the chip during flashing. At least that is our TODO.

More information to come. ;)

[Update] Added some links.

Today I found something pretty nice a Lisp interpreter in Java Script.

I came to it through logowiki. I found it pretty amazing that you can run the example programs you have in your wiki. So I asked google about it.

The interpreter lacks some functionality like defun, defmacro and so on but I think it would be a nice base for creating logowiki like interpreter. I have not read the source yet but I think it may be a nice way to show someone how to create a simple lisp interpreter.

I continued my reading about Lisp and also searched the Web a bit more for anything related to Embedded Systems. I think that this is a pretty sad story.

I heard from a friend that I missed ecls in my last post. He said that it is possible to compile Lisp to C with it and then you can crosscompile the resulting C source to any architecture you like. But that simply does not feel right. That is only a hack. You miss the things you want the most (beside Lisp itself) REPL and with it the integrated inspector and debugger just like the profiler and tracer. Also you miss binary upload of functions. Think for yourself. If you do not have that things does development with lisp feel like it should? If you ask me it does not.

So I searched further. I knew that there was someone who developed the triple L, Mars and Venus. I did not know what it exactly was but I knew that it was a lisp development environment for embedded systems.

Looking more in depth in to that, I had to realize that the only thing that exists is the paper L - A Common Lisp for Embedded Systems (pdf format is here) by Rodney A. Brooks and Charles Rosenberg. This paper is telling a beautiful story about a development system that would be the thing one would like to have. But you can not get it anywhere! On the page of Charles Rosenberg you find the pointer that the company IS Robots (that was developing L, Mars and Venus) is now iRobot (yes the Roomba guys). Searching their site does not say anything about lisp though.

The only other person bringing iRobot together with Lisp is Lemindor I have not read all his posts yet but he does not really say anything that helps me neither.

I also asked about the topic in #lisp on freenode but it seems that the overall opinion is that everyone is brewing his own Lisp if he/her wants to use lisp on embedded system.

That is really bad news. I was hoping that there will be something I will be able to base on. The only solution that I see now is to take some common lisp implementation and port it to some embedded system. And when it works start changing it and splitting in parts so that it fits development on embedded systems. (you do not really want the compiler on your embedded system normally an interpreter is enough)

That somehow sounds pretty big and heavy. :(

The second solution would be to start with a small Lisp implementation by oneself. When you read Paul Graham’s article Roots of Lisp you get the feeling that it can not be that hard. But still I think that is probably a false feeling. But if I had the power and money to hire some people that are bright enough I think I would attack that. I even know some people that are bright and that would be able to create such thing but none of them would want to invest their time in such a project when they do not get money for that. So there is high possibility that Lisp on embedded systems will remain a dream. :(

I had a very inspiring conversation today. I was trying to lay out why one should learn Lisp. I found that there are tons of reasons why Lisp is superior to other Languages. But I found some articles in the web that can explain that much better then me. There are some Articles written by Paul Graham that describe the reasons beautifully. For example “If Lisp is So Great” or “Revange of the Nerds“. I can only encourage you to read them.

What I found very interesting is the main statement of these Articles. Popularity of a Language is not the same as greatness as very well explained in the second Article. Another statement is that programming languages are slowly closing up with functionality and paradigms found in lisp. That is also one of the reasons why I started learning it, because I heard about that trend some time ago somewhere in the big depths of the net.

Most articles are stating that Lisp is the way to go to create web applications and financial systems. But I would even go further. I think it is also the way to go for embedded systems. Some people may think that Lisp is too big and too slow to use it for development on embedded systems. But look at your cellphone. It will probably have a JVM (Java Virtual Machine) running on it. What is that thing? It is a full emulation of a system. It runs bytecode. It is slow like hell but people still develop applications for cellphones compleatly written in java. I bet that there are phones that have their entire software written in Java. Now we look at Lisp. I found a comparison between JDK and SBCL here. It really seems that Java is faster and uses up less memory in most cases. At least taking a glimpse on the Graph. But as I already posted before. SBCL is not perfect. But there are developments like “Headless” coming that will better up that situation. On another site I found that the commercial Allegro Common Lisp implementation is the fastest. But sadly I do not see any benchmarks anywhere. And it does not support any embedded system.

I think that even if the benchmarks show that Lisp may be less efficient in speed and memory usage, it is only a matter of time and dedication to change that. But what do you buy with that loss of efficiency anyways. You get a REPL (you can interact with everything in the running program) you get binary upload (you can change the code of a running program) you get macros.

But for the beginning we could start with something more simple then the full fledged Common Lisp on embedded. There is still L (a Common Lisp language subset specially designed for embedded systems) and Mars realtime kernel to run L on. I sadly have not found a project site for that only a paper. I ask myself how much of Lisp goodness it provides.

Next semester I will have to make a project in embedded systems and the topic is not yet fully set. But I hope that I will be able to work towards the target of running lisp on embedded systems. I already asked my Professor about the idea and he is not negative but he still wants to talk about it. So wish me luck. (also I hope that my partners for the project will be willing to work in that direction too)

If you have any pointers and ideas about this topic then do not hesitate. I will appreciate any pointer.

[Update] Corrected minor stylistic mistakes.

There is one thing that you really want to have when you are creating programs. You want to create binaries. You can give them to others so that they can run them, without the hassle of compiling your programs by themselves, or you do not want them to see your sourcecode for some strange reason.

When you look at ruby, perl, python or even the all praised Java (do you hear the holy horns play? >_< ) you will see that you always need to install the appropriate one with tons of libraries so that you can run the scripts. I know I know ... I already see you running in my direction with your blades pulled out. There are compilers and packagers out there that can create binaries and you can even create a static binary that runs without the need of additional libraries.

But think for yourself are these solutions good? Is it working well?

I remember trying gcj. I had a test program of some hundred of very simple and standard java code. It was screaming very loudly "I am not ready to do that, I am too young!" perhaps it is better these days but I can not imagine that it works as it should. I also tried a perl to c converter but it was even more a mess.

As you know I am playing around with lisp, common lisp to be exact. As most people I was thinking that it will be the same way it is with the languages mentioned above. But I could not be wrong more. There are compilers and today most of the implementations do not even have an interpreter. Most of them compile the code to at least bytecode. (I know ruby does that too, and Java too ... damn do not pick out every word I say separately) But sbcl for example (my implementation of choice for now) compiles everything. In CMUCL from which SBCL was inherited still has an interpreter additional to the compiler.

I wanted to try out how it works with compiling a binary. I first thought that it will work just like with gcc or other command line batch compilers but I once more could not be wrong more. What you do is start SBCL load all libraries you need with "require" or "load" also load your program code and initialize everything you need. Then you run:

(sb-ext:save-lisp-and-die "my_binary" :executable t :toplevel 'main-program-function)

After that you have "my_binary" on your disk and you can start it on every compatible machine. What it does is saving the state of the lisp with everything that is present at the time you run the command. When you leave out the :executable you get a core file that you can use to run with sbcl -core commandline parameter. The :executable command only adds to the core file the ability to be executed by the operating system. In fact sbcl binary is just this kind of core dump that was created at compiletime of sbcl. The :toplevel keyword says the save function which function should be called the next time the core gets loaded. In most cases it probably will be the main function of your program. But when you think about it a bit more you can imagine how much power it is to be able to say what function is the main function. ;) (I know it from the lowlevel embedded programming side of the world ;) )

But now comes up the Question. It is a coredump so what does it contain? Well there it comes. It contains everything. Really everything including all libraries and the lisp compiler. So when I compile the robots game I introduced in the previous post here I get a binary of 23MB (yes megabytes). That is pretty much. Sure it does not count if you have a really big system that is 100 times bigger but still that sucks somehow. I informed myself and now I know that there is something called "headless" in the works that will enable sbcl to create coredump with an integrated dynamic linker. This will make the binary significantly smaller and when you run your program it will dynamically link the libraries it needs. Just as it should be. Next thing is from the slime world. There is a profiler in the works that will be able to even more optimize the code so that you will be able to create really small binaries.

All that is of course only SBCL other, commercial lisp implementations, like LispWorks or Allegro, already have very efficient mechanisms to create such binaries. But as long as you do not need that stuff immediately you can stay on the open source side of the world. ;)

I hope that was interesting, and also hope to get some comments. That would encourage me to write more…