So I guess most delusional Lisp weenies will have read the account at http://www.flownet.com/gat/jpl-lisp.html.
I started wondering, though, is any of the Lisp code that NASA/JPL wrote publicly available?
I did find http://nmp-techval-reports.jpl.nasa.gov/DS1/Remote_Integrated_Report.pdf, which is interesting in it's own right, and contains snippets like this: (to achieve (IPS THRUSTING ips level)
((ips is in standby state p ips)
(sequence (achieve (power on? 'ega—a))
(command with confirmation
(send—ips—set—thrust—level level))
(command with confirmation
(send—acs—change—control—mode
:acs—tvc—mode))))
((ips in thrusting state p ips)
(command with confirmation
(send—ips—change—thrust—level level)))
(t (fail :ips achieve thrusting)))
Name:
Anonymous2011-01-09 15:25
It also had this little goodie:
1.6 Preparing Lisp for Flight
One important aspect of the RA preparation for flight was the preparation of Lisp for flight. The RA software development and runtime environment was based on Common Lisp, in particular the Harlequin Lispworks product. The use of Lisp was appropriate given the background of the RA developers, the early inheritance of code libraries, and the hardware independence of the high-level software interfaces between RA and the rest of the flight software. However, with the choice of Lisp came some unique challenges. These challenges fell into two rather broad categories: resource constraints and flight-software interfaces.
To fit within the 32 MB memory allocation and the CPU fraction constraints, the RA team thoroughly analyzed their code for memory and performance inefficiencies and applied a “tree-shaking/transduction” process to the Lisp image. The analysis is, of course, common for any high-performance software. However, transduction is Lisp-specific and arises from the tight coupling of the Lisp runtime and development environments. Transduction removes the unneeded parts of the development environment (e.g., the compiler, debugger, windowing
system). The result is a significantly smaller image, both in terms of file system and runtime memory. During RA testing, peak memory usage was measured at about 29 MB. Upon completion of the transduction process, the RA Lisp image was compressed by a factor of about 3 to 4.7 MB and uplinked to the spacecraft. Onboard decompression was initiated at the start of each RA run, with the file being inflated directly into the 32-MB RA memory space. Use of this custom compression drastically reduced the file-uplink time and kept RA-file space usage within the agreed limits.
Added to the challenge of working within resource constraints was the challenge of working out the complicated interfaces between RA and the rest of the flight software. The flight software was written in the C programming language and ran on the VxWorks operating system. Lisp and C interacted through Lisp’s foreign function interface. This interface was the source of many early problems, primarily caused by discrepancies between data structure alignments assumed by the Lisp and C compilers. These problems were quickly discovered and
resolved with the help of an extensive test suite that analyzed many function-parameter variations. Another problem arose in preparing the Lisp multi-threading system for flight. Originally, the Lisp thread scheduler relied on a high-frequency, external, periodic wakeup call issued at interrupt level. However, this went against the design principles of the DS1 flight software. Hence, Lisp’s approach—to thread preemption to use a lower frequency wakeup call implemented with flight software timing services—had to be significantly changed.
Most of the late integration problems with RA Lisp arose because of the VxWorks port. As RA moved from testbed to testbed, ever closer to the final spacecraft configuration, low-level Lisp problems arose. The problems were consistently of two types: a function assumed by Lisp to be present was not present or a function was present but did not perform as expected by Lisp. The first type of problem was resolved by consistent application of a detailed RA and FSW build process. The second type of problem was addressed on a case-by-case basis. Solutions to these problems were made difficult due to the reduced debugging visibility as testbeds assumed the spacecraft configuration. The entire undertaking benefited from the dedicated efforts of both Harlequin and the DS1 FSW team.
Doubtful that it is availabe, but you could always ask them if they'd be willing to publish it, as long as it contains no "secrets".
As for reading it, sure, most CLers will inevitably encounter the author and his account by reading c.l.l. or reading c.l.l. archives or even just the ones related to Naggum as the two (Erik Naggum and Erran Gat/Ron Garret) used to argue a bit.
Name:
Anonymous2011-01-09 15:42
Lost In a Sea of Parens
Sure, the semantics are cool, but the syntax sucks dicks.
>>4
Complete non-issue after working with itfor less than a week in a good editor (Emacs+SLIME+Paredit would be minimum IMO). Of course, if actually spending a week or less coding in a new language is too much effort, I can understand.
Name:
S2011-01-09 15:54
I also suck dicks, but that doesn't make me any less of a programmer.