Nov. 11th, 2013 | 09:32 pm
Nov. 6th, 2013 | 01:43 pm
Here's a neat use of CL: a bike configurator expert system. A few details are available. Here's a bit I liked:
Bike Friday builds so many bicycles that to photograph everything would not be possible. Even with the limited component selection displayed in the cartoons there are over 15,000 cartoons generated just for the ~130 starting designs so far in the system.
The cartoon generator works by using CXML to load a master SVG file, remove all but the appropriate layers for a given model, and then colorizing different parts of the bike using a mix of SVG patterns and RGB hex codes depending on the bike and color selection. It then uses ImageMagick to convert the generated SVG file to JPG.
You can read more on reddit.
Nov. 6th, 2013 | 07:56 am
A while ago I created an Atom feed for new Common Lisp projects on github. Unfortunately, the github page from which it scraped its data was removed a few months ago. Fortunately, Matt Niemeier just sent me a patch to the github scraper to make it work with the github API. Thanks, Matt!
So if you want to see a daily feed of new Common Lisp stuff on github, point your favorite feed reader here:
Oct. 24th, 2013 | 01:50 pm
From: "R. Matthew Emerson"
Subject: [Openmcl-devel] ccl and recent Apple updates
To: openmcl-devel Development
Date: Thu, 24 Oct 2013 13:49:11 -0400
Some people have reported problems building ccl after updating to Xcode 5, or after updating to OS X Mavericks.
The version of Subversion that is included with Xcode 5 uses a new working copy format. Past versions of Subversion would upgrade working copies automatically and silently, but this time, the Subversion developers decided to require manual intervention.
Go to your ccl directory and run "svn update" by hand, and note that it prints out a message prompting you to run "svn upgrade". Run "svn upgrade" as it prompts.
On OS X Mavericks, it appears that installing Xcode does not install include files in /usr/include. It used to be the case that you could solve this problem by downloading the Command Line Tools from Xcode's preference panel. On Mavericks, this no longer appears to be an option. Instead, you must run "xcode-select --install" from a terminal. This will show a dialog, make you agree to some license or other, and then offer to download the files that ccl needs in order to build. It may even be the case that you don't need to download Xcode just to install the command-line tools, which would save you a 2 GB download if you only want to rebuild ccl. </blockqoute>
Oct. 7th, 2013 | 07:43 pm
Juanjo sent en email yesterday about about the status of ECL:
* First of all, ECL no longer relates to my own work. On the contrary, other open source projects that I carry on (https://github.com/juanjosegarciaripoll?t
ab=repositories) are more directly related to my research and are demanded by my group. This is detracting development time from the project, but there is little I can do, as that numerical software is what feeds our bellies right now.
* Not only does my work consume most of my open-software development time, but the job overall does significantly constraint the time I can spare for the project. As group leader in a research environment with scarce resources, I spend more time writing grant applications and bureaucracy than I do in front of Emacs. Quite frustrating as it is, I only see it worsening in the near future.
* The consequence is that the time I can devote to ECL has serious ups and downs. In an environment of rapidly developing tools and libraries, this is quite unfortunate, as the project may lag behind and become obsolete. This is indeed what has happened with several of the ports out there.
* On top of this, there are a lot of frustrating things that I did not want to care about but which are bugging me right now and also stealing time. The first one is the license issue. I put out a suggestion to migrate to MPIR because I knew that MPIR had an effort to stay with LGPL2. Regrettably, I did not know that this effort was abandoned so that if ECL wishes to upgrade to any more recent version of GMP/MPIR it has to migrate to LGPL3.
* Another nagging issue is testing. You have suffered this in the past and it still is a problem: my testing environment is broken and I do not have time to fix it. Despite Anton's wonderful library, the fact is that it is a heck of a problem to maintain several virtual machines and computers in an uncooperative computing environment with frequent blackouts.
* Finally, on the one hand, there are many new upcoming implementations out there, some with promising results and features that I do not have the time to incorporate -- but which would be simple with resources -- and certain forks are consolidating. On the other hand, despite ten years of development, I have failed to aggregate any number of contributing developers around this project. This may be blamed on the community or on myself, and it does not match the supportive and helpful user base that ECL has always had, but the fact is that it is a problem and a time has come to accept it [but please, I do not need your pity on the IRC channels, ok?]
Though I did not have time to develop, I had time to think, even if on the bus trips and planes, and I came to the following conclusions:
* I am resigning and opening the position of ECL maintainer for anyone to take. I will grant him or her with full administrative rights and full responsibility over the project's future. No need to fork the project: if you really feel you can make it better, step ahead and take it. I will remain as a support developer and help you as much as I can.
* If no one takes over maintenance, I will continue working as I can, when I can. This may be unsatisfactory for many of you -- if this is the case, I am sorry, but that's all there is.
Sep. 1st, 2013 | 05:27 pm
Sabra Crolleton has put together a thorough, detailed survey of Common Lisp JSON libraries. If you are trying to evaluate which one to use, this survey may help you understand the features, strengths, and weaknesses of cl-json, st-json, yason, jsown, and com.gigamonkeys.json.
Jul. 9th, 2013 | 11:52 pm
The SAILDART archives are pretty fascinating. I stumbled across a page there that describes an approach to Common Lisp standardization of which I was previously unaware: the white, yellow, red, and blue pages concept.
The white pages is a language specification rather than an implementation specification. It defines a set of standard language concepts and constructs that may be used for communication of data structures and algorithms in the Common Lisp dialect. [...]
The yellow pages is a program library document, containing documentation for assorted and relatively independent packages of code. While the white pages are to be relatively stable, the yellow pages are extensible; new programs of sufficient usefulness and quality will routinely be added from time to time. The primary advantage of the division into white and yellow pages is this relative stability; a package written solely in the white-pages language should not break if changes are made to the yellow-pages library.
The red pages is implementation-dependent documentation; there will be one set for each implementation. Here are specified such implementation-dependent parameters as word size, maximum array size, sizes of floating-point exponents and fractions, and so on, as well as implementation-dependent functions such as input/output primitives.
The blue pages constitutes an implementation guide in the spirit of the Interlisp virtual machine specification. It specifies a subset of the white pages that an implementor must construct, and indicates a quantity of Lisp code written in that subset that implements the remainder of the white pages. In principle there could be more than one set of blue pages, each with a companion file of Lisp code. (For example, one might assume IF to be primitive and define COND as a macro in terms of IF, while another might do it the other way around.)
[W]e will produce the first version of the blue pages. This requires producing a detailed specification of the subset of the white pages that must be written, expanding on the white pages description where necessary. We will also write, test, and document an implementation of Common Lisp in that subset and make that code available to anyone wanting to implement a Common Lisp. Thus, for any group to implement a Common Lisp, all that will need to be done is to write the specified subset language in whatever other language their hardware supports and to then take a copy of the Lisp code we will have produced which will complete the implementation of the white pages language.
(Emphasis and hyperlinking added.)
See the full ARPA.PRO document for the entire message. It's from 1982. What would the CL landscape be like today if this plan was followed to fruition?
Jul. 8th, 2013 | 08:49 pm
Last month I emailed Roger Corman about his future plans for Corman Common Lisp. Here's his response:
Thanks for your interest in Corman Lisp. I have been unable to commit any resources to developing Corman Lisp for the last couple of years. I would be willing to convert it to open source, and let others take it over, as I don't expect to be able to get back to it any time soon. My medical software business consumes most of my time these days. The source code is all already included (at least for Corman Lisp itself). The source code for the IDE is not included, and I could package it up and add it to the distribution. Then I guess the thing would be modifying the licensing terms to reflect one of the open source models.
I see two primary issues at this point. First, the Corman Lisp kernel needs to be built with Visual Studio 2005, which is an old version of VS. At one point I built it with VS2008 and it built and ran, but some problem with the FFI caused applications saved, and the IDE, to have problems. This type of thing is fairly common as Microsoft makes subtle changes to the code generation of their C compiler, which in turn affects the Lisp kernel which has very tight rules about how it expects its code to look. I did a lot to reduce the kernel (move things from the kernel to Lisp code, which is then compiled safely), but did not fully resolve the VS 2008 issues. Now there is VS 2010 and 2012, and I never tried building with either of those. In general I find each newer version of VS is worse for native C/C++ debugging, as .NET has become Microsoft's primary platform for new software.
The other issue is running on 64-bit OS. Again, the FFI misbehaves when you have saved an application, or just doing a bunch of FFI stuff in an application. It is something to do with GC and the 64-bit support for running 32-bit applications (which is what CL is). It could be related to the same issue as I encountered with building under VS2008.
Tracking down this problem is difficult.
Regarding converting to a full 64-bit Lisp, this would be a much bigger effort. Corman Lisp gets such good performance by a large amount of hand-optimized x86 assembly code. This would all have to be rewritten/replaced in a 64-bit Lisp.
When Corman Lisp was first developed in the late 90s, there was really no competition on Windows platforms. Franz only had a 16-bit Lisp they were selling, and not really taking the Windows market seriously. Mac Common Lisp was on 680x0 and later PowerPC but didn't get to Windows for a very long time, and LispWorks didn't support Windows until much later. Now I think most all of those have good implementations on Windows (though only MCL is free). I have used Allegro extensively for a large contract with SRI and I see the value of a mature cross-platform system like they have. It is however extremely expensive, and developing applications for distribution requires lots of negotiation and per-license payments to Franz. Corman Lisp still has some advantages, I think--it is really a good hackers Lisp, when you want to easily get down into the assembly level, or in the guts of the compiler, to do almost anything. You have the power of Lisp to do those things with macros and a nice high-level dynamic environment.
I definitely want to see it live on, so am open to whatever enables that. I don't currently derive any significant income from it so that's not a concern for me.
I can't wait to see how this goes!
Jul. 1st, 2013 | 08:42 pm
Mark Watson wrote to me about an announcement he made today on his blog:
I ... got back to my Common Lisp “roots” last week when I was enjoying playing with the mocl Common Lisp system for Android and iOS development. I wrote an AI book using Common Lisp for Springer-Verlag in the 1980s, which was lots of fun, and in 2007 I put together a very short PDF free “book” called “Loving Lisp, or the Savvy Programmer’s Secret Weapon” with the help of many people in the Common Lisp community who offered corrections and suggestions. A few years ago I spent a weekend correcting and adding material to “Loving Lisp, or the Savvy Programmer’s Secret Weapon” but I never published the new material. I just decided last night to spend some of my free time updating this book adding more material on: accessing PostgreSQL, MongoDB and CouchDB; writing web apps; a native Common Lisp SPARQL client and some ideas for using SPARQL endpoints in Common Lisp applications, and some general material on information gathering. Basically, supporting an old language like Common Lisp with some fun modern application examples.
Jul. 1st, 2013 | 07:07 pm
About 10 years ago I read an article on comp.lang.lisp about system calls and the condition system:
... I would have liked a native Unix system call interface that could skip the dumbing-down that the C interface library represents. e.g., most system calls in most Unix implementations return an error as a CPU flag, not as some stupid special value and setting a global variable like the C library exports to C programmers. that is, it should be fairly simple to create a condition system for Unix system calls that could be more efficient and less insane than the C stuff we have to deal with via today's foreign function interfaces.
That sounded interesting, and I started hacking around on it, and someone sent me code from Douglas T. Crosher for direct syscalls in CMUCL on Linux/x86. Then I lost interest in the project and forgot about the code, until yesterday. So I posted the code on github in case it seems interesting to someone else. I'm not sure how much work it would take to get it running on modern CMUCL or SBCL.