|Version 19 (modified by gz, 3 years ago) (diff)|
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.
The 32-bit Windows lisp doesn't currently run on 64-bit Windows. This is because 64-bit Windows doesn't let us set up an x86 LDT so that we can use a segment register to point to thread-local data. A possible solution to this is to pare down the size of the TCR so that we can fit as many slots as possible into the Windows TLS vector.
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.
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.
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.