[Openmcl-devel] Is OpenMCL ready for use?
joswig at lispmachine.de
Fri Dec 20 16:59:17 PST 2002
At 22:12 Uhr -0700 15.12.2002, Gary Byers wrote:
>On Sun, 15 Dec 2002, Stonewall Ballard wrote:
>> I'm becoming very encouraged by the MCL 5 beta and the OpenMCL efforts.
>I hope that other people will be inclined to respond to this with
>One of the original goals of (what became) OpenMCL was to make it
>possible to develop embedded/server applications in Lisp. That's
>still an important (if not widely-shared) goal (it's important to
>the people who pay me, therefore important to me.) Some of the
>issues there overlap with desktop-delivery issues.
Most of the business in server applications is on x86 (*BSD, Linux, ...)
Interesting "embedded" apps are running PowerPC (also Nintendo
gamecube) and ARM (also mobile phones and PDAs).
So I'm curious who would really be using OpenMCL for
deployment of embedded or server applications in OpenMCL
(using LinuxPPC or MacOS X).
Personally for me, for development I just care about MacOS X.
For OpenMCL I especially *don't* care about LinuxPPC.
For delivery I also would look for SPARC and x86, But currently
I'm not much interested in delivery.
I'm interested in a small, fast, robust, complete Common Lisp
that can run CL-HTTP and/or CLIM-based applications. I'm currently
in the process of slowly porting CL-HTTP to OpenMCL. CLIM
could also be the base GUI toolkit for an IDE. I don't
care about Project/Interface Builder - I want to write stuff
in Lisp with Lisp for Lisp. A long term goal (currently I don't have much
time to concentrate on that) is to port an object-oriented
database to OpenMCL (and/or LispWorks).
Though I have to confess that using the Interface Builder
for OpenMCL GUIs could be interesting for a lot of people
(with OpenMCL then being a competition to AppleScript Studio).
Another road could be a Cocoa-backend for McCLIM. Or
a Cocoa-backend for an open-sourced CLIM (like the MCL
I think native threads are high on my wish list for OpenMCL.
- more clever boxing/unboxing support for floats and fixnums
- larger arrays (for example for image processing routines)
- native threads with support for multiple CPUs
- better MOP support (slot descriptors, ...)
- a cookbook about how to deal with development issues
for MacOS X / Cocoa (how to use the MacOS X libs
effectively and how to write high-level CL APIs for them)
- OpenMCL highlevel libs to MacOS X libs...
> > I'm not clear on whether MCL 5 is stuck with Carbon, but I suspect
>> that it is so long as it uses CFM. I have no interest in OS 9 apps,
>> so I'd rather use a Mach-O based system.
>There are a lot of people for whom backward compatibility is a big
>concern. MCL 5 certainly provides lots of backward compatibility;
>since they seem to have that issue pretty well covered, it seems that
>OpenMCL should ideally move in the other direction (faster than it's
>been doing so lately.)
On MacOS X carbon-based applications can use cocoa. And
cocoa-based applications can use carbon. So in theory
MCL *could* give developers access to cocoa features.
>I don't think that this list has ever carried a high volume of traffic;
>it's certainly been quiet lately, but it's always been kind of bursty.
>If you look at the release history, development's also been bursty;
> releases were probably more regular in the past, but progress
>(however it's measured) hasn't always been linear.
Generally I think OpenMCL is working relatively nicely on
the core Common Lisp stuff. So there is not that much
discussion on these issues (not that there might not be some).
MacOS X has a lot of Common Lisp development environments
(with more to come) - so there is a lot of competition.
Of the Open Source Common Lisp implementations for MacOS X,
OpenMCL is by far the best - maybe even the best on any platform
(soon) - for a lot of meanings of "best".
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel