Things To Do
Here are some big and small things that would be good to do. If you would be interested in funding any of these, please send mail to business@…. If you would be interested in volunteering to work on any of these, that would be welcome, too. Please send mail to openmcl-devel@… to discuss any of them.
Building the lisp kernel for Windows can be pretty hard because the gcc-based toolchain for Windows has been a bit of a moving target. Building with Microsoft's Window SDK is a possible alternative. See ticket:875.
We could really use better documentation tools. We had a long thread on openmcl-devel about it, but there seems to be no magic way to make editing Docbook content easier.
More thorough documentation (document all exported functions).
Better documentation generally. Producing this would presumably be made easier by better tools.
Breakpoints, single stepping (not the evaluator kind, the compiled code kind).
Make the lisp available as a shared library.
We now have a buildbot that builds and tests ccl automatically. In addition to ccl's own test suite, it would be desirable to run and test other major software. For instance, Maxima has a substantial test suite.
Enhance socket interface to support IPv6. Maybe follow http://www.franz.com/support/documentation/current/doc/socket.htm#socket-ipv6-1
Unbundle the Cocoa-based IDE from the ccl distribution and make it available as a separate product.
Add and document a reasonable way to create NSStrings/CFStrings from lisp strings. There's unexported stuff like %make-nsstring and ccl::with-autoreleased-nsstrings, but there needs to be something official.
Design and implement some sort of windowing library for MS Windows that doesn't rely on Cocotron. Maybe something for X11, too. (Note that ccl doesn't have any idea how to call C++, so it's best to pick a library with a C interface.)
Bring back Fred.
Implement missing CLOS MOP features.
Better machine-word arithmetic support. Or maybe an interface akin to LispWorks's int32 API.
Make ccl reliably handle out-of-memory conditions on operating systems (like Solaris) that don't lie about memory allocation.
The GC stops all other threads while it operates. Some sort of concurrent GC (where collector and mutator threads can run at the same time) might be beneficial for some users.
The interface translator is a set of patches to GCC. It might be worth looking into using libclang for this instead.
Revive support for the GNU Objective-C runtime in the Objective-C bridge.
The jfli interface to Java ships with ccl as an example, but perhaps an improved bridge would be useful (e.g., for Android).
Rename openmcl-devel@… to ccl-devel@….
Review tickets on the Trac.
Update Trac main page now that ccl.clozure.com exists.
Ports to More Systems
Port to Itanium. Probability: low.
Port to modern SPARC. Probability: very low.
Possibly target LLVM, though there are serious open questions about our GC would work.
At some point, the Darwin/PPC is going to die (not least because we'll run out of working hardware). The PPC Linux port will likely live on, but we'll probably need to acquire some newer hardware one of these days. Some larger PPC systems use a page size of 64K. CCL expects a page size of 4K, and it would take some effort to make it work with other page sizes.