Development of the ilisp Emacs interface to Lisp

Bill Clementson | 2 Dec 2003 05:02

Re: [Ilisp-devel] SLIME

Luke Gorrie <luke <at> bluetail.com> writes:

> Bill Clementson <bill_clementson <at> yahoo.com> writes:
> 
> > Even if the eventual goal is to replace all the
functionality that
> > is provided by ILM/ILISP, ILISP would provide more
"short-term"
> > benefits for the SLIME CL developer than ILM
would.
> 
> That would have been one way, but we went the
clean-room approach. We
> only use ILM to start Lisp and compile our server,
and *inferior-lisp*
> as a debugging fallback. We've covered all the major
features now,
> although there's plenty of hacking left to do to get
all the details
> right and support everyone's favourite add-ons.
> 
> Starting from scratch means more work/fun, but it
also gives us a
> fresh codebase. To an outsider, some of the code in
ILISP is slightly
> terrifying , as in any program with such a long

Actually, to an insider, some of the code in ILISP is
a bit terrifying too

(Continue reading)

headers

Bill Clementson | 28 Nov 2003 22:13

Re: Re: [Ilisp-devel] SLIME

bmastenb <at> cs.indiana.edu wrote:

> On Nov 27, 2003, at 1:31 AM,
Bill_Clementson <at> peoplesoft.com wrote:
>> 2. Effort is put into creating more complete LEP
implementations for
>> different CL's so that ELI can be used effectively
on multiple CL
>> implementations. The benefit of this option is that
ELI is very
>> full-featured as it is and just the port of the
underlying 
>> communication
>> layer would need to be done. Also, since the
largest commercial CL 
>> vendor
>> supports ELI and actively enhances it, we can take
advantage of both
>> commercial and open source development efforts.

> As far as I understand it, LEP won't work on
non-threaded lisps, which 
> means there will always be room for a solution that
doesn't require 
> threading. Of course taking advantage of it where
present is great, but 
> right now SBCL lacks threads on anything but x86. 

I may be wrong, but my understanding was that:

(Continue reading)

headers

Bill Clementson | 28 Nov 2003 19:22

Re: [Ilisp-devel] SLIME

> Nicolas Neuss <Nicolas.Neuss <at> iwr.uni-heidelberg.de>
writes:

>> I would have preferred the option of LEP being
supported by the free Lisp
>> implementations (CMUCL, SBCL, CLISP, GCL). 

> David Lichteblau is working on this for SBCL. He
shares code with
> SLIME, since Dan is factoring all the
SBCL-deep-magic code into the
> SB-INTROSPECT library that we both use.

> His LEP-for-SBCL is at
http://www.lichteblau.com/src.html

>> Is LEP too complicated or otherwise bad, so that
SLIME became
>> necessary?

>Absolutely not.

Interesting, I wasn't aware that there was any sharing
going on between the SLIME and ELI-SBCL efforts. Since
you are obviously talking to each other and aware of
what the other is doing, how do you see the two
efforts evolving? Do you think they will continue to
be two separate efforts? If so, what segment of the
SBCL developer community do you feel would gravitate
towards SLIME as opposed to ELI-SBCL and why? In other

(Continue reading)

headers

Luke Gorrie | 28 Nov 2003 22:06

Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> Interesting, I wasn't aware that there was any sharing
> going on between the SLIME and ELI-SBCL efforts.

That's all Dan's doing with SB-INTROSPECT. I think he's got it exactly
right - the best way for us to all share code is for the Lisp
implementations to make supported interfaces for the functionality
that we need (e.g. finding definitions).

We should be able to do good sharing with ILISP this way too. The main
barrier for you guys, as I understand it, is that you're more
sympathetic to people who don't want to use the very latest of
everything, and won't have e.g. an SBCL with SB-INTROSPECT.

Ultimately though we should be able to share all the hairy-scary
non-portable code this way. Dan and Christophe from SBCL are leading
the charge admirably. We SLIME'ers haven't really engaged other
implementors, but do hope to work with the good folks doing CMUCL,
OpenMCL, LispWorks, and any other Lisps we end up supporting.

> Since you are obviously talking to each other and aware of what the
> other is doing, how do you see the two efforts evolving?

I for one am not big on planning the future, I've always found it
harmful in hobby-hacking. I think we'll all follow our noses, try to
write good code, and see where we end up.

As our common ancestor puts it: Don't think; hack. (*)

(Continue reading)

headers

Bill Clementson | 1 Dec 2003 03:28

Re: [Ilisp-devel] SLIME

--- Luke Gorrie <luke <at> bluetail.com> wrote:
> (*) This probably explains why loading inf-lisp
> hijacks all my
> lisp-mode key bindings, instead of being nice and
> using a minor-mode.

I found this comment curious as I thought that you
used only a TCP socket to communicate between emacs
and cl. I had a look at the source and you do require
inferior lisp mode (ILM) and comint mode. What is the
rationale for using both inferior lisp mode and a TCP
socket? Is your intention to entirely replace ILM with
socket communication or will you continue to use ILM
for some things and sockets for others?

--
Bill Clementson

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

(Continue reading)

headers

Daniel Barlow | 1 Dec 2003 03:54

Re: [slime-devel] Re: SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> I found this comment curious as I thought that you
> used only a TCP socket to communicate between emacs
> and cl. I had a look at the source and you do require
> inferior lisp mode (ILM) and comint mode. What is the
> rationale for using both inferior lisp mode and a TCP
> socket? Is your intention to entirely replace ILM with
> socket communication or will you continue to use ILM
> for some things and sockets for others?

"Require" may be a bit of a strong word: it is possible to run SLIME
with only the TCP connection (e.g. to a lisp on another machine) but
you need to (swank:create-swank-server) on the CL by hand before
running slime-connect.  

That said, yes, if you run the default M-x slime it does use
inferior-lisp to start up a lisp implementation.  I think the plan
is to make inferior-lisp largely unnecessary, but in the meantime for
purposes of hacking slime itself it's damned handy to have an
alternate route into Lisp when things get wedged.

(There's also the problem that although we can redirect all 'normal'
lisp output, we don't currently trap anything in the lisp that
bypasses the streams layer (e.g. foreign code printing to file
descriptors) so that winds up in *inferior-lisp* as well.  I'm sure we
can solve this some other way, but thus far we haven't)

-dan

(Continue reading)

headers

Bill Clementson | 1 Dec 2003 05:23

Re: Re: [Ilisp-devel] SLIME


--- Daniel Barlow <dan <at> telent.net> wrote:
> Bill Clementson <bill_clementson <at> yahoo.com> writes:
> 
> > I found this comment curious as I thought that you
> > used only a TCP socket to communicate between
> emacs
> > and cl. I had a look at the source and you do
> require
> > inferior lisp mode (ILM) and comint mode. What is
> the
> > rationale for using both inferior lisp mode and a
> TCP
> > socket? Is your intention to entirely replace ILM
> with
> > socket communication or will you continue to use
> ILM
> > for some things and sockets for others?
> 
> "Require" may be a bit of a strong word: it is
> possible to run SLIME
> with only the TCP connection (e.g. to a lisp on
> another machine) but
> you need to (swank:create-swank-server) on the CL by
> hand before
> running slime-connect.  
> 
> That said, yes, if you run the default M-x slime it
> does use
> inferior-lisp to start up a lisp implementation.  I

(Continue reading)

headers

Luke Gorrie | 1 Dec 2003 20:19

Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> Even if the eventual goal is to replace all the functionality that
> is provided by ILM/ILISP, ILISP would provide more "short-term"
> benefits for the SLIME CL developer than ILM would.

That would have been one way, but we went the clean-room approach. We
only use ILM to start Lisp and compile our server, and *inferior-lisp*
as a debugging fallback. We've covered all the major features now,
although there's plenty of hacking left to do to get all the details
right and support everyone's favourite add-ons.

Starting from scratch means more work/fun, but it also gives us a
fresh codebase. To an outsider, some of the code in ILISP is slightly
terrifying , as in any program with such a long history. We also
wanted to do most things differently and to have an environment more
like the elisp one, so it would only give us a head-start in the
short-term.

ELI really doesn't appeal to my hackstincts. From the web I can't even
tell who wrote it, and most questions on groups.google.com seem to go
without definitive answers. I downloaded my copy from Neil van Dyke's
website, which says "Please do not pester Franz to support this
packaging, lest they regret GPL'ing."

It looks like Franz did the least necessary to be allowed to link with
Emacs under the GPL, and would be unlikely to let a dozen random
hackers into their CVS tree  so that is a potential dead-end.

So I think our approach is pretty reasonable. We'll see how it

(Continue reading)

headers

Helmut Eller | 1 Dec 2003 09:03

Re: Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> Thanks for the clarification. Incidentally, what was
> the rationale for using inferior lisp mode instead of
> ilisp to "boot-strap" development? ILISP has some of
> the same "negatives" as ILM (since both were built on
> comint mode) however it has a lot more functionality
> than ILM. It seems like (at least to me) it would have
> made more sense creating SLIME extensions on top of
> ILISP rather than ILM since there is so much more
> functionality in ILISP than there is in ILM. Even if
> the eventual goal is to replace all the functionality
> that is provided by ILM/ILISP, ILISP would provide
> more "short-term" benefits for the SLIME CL developer
> than ILM would.

I think the reason is that Eric Marsden, the author of SLIME's initial
version (at that time called SLIM) uses inf-lisp and not ILISP.  I
don't know what Luke used before SLIME, but I too used inf-lisp.

SLIME is now good enough for developing SLIME and at this stage it
simpler to add any missing functionality to SLIME itself than to make
it work with ILISP.  The advantage of inf-lisp over ILISP is that
inf-lisp is simpler and more robust.  Since we use inf-lisp primarily
as fallback when everything else fails, inf-lisp seems to be
preferable.

Helmut.

_______________________________________________

(Continue reading)

headers

Bill Clementson | 1 Dec 2003 16:29

Re: Re: [Ilisp-devel] SLIME


--- Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> wrote:
> Bill Clementson <bill_clementson <at> yahoo.com> writes:
> 
> > Thanks for the clarification. Incidentally, what
> was
> > the rationale for using inferior lisp mode instead
> of
> > ilisp to "boot-strap" development? 
[snip]
> I think the reason is that Eric Marsden, the author
> of SLIME's initial
> version (at that time called SLIM) uses inf-lisp and
> not ILISP.  I
> don't know what Luke used before SLIME, but I too
> used inf-lisp.
> 
> SLIME is now good enough for developing SLIME and at
> this stage it
> simpler to add any missing functionality to SLIME
> itself than to make
> it work with ILISP.  The advantage of inf-lisp over
> ILISP is that
> inf-lisp is simpler and more robust.  Since we use
> inf-lisp primarily
> as fallback when everything else fails, inf-lisp
> seems to be
> preferable.

Fair enough. But, could you elaborate on where you

(Continue reading)

headers

Helmut Eller | 1 Dec 2003 17:06

Re: Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> Fair enough. But, could you elaborate on where you
> feel inf-lisp is more robust than ILISP? I know that
> there were a lot of quality issues a while ago;
> however, I believe that most of those have been
> addressed in the last couple of releases. I would have
> thought that ILISP today would be no less robust than
> inf-lisp.

I haven't used ILISP for some time and things may have changed in the
meantime, but I think ILISP needs a way to detect the prompt of the
Lisp to work properly.  I think ILISP hangs or breaks if the prompt
regexp is not set correctly.  AFAIK inf-lisp also uses a such a
regexp, but doesn't break if the regexp is wrong.  So in this sense
inf-lisp is more robust.

Helmut.

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

headers

Bill Clementson | 3 Dec 2003 06:43

Re: [slime-devel] Re: SLIME

Edi Weitz <edi <at> agharta.de> writes:

[snip]
> The patch below tries to address this. 
[snip]

Thanks for the patch. I have applied it in cvs.

--
Bill Clementson

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

headers

Luke Gorrie | 1 Dec 2003 17:20

Re: [Ilisp-devel] SLIME

Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> writes:

> I haven't used ILISP for some time and things may have changed in the
> meantime, but I think ILISP needs a way to detect the prompt of the
> Lisp to work properly.  I think ILISP hangs or breaks if the prompt
> regexp is not set correctly.  AFAIK inf-lisp also uses a such a
> regexp, but doesn't break if the regexp is wrong.  So in this sense
> inf-lisp is more robust.

FWIW, I always used ILISP before, and this was the big problem for
me. It seemed very common when Lisp was asynchronously printing
messages, then it would get wedged when e.g. trying to fetch an
arglist. Sometimes combinations of C-g and `M-x repair-ilisp' would
unwedge it, but other times I'd need to restart Lisp.

Also, I really wished that printed output from Lisp would be inserted
before the prompt. That may even fix the problem above by keeping the
prompt in the right place.

Cheers,
Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

headers

Bill Clementson | 28 Nov 2003 22:49

Re: SLIME

--- Luke Gorrie <luke <at> bluetail.com> wrote:
> Bill Clementson <bill_clementson <at> yahoo.com> writes:
> 
> > Interesting, I wasn't aware that there was any
> sharing
> > going on between the SLIME and ELI-SBCL efforts.
> 
> That's all Dan's doing with SB-INTROSPECT. I think
> he's got it exactly
> right - the best way for us to all share code is for
> the Lisp
> implementations to make supported interfaces for the
> functionality
> that we need (e.g. finding definitions).
> 
> We should be able to do good sharing with ILISP this
> way too. The main
> barrier for you guys, as I understand it, is that
> you're more
> sympathetic to people who don't want to use the very
> latest of
> everything, and won't have e.g. an SBCL with
> SB-INTROSPECT.

I can't speak for ILISP; however, I don't think the
maintainers have ever been unsympathetic to
incorporating innovations into the code base. ILISP
does need to work with a wide variety of CL and Scheme
implementations though so implementation-specific
enhancements can't break functionality for other

(Continue reading)

headers

Bill Clementson | 27 Nov 2003 23:35

Re: SLIME

Nicolas.Neuss <at> iwr.uni-heidelberg.de writes:

>Bill_Clementson writes:

>> I would be interested in hearing what others think
about these different
>> scenarios. In all probability,  scenario #1 will
prevail; however, I would
>> like to hear what others think about the different
options (as well as
>> options that I haven't thought of).

>One question: is the license status of ILISP now
completely clear?  If not,
>there might be an advantage from building things anew
as SLIME does.

I'm not sure. I know that Kevin Rosenberg went through
quite an extensive effort a while ago to try to clear
up the license status. In any case, the license issue
is probably only going to be important to you if (a)
you have religious convictions in this area or (b) you
want to bundle ILISP and need to ensure that it's
license is conformant with what you are trying to
create. For Joe Hacker who just wants a tool to help
him develop software with, ILISP is "free" enough.

>I would have preferred the option of LEP being
supported by the free Lisp
>implementations (CMUCL, SBCL, CLISP, GCL).  Is LEP

(Continue reading)

headers

Bill Clementson | 27 Nov 2003 23:58

Re: Re: [Ilisp-devel] SLIME

>> 3. Flesh out SLIME with the functionality that is
available today in ILISP
>> and ELI. This is the "clean slate" option. It would
allow for a new Emacs
>> CL mode to be developed utilizing the best ideas
from ILISP & ELI. It also
>> requires the greatest amount of effort.

>s/effort/fun/ 

Yes, that's a valid reason. However, if I do a wc of
the elisp files in the different packages, I get the
following results (lines/words/chars):

SLIME: 4345/14463/161611
ILISP: 15466/63798/565273
ELI: 19801/77244/743786

According to these figures, you've still got a lot of
fun ahead of you to get feature parity with ILISP/ELI


>This is firmly the path we've taken, except that
we're primarily
>stealing ideas from Emacs Lisp's development
environment.

And some of the stuff that I've seen come out of SLIME
looks pretty neat. So far, I've only been able to
drool over screen shots as I primarily use MS Windows.

(Continue reading)

headers

Hannu Koivisto | 30 Nov 2003 23:58

Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> I'm not advocating adding TCP socket code to ILISP or
> merging ILISP and SLIME. I just consider that another
> option. As I said, it could be a "win-win option" but
> it might also be a "Frankenstein". Since ILISP was
> built on top of comint mode, it would probably be too
> much effort to retrofit socket communication support
> as an alternative. 

In a sense SLIME uses socket communication, yeah, it probably would
be, but if you simply want to connect to a repl through a socket,
comint supports that already.  You might need an additional channel
for sending signals.

--

-- 
Hannu

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

headers

Luke Gorrie | 28 Nov 2003 09:51

Re: Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> >s/effort/fun/ 
> 
> Yes, that's a valid reason. However, if I do a wc of
> the elisp files in the different packages, I get the
> following results (lines/words/chars):
> 
> SLIME: 4345/14463/161611
> ILISP: 15466/63798/565273
> ELI: 19801/77244/743786
> 
> According to these figures, you've still got a lot of
> fun ahead of you to get feature parity with ILISP/ELI
> 

You might be surprised. If we copy that 15-year-old beta copy of
comint.el that ILISP mysteriously includes into SLIME, we can grow by
25% right now 

Time will tell all 

Cheers,
Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

(Continue reading)

headers

Bill Clementson | 28 Nov 2003 19:07

Re: Re: [Ilisp-devel] SLIME

--- Luke Gorrie <luke <at> bluetail.com> wrote:
> Bill Clementson <bill_clementson <at> yahoo.com> writes:
> > According to these figures, you've still got a lot
> of
> > fun ahead of you to get feature parity with
> ILISP/ELI
> > 
> 
> You might be surprised. If we copy that 15-year-old
> beta copy of
> comint.el that ILISP mysteriously includes into
> SLIME, we can grow by
> 25% right now 

Yeah, and if you copy in hyperspec.el and
completer.el, you'll grow by another 25% too. Oops,
never mind, I see you've already done that... 

Cheers,
Bill

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

(Continue reading)

headers

Luke Gorrie | 28 Nov 2003 21:16

Re: Re: [Ilisp-devel] SLIME

Bill Clementson <bill_clementson <at> yahoo.com> writes:

> Yeah, and if you copy in hyperspec.el and completer.el, you'll grow
> by another 25% too. Oops, never mind, I see you've already done
> that... 

Oooh, that hurts..

.. or at least, it would if I hadn't just removed the 1143-line
completer.el and replaced it with half a page of new CL code.

Bugger. We'll never reach 15000 lines at this rate. 

(hyperspec.el doesn't count - we're just bundling it for convenience,
our only dependency is a key-binding.)

Thanks for keeping a guy on his toes 
-Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

headers

Bill Clementson | 28 Nov 2003 21:50

Re: [slime-devel] Re: SLIME


--- Luke Gorrie <luke <at> bluetail.com> wrote:
> Bill Clementson <bill_clementson <at> yahoo.com> writes:
> 
> > Yeah, and if you copy in hyperspec.el and
> completer.el, you'll grow
> > by another 25% too. Oops, never mind, I see you've
> already done
> > that... 
> 
> Oooh, that hurts..

Hehe, sorry about that, but I couldn't resist ...

> .. or at least, it would if I hadn't just removed
> the 1143-line
> completer.el and replaced it with half a page of new
> CL code.
> 
> Bugger. We'll never reach 15000 lines at this rate.
> 

That's the problem with refactoring, your loc count
never looks as impressive 

> (hyperspec.el doesn't count - we're just bundling it
> for convenience,
> our only dependency is a key-binding.)
> 
> Thanks for keeping a guy on his toes

(Continue reading)

headers

Bill_Clementson | 27 Nov 2003 07:31

Re: [Ilisp-devel] SLIME


Hi Luke,

I've been following "SLIME" with some interest.

Historically, the three main Emacs modes that people have used for CL
development were Inferior Lisp Mode (ILM), ILISP and ELI (developed by
Franz). ILM & ILISP worked with most CL implementations but were
constrained by having been built on top of comint mode (This sometimes
results in lock-ups. Also, since comint mode has a single line of
communication between Emacs and the CL implementation, it is not possible
to take advantage of multiprocessing if the CL implementation supports MP).
ELI doesn't have the comint heritage of ILM and ILISP. It (like SLIME) uses
a TCP socket to talk to CL and you can have multiple threads of
communication open to the CL implementation. Although ELI was developed by
Franz, it was released under the GPL and some people have done some work
towards porting it to CMUCL and SBCL. I think that the approach taken by
ELI and SLIME is the preferable approach; however, ILISP and ILM are both
widely used simply because they are the only option available with many CL
implementations (for people who want to use Emacs) .

I think there are a number of different possible scenarios that might
develop:

1. Status quo: ILM, ILISP, ELI and SLIME all coexist. Having multiple Emacs
CL modes is in some ways a benefit as it gives people choice; however, it
also means that multiple people are all working on divergent efforts to
achieve a similar result.
2. Effort is put into creating more complete LEP implementations for
different CL's so that ELI can be used effectively on multiple CL

(Continue reading)

headers

Brian Mastenbrook | 28 Nov 2003 04:44

Re: Re: [Ilisp-devel] SLIME

On Nov 27, 2003, at 1:31 AM, Bill_Clementson <at> peoplesoft.com wrote:

> 2. Effort is put into creating more complete LEP implementations for
> different CL's so that ELI can be used effectively on multiple CL
> implementations. The benefit of this option is that ELI is very
> full-featured as it is and just the port of the underlying 
> communication
> layer would need to be done. Also, since the largest commercial CL 
> vendor
> supports ELI and actively enhances it, we can take advantage of both
> commercial and open source development efforts.

As far as I understand it, LEP won't work on non-threaded lisps, which 
means there will always be room for a solution that doesn't require 
threading. Of course taking advantage of it where present is great, but 
right now SBCL lacks threads on anything but x86. If you want to help 
out, I'm sure that we'd take any code patches towards getting gencgc 
working on PowerPC - it's not a trivial matter though, and in the 
meantime I enjoy having a development environment that works on SBCL/OS 
X.

--
Brian Mastenbrook
bmastenb <at> cs.indiana.edu
http://cs.indiana.edu/~bmastenb/

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

(Continue reading)

headers

Luke Gorrie | 27 Nov 2003 16:05

Re: Re: [Ilisp-devel] SLIME

Bill_Clementson <at> peoplesoft.com writes:

> 3. Flesh out SLIME with the functionality that is available today in ILISP
> and ELI. This is the "clean slate" option. It would allow for a new Emacs
> CL mode to be developed utilizing the best ideas from ILISP & ELI. It also
> requires the greatest amount of effort.

s/effort/fun/ 

This is firmly the path we've taken, except that we're primarily
stealing ideas from Emacs Lisp's development environment.

> 4. Integrate SLIME and ILISP. This would add multiprocessing support to
> ILISP and would allow SLIME to take advantage of the rich functionality
> already built into ILISP.

As Dan mentioned, we don't do any multiprocessing yet, though we hope
our infrastructure will permit it with minimal rewriting.

If you guys are interested in using TCP for your connection, the
socket code is pretty easy. I don't think merging with SLIME would be
a practical way to do it though.

BTW, the interesting aspect of SLIME is the depth of our Emacs/Lisp
integration. For example, we have rewritten parts of the Common Lisp
top-level and debugger in Elisp, and made Emacs understand Lisp
compiler messages very well. The socket stuff is just a boring
implementation detail.

Cheers,

(Continue reading)

headers

Nicolas Neuss | 27 Nov 2003 15:33

Re: [Ilisp-devel] SLIME

Bill_Clementson <at> peoplesoft.com writes:

> I would be interested in hearing what others think about these different
> scenarios. In all probability,  scenario #1 will prevail; however, I would
> like to hear what others think about the different options (as well as
> options that I haven't thought of).

One question: is the license status of ILISP now completely clear?  If not,
there might be an advantage from building things anew as SLIME does.

I would have preferred the option of LEP being supported by the free Lisp
implementations (CMUCL, SBCL, CLISP, GCL).  Is LEP too complicated or
otherwise bad, so that SLIME became necessary?

Nicolas.

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

headers

Luke Gorrie | 28 Nov 2003 10:28

Re: [Ilisp-devel] SLIME

Nicolas Neuss <Nicolas.Neuss <at> iwr.uni-heidelberg.de> writes:

> I would have preferred the option of LEP being supported by the free Lisp
> implementations (CMUCL, SBCL, CLISP, GCL). 

David Lichteblau is working on this for SBCL. He shares code with
SLIME, since Dan is factoring all the SBCL-deep-magic code into the
SB-INTROSPECT library that we both use.

His LEP-for-SBCL is at http://www.lichteblau.com/src.html

> Is LEP too complicated or otherwise bad, so that SLIME became
> necessary?

Absolutely not.

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

headers

Daniel Barlow | 27 Nov 2003 15:15

Re: [slime-devel] Re: SLIME

Bill_Clementson <at> peoplesoft.com writes:

> 4. Integrate SLIME and ILISP. This would add multiprocessing support to
> ILISP and would allow SLIME to take advantage of the rich functionality
> already built into ILISP. Perhaps comint mode support could be retained and
> the SLIME TCP socket communication protocol is provided as just another
> option (not all CL's support multiprocessing and ILISP also supports a lot
> of Scheme implementations that don't support multiprocessing so not
> everyone would benefit from ILISP moving away from comint mode). This might
> be a win-win option. It might also be a "Frankenstein" approach that could
> hurt both.

SLIME does not currently have any special support for multithreaded
Lisp (although I'm currently using it with one and speculating on how
it could be arranged).  It does need an asynchronous TCP socket, that
is true, but that can be done without threads if some other mechanism
is available: in CMUCL and SBCL it hooks the event loop with
SERVE-EVENT.

The out-of-band communication is for me SLIME's biggest selling point
over ILISP, architecture-wise: the chance of it getting confused is so
much less (although it should be admitted that it can quite happily
get confused for other reasons, but that's at least partly because I'm
using it to develop itself).  There are regexps in the ilisp support
for SBCL than I don't understand the purpose of, and I put them there ...

-dan

--

-- 
   http://web.metacircles.com/ - CL custom development and SBCL support

(Continue reading)