[slime-devel] Re: Daily ChangeLog diff

[Helmut Eller]

Peter Seibel <peter at javamonkey.com> writes:

> Luke Gorrie <lgorrie at common-lisp.net> writes:
> 
> > +2003-12-06  Helmut Eller  <e9626484 at stud3.tuwien.ac.at>
> > +
> > +	* swank-allegro.lisp: New file.
> 
> Hey, cool! How far along is this port? 

Most of the basic (in Slime terms) functionality is there: evaluating,
debugging, compiler condition trapping, definition finding, stream
redirection, apropos, and xref lookup.  Evaluating is implement in
portable CL and works the same in all backends.  Stream redirection
uses the same gray stream based code as the other non-CMUCL ports.
Allegro has a documented debugger interface and I used that where
possible (the document is partly out of sync with the implementation).
Only backtrace, listing of local variables, and "find frame source
location" are implemented.  More advanced stuff like stepping, "return
from frame" etc are missing in Slime, but Allegro has very neat
support for most things and it wouldn't be too hard to add them.
Compiler condition trapping was mostly an exercise in reverse
engineering; not sure if it works for non toy code.  Compiling from
buffers is implemented with temporary files.  This works good enough
for compiler warnings, but isn't much fun in the the debugger.
Allegro's xref support is the best of all our backends.

Interrupting doesn't work very well, because Allegro asks which thread
should be interrupted.  That's quite annoying.  In general the port is
like the OpenMCL and LispWorks backends: works, but not as nice as for
CMUCL.

I'm mostly interested in good CMUCL support and did the port to learn
about Allegros xref stuff.  (That's an area where CMUCL needs
improvement.)  I had the code lying around for some days and wasn't
sure if I should commit it.  More backends means rather boring porting
work and fewer features for CMUCL.  I committed in the hope that some
Allegro user would take it up and maintain it.  (Not very likely,
given that ELI is the official Allegro interface; but one never
knows.)

> The more implementations SLIME can be used with, the more plausable
> this becomes. And of course to the extent that SLIME is the best emacs
> intergation it gets even more plausable. I haven't actually had a
> chance to play with SLIME yet myself but I've read the backlog of
> messages on this list and looked at the code some--I'm impressed with
> the momentum you guys seem to have.

The project snowballed; that's a good motivator.  OTOH, Slime is still
relatively young and, like any other piece of software, requires time
to evolve.  I don't know if Slime is ready for the Real World;
probably not yet.  We need more experience with non-toy projects and
challenging problems, like multi-threading support and remote
debugging, are note solved yet.

You will have to try Slime for yourself, to see if does what you need.

> So I guess what I'm saying is, if you keep cranking out cool stuff the
> way you have over the past couple months I may be able to give you a
> big fat plug in my book. And that'll be even easier for me to do if
> you have good integration with Allegro. I'd volunteer to help out with
> some hacking but I'm already in up to my neck with writing the book.

Contributions, be it code, publicity, or feedback, are always welcome.

> I do have some contacts over at Franz--Steve Haflich is my technical
> reviewer--so if there's anything I can do from that perspective to
> facilitate the Allegro SLIME port, let me know. (Though Steve is
> also, as I understand it, the author of ELI so there may be limits
> to how much he or anyone at Franz will care about SLIME.)

There is an almost endless list of things I'd like to know about
Allegro internals.  E.g., I really wonder how they implement the
"compile modified definitions" commands; is it some heuristic or
actually some sort of compilation with macro expansion and other
complications?  Also a way to tell the compiler where the source comes
from would be very useful.  E.g., we would like to say that a piece
of code comes from a particular buffer so that the debugger knows
where to find it.  Is there some support for this?

> P.S. Are any of the SLIME hackers in the Bay Area? If so, I'd love to
> buy somebody dinner in return for getting a sit-down-at-a-computer
> tour of SLIME. I'm sure I can figure stuff out on my own but having
> someone who knows what they're doing show me the good bits will
> probably save me a bunch of time and decrease the chance I'll miss
> them altogether.

Perhaps James Bielman?  I think most others live in Europe.  

Helmut.