SBCL 0.7.10 has been released. It looks like there are major changes to the CLOS implementation (PCL) and a lot of bugfixes.
More old news!
Kevin Rosenberg has created both fink and debian packages for OpenMCL.
This is the sort of thing I've been waiting for from the ILC. [via LtU.]
I learned that Kent Pittman is an angry man.
...
Kent Pittman will charge the submitters of sub-standards up to $300; His web site will let people log their preference for particular SRFIs (I mean, substandards). People will be charged around $20 per year for such a privilege.
...
Watching robots playing soccer was indeed as exciting as watching real soccer.
...
Franz has distributed the following notice to the attendees: Franz Inc. works with Apress Publishing to publish a book on practical Lisp Applications. Areas of interest: bioinformatics, robotics, Web/Internet, databases. The applications should be Lisp-based, used in the "real world", and have commercial/educational value. Contact: Lisa Fettner, lisa@franz.com
...
In general, I got an uneasy feeling about Google. They seem to be too much 'cowboy programmers'. One day it will cost them.
On the ll1-discuss mailing list there has recently been a lot of discussion of lisp-style macros. One of the funnier threads started when Todd Proebsting posted a message with the subject "Macros Make Me Mad":
Defining a macro is often an act of defining a language construct and implementing it. Reasonably or not, I hold language constructs to a higher standard than, say, a mere function definition. Specifically,
- I expect language constructs to be implemented perfectly. I must trust my compiler.
- I expect language constructs to be documented precisely. I must trust the documentation.
Which is a pretty bogus complaint, I thought.
Guy Steele replied with a series of messages of the form
- I expect <language feature> to be implemented perfectly. I must trust my compiler.
- I expect <language feature> to be documented precisely. I must trust the documentation.
where <language feature> was classes, procedures and algebraic expressions. Steele finished with Parodies make everyone mad:
My point is not that Todd should lighten up on macros; on the contrary, if anything, I would say he expects too little of those who define functions. All too many programmers *are* really lousy at writing documentation. A library of procedures or methods can constitute just as big an extension to a language as a handful of macros.
Where the line is drawn will depend to some extent not only on the skill level of the programmer but also on the customs and expectations of the community within which the programmer functions. If macros are part of the customary toolset of a community of programmers and there are guidelines and expectations about how they are and are not to be used, and about the level of documentation needed, then they need not be a problem. The same is true of classes, procedures, and algebraic expressions---and there was a time and place in the history of computers when each of these was regarded with similar suspicion by some group of (non-stupid) programmers.
Macros are one of my favorite, and most unique features of lisp. I'm a little touchy when they're criticized, so I'm glad that Steele answered Preobsting's point so well (while still not letting macros completely off the hook).
Oops, I forgot to post this a few days ago. Matthew Danish has code for FTP client functionality: CL-FTP.
It should work in any lisp that ACL-COMPAT supports.
CMUCL and SBCL now have a shared bug tracking database (based on Dan Barlow's CLiki technology): Entomotomy.
Stig Sandoe has released version 0.1.1 of Langband the Angband-like game that's written in lisp. This version now uses SDL for the UI.
A couple nights ago I went to see David Cross do some sort of in-store performance at Amoeba records.
He has a new comedy album out, but he just played CDs and made jokes in between. He was effortlessly hilarious.
Meanwhile I browsed. Eventually I picked up a Royal Trux CD.
Then David said "OK, I'm going to play another CD now. Royal Trux. Do you guys like Royal Trux?" I thought "Ha, that's kind of funny, I'm holding a Royal Trux CD."
Then he said "Hey, anyone buying a Royal Trux CD, anyone with a Royal Trux CD in their hands right now, raise your hand." so I tentatively raised my hand. I was the only one.
So he invited me on stage and I joked around with him, played a little guitar, and finally we performed the Nil's Guitar Shop sketch.
Today at work we posted the beta of the next software release. This is what I've been so busy on lately. I'm pretty invested in this release, as the most significant new feature is the result of the work I've been doing since I started at Evolution seven months ago: A new, relatively easy way to program our robots in C++ and Python.
When you hear about robot software, the focus tends to be on two ends of a spectrum. At one end is the subfield of AI known as planning, which in caricature has the goal of building a superbrain capable of general problem solving. You tell it what you want to do (e.g., get to the upstairs bedroom from the downstairs kitchen). It thinks, then spits out a complete and detailed plan for achieving your goal (turn 190 degrees to your right, move forward 3 feet, turn right 90 degrees, move forward 7 feet, turn right 60 degrees, engage stair-climber treads, etc.).
This was the traditional AI approach to robotics for many years. It turned out to have some real drawbacks, however. Coming up with a plan that was detailed enough to be helpful could take a long time, during which the robot might be unresponsive. Then once a plan was ready the dynamic nature of the world soon made it obsolete; "No plan survives first contact with the enemy" is a military saying, but to a robot the whole world is the enemy. People open or close doors, roads get washed out, sensors are inaccurate, and mechanical parts fail. Attempting to create plans that anticipate all possible failures or try to take advantage of new opportunities quickly becomes unwieldy.
On the other end of the spectrum is Rodney Brooks' subsumption architecture, which was developed as a reaction against the whole symbolic representation and planning approach. Robots are wired with tight feedback loops and little or no internal state. They're like cockroaches, walking nervous systems that rarely do anything optimally but are very robust. Unfortunately it gets very hard very fast to figure out how to program robots in this way to do anything other than simple insect-like behaviors.
Now if chocolate represents a deliberative planner, and peanut butter represents a subsumption architecture, and... well, yeah, you've got the idea. It turned out to work pretty well to glue two software layers together. Except in this case we make it twice as tasty by adding a middle layer of delicious marshmallow-flavor whip, which in the ingredients list shows up as "Sequencer" or "Task Execution System". This third layer, the sequencer, selects which low-level reactive behaviors should be active based on the robot's higher level goals. The three layer architecture has become a popular and successful way of writing robotic software.
The software I wrote is called the Task Execution Layer (TEL), and sits on top of the lower level behavior layer. Writing new behaviors to control the robot is probably beyond most hobbyists, but with the TEL they can write code that looks a lot like a traditional program yet still takes advantage of the supplied library of robust reactive behaviors. (We don't have a planning layer, at least not yet.)
Writing C++, however, may be beyond a lot of hobbyists too. And hell, even as a non-hobbyist I'd still prefer to write as little of it as possible. So I developed a Python interface to the TEL.
I should admit I don't really think much of Python. It's ok for what it is, but I don't think it deserves nearly the attention and praise it gets. Until recently I would have said that nobody would write large software systems in Python. It's not particuarly clean or elegant, it's not fast, it's not all that powerful. But it is really easy to learn. And while it loses pretty badly compared to lisp, it's quite nice compared to C++.
Compare C++:
TaskFunctor* Add = TaskRegistry::find_task("Example.Add"); TaskArg add_args[] = { -2.0, 5.0 }; TaskContext* context = TaskContext::task_args(2, add_args); TaskValue* value = Add->run(context); if (value != NULL) { std::cout << *value << std::endl; delete value; } delete context;
To Python:
print ersp.task.example.Add(-2.0, 5.0)
voicecontrol.py is a more complete example that demonstrates simple voice control of a robot.
Lisp would have been a much nicer language in which to implement an interface to the TEL (or even just implement the whole TEL) since what I really wanted to do was either create my own language (as in Jim Firby's RAP system) or extend the host language syntax a bit (as in Erann Gat's ESL). Maybe there will be a lisp interface one day, but I have to admit that while Python was quite easy to extend and embed I don't know of an existing lisp implementation that would have met our technical (native threads, callbacks between languages, embed in shared libraries, support linux & windows) and licensing (must be 100% free) requirements.
Rainer Joswig clued me in on getting MCL 5.0 beta to quit using the olde fashioned UI widgets, by setting ccl::*use-pop-up-control* to T. I've been working ridiculous hours to finish the beta release of the Python SDK for the ER1 robot, and this is the first chance I've really had to make an updated screenshot.
Rainer also sent in a screenshot of him editing the OpenMCL listener window in the cocoa Interface Builder.
Thien-Thi Nguyen has a lisp wiki-alike, wikid. You can see it in action at http://www.glug.org/wiki/.
Fred used to crack me up every time until he retired from being funny. He's still the only person with whom I can still safely indulge in telling Meg White stories.
Repercussions from ILC continue to be felt. The deepsleep pod with the frosted glass faceplate containing the motionless body of the Association of Lisp Users begins to bleep and bloop.
Tim Converse's secret confession:
I love Lisp. Even more secret confession: Lisp advocates get on my nerves.
[...]
A Lisp advocate can be happily and effectively making arguments about programmer productivity or high-level language design and everything will be going quite swimmingly right up until the point when things get sticky or confrontational or start departing from plan, and then... our Lisp advocate will curl his lip and start muttering savage little imprecations about how the only six intelligent people on this Earth are himself and his five Lisp-programmer friends. And this is just so unfortunate and unhelpful.
I do get really sick of that attitude among some lispers. People are not stupid for not using Lisp. Actually, I'm sick of that attitude as expressed in "people use Microsoft because they don't know any better" too. It's understandable if you're twenty-two years old, but after that you should know better. Or, you're bitter.
Raymond de Lacaze has put up an impressive array of pictures from the International Lisp Conference. Being reminded of everyone I did not see is a little depressing. Ironically, kmp seems to be heading for an rms appearance asymptote.
There are also links to photos by Taiichi Yuasa and Bill Clemenson.
One year ago I started lemonodor, courtesy of blogger and blogspot. You can still see some of the old pages with their ripoff a list apart look.
I was working on porting an I/NET application from ACL to CMUCL, and thought it would be a good idea to take notes on the process. And then I had the idea of doing it as a weblog. Actually I had a very specific goal in mind: to make contacts. Whatever that meant; mostly I think it was just to meet some interesting people.
It's weird. 12 months. Of a weblog. Where's my book deal? Why exactly did I start? How did anyone find it? (I'm glad they did.) How did my life change so much in 12 months? How did I post over 250 items? And who posted those hundreds of comments? Should I just stop now? Maybe I should take guitar lessons instead of this lemonodor stuff. Nah, I think I can do both.
Predictions for the the next twelve lemony months:
I've been playing with adding a search function (see sidebar). A few weeks ago I seeded all the pages with a "globally unique" keyword as part of an experiment in enabling more focused google searches, but it didn't work (google ignores meta keywords, I guess).
The beta version of MCL 5.0 is now available at the discounted price of $495. It includes a free upgrade to the final version, expected in January, and there are educational discounts.
You can read the release notes.
If you're curious what it looks like, here's a screenshot in which I threw every dialog I could think of onto the screen (I've also got Terje Norderhaug's Appearance Manager stuff loaded, which upgrades the look of the controls a bit):
The visual appearance of the beta is an odd mixture of lickable OS X widgets and monochrome system 7-era controls. I expect this will change over time (as Terje's code shows).
Active Lisp Pages, from SRI, looks almost exactly like LSP.
OpenMCL 0.13.1 is out. This release mostly contains bug fixes, though it also now compiles under OS X 10.2 (Jaguar), and the Cocoa demo works under Jaguar as well.
Courtesy of Rainer Joswig (again), lemonodor presents scans of a Symbolics Color Graphics System (aka S-Graphics) brochure. Given my propensity for cluttering lemonodor with pretty pictures, it's probably not surprising that I have a soft spot in my heart for 3D graphics in Lisp. You can imagine my delight when Rainer mentioned he had these scans.
S-Graphics running on Symbolics hardware became nearly ubiquitous in broadcast and film animation in the late 80s and early 90s. Many of the short films in The Mind's Eye, a 1990 compilation of computer animation, were created on Symbolics systems. The video included a groundbreaking animation produced by the Symbolics Graphics Division, "Stanley and Stella in: Breaking the Ice". (Stanley and Stella was one of the first applications of Craig Reynolds' "boids" behavioral animation model.)
When Symbolics went bankrupt S-Graphics was acquired by Nichimen Corp., which renamed it N-Graphics and eventually turned it into a series of high-end graphics tools: N-World, then Mirai. As just one example of the popularity of the tools, the graphics in Super Mario 64 were created with N-World (which is built on ACL). Two years ago Izware took over development of the Nichimen graphics products.
So that's a short summary of the long history of S-Graphics. In 1984, when this brochure was produced, I doubt anyone was expecting even descendents of the software to be around almost 20 years later.
Dave Bakhash posted a personal account of the conference, and Bill Clemenson put up some photos. See what the people actually doing lisp look like. [via CLiki]
Later:
Dan Barlow notes some interesting bits from ILC.
More ILC stuff is dribbling in. Here's a McCLIM paper by Robert Strandh and Tim Moore.