[Openmcl-devel] BBEdit as IDE?

Gary Byers gb at clozure.com
Mon Apr 5 15:00:28 PDT 2004



On Mon, 5 Apr 2004, Stonewall Ballard wrote:

> Raffael,
>
> I didn't realize that there was an OpenMCL IDE. Where exactly is it?
>
> I really need something. I spent Sunday afternoon trying to get MCL 5.0
> to read and parse my iTunes Music Library.xml file (30K tracks) so that
> I could find all the duplicates. The xml parser created 90MB of
> objects, which seemed to annoy MCL, since it kept crashing. I was also
> unable to get the PCRE system to run in MCL. I think MCL's basically
> unusable with Unix text files.
>
> An interactive IDE for OpenMCL would be ideal.
>
> I'll see if there's something I can contribute to it. I am trying to
> resist the "tool regression" effect that has snared me in the past
> (where you keep working on the tools and never get around to using the
> language for your original project). That may be hopeless. I have too
> long a history of building IDEs for dynamic languages.
>
>   - Stoney
>

There's been a sort of proof-of-concept IDE available as an example
program - (require "COCOA") - for a fairly long time.  It's not very
usable as and IDE (a few things work, a lot of other things don't),
but it might be correct to say that it's about as usable as a shell
mode for BBEdit would be (never having used BBEdit, that's just a
guess.)

One of the things that Emacs (via SLIME/ILisp) and FRED have that
makes them (depending on your tastes) more usable is "lisp syntax
awareness" : a lot of code that knows how to navigate around a
buffer by S-expression.  There's a little bit of that sort of code
in ccl:examples;cocoa-editor.lisp, but there would need to be a lot
more of that infrastructure before you could start getting automatic
indentation (for example) to work.

I've been working for several weeks on replacing the text-storage
layer and command-handling code in the Cocoa text system with
equivalent layers from Hemlock (Hemlock's an Emacs-like text editor
writen in CL, originally as part of the SPICE Lisp project at CMU,
distrubuted with CMUCL, and made less CMUCL-dependent by Gilbert
Baumann last year.)  Gilbert's Portable Hemlock sort of runs (via
CLX/X11) in OpenMCL, but I think that most people would say that
its UI reminds them of a raw X11 program that's 15-20 years old.

The Cocoa-Hemlock integration is moving forward (a lot of stuff works,
a lot still doesn't); at the moment, there seem to be bugs that cause
it to fail to work at all on some machines (and to work as well as it
does reliably on other, seemingly identical machines).  When what works
works, it's marginally usable, and some of the things that'd make it
fully usable (highlighting matching parens, Meta-., integration with
backtrace and inspector windows, removal/change of code that only
makes sense under X11) are sort of in sight (if you squint a bit.)

All of this code is in the bleeding-edge (0.14-dev) CVS tree at the
moment.  A few people have played with it; if it was perhaps a little
more mature than it is, I wouldn't feel guilty about asking people
to pound on it and invite people who're interested in doing so to
work on it.  (A lot of things have changed and need to be documented,
and there'd need to be a nearly-up-to-date-and-constantly-changing
list of what works and what doesn't)

If this is successful, then (ideally) anyone who wants to do so should
be able to write extensions and customizations in Lisp; if it reaches
the point where many people are suffering from "tool regression", that
wouldn't necessarily be a bad thing.

I should also mention that there are at least a handful of people working
on various aspects of "IDEs for open-source Mac CL implementations", and
at this point many of those projects involve OpenMCL. Common-lisp.net
provides SourceForge-like resources for CL projects and hosts a mailing
list:

<http://common-lisp.net/mailman/listinfo/mac-lisp-ide>

A recent series of messages on that list indicated that progress is
being made on several interesting fronts; at this point, the progress
is often "fixed a few bugs, got a few more things working", so traffic
on the list is often bursty (but usually pretty interesting.)

I'd like to get the Hemlock/Cocoa stuff in the next release (which is
the primary reason that the next release is taking so long.)  I don't
think that it's too far away, but since I've been saying that for several
weeks now you should probably take that with a grain of salt ...




More information about the Openmcl-devel mailing list