[Openmcl-devel] I made simple swank helper.

Gary Byers gb at clozure.com
Mon May 16 10:53:23 PDT 2016

let me try again ...

If one wanted to use SLIME with CCL and did not want to experience the 
effects of :communication-style :spawn,
would using the SLIME-REPL Emacs package avoid those effects?

As far as I know, that Emacs package is used if one's .emacs file does

(slime-setup '(slime-fancy))
which is actually what 
<http://trac.clozure.com/ccl/wiki/InstallingSlime> suggests.

As your earlier message said. SLIME-REPL does indeed create a persistent 
thread, and forms read from that buffer are executed in that thread

a simpler way of demonstrating the problem is to simply create a lisp 
buffer , type
a few forms (e.g., a few calls to (RANDOM 100)) into that buffer, and 
note how things
like C-X C-E create a new thread to execute each of them in succession.  
When I last
tried to use SLIME, there was no slime-repl buffer or slime-repl thread, 
and all
interaction with SLIME took place (in a buffer named SLIME IIRC) in 
threads (via :communication-style :spawn).  I think that everyone agrees 
that this
is undesirable in many cases; I'm tired of seeing bug reports from 
people who claim
that executing a sequence of calls to (RANDOM 100) - and having them all 
return the
same value - indicates a bug in RANDOM, and more tired of subtler cases 
that people
still run into and  seem to rarely understand

On 05/16/2016 08:52 AM, Bill St. Clair wrote:
> At worst, when you want to evaluate a form in a lisp buffer that would 
> tickle the bug, you’d have to do an (in-package …) in the Slime-REPL, 
> to match the buffer, copy the form from the buffer, paste it into the 
> slime-repl, and press <enter>. So yes, that is a reasonable workaround.
> Slime, the way most of us use it, comes with a Slime Read-Eval-Print 
> loop buffer. Typing a form in that buffer sends it over to the 
> connected lisp process for evaluation, and prints the result, just as 
> you would expect from a REPL. It tends to be very slow if the result 
> string is very long, but that happens for me only rarely. The 
> Slime-REPL, just like any other Slime lisp-mode buffer, supports 
> symbol completion, meta-. for definition lookup, and connection to the 
> slime inspector.
> Bill
> On Sun, May 15, 2016 at 2:37 PM, Gary Byers <gb at clozure.com 
> <mailto:gb at clozure.com>> wrote:
>     Bill:
>     I didn't see the message from you (presumably because of problems
>     with my spam filter), but I did
>     see (and hopefully can reply to) this reply.
>     As far as you know, would people who use SLIME with CCL and want
>     to avoid at least many of the
>     problems with :communication-style :spawn be able to do so by
>     using SLIME-REPL, at least until
>     someone cam figure out how to make SWANK-HELPER easier to load?
>     (asked in very genuine ignorance of what "SLIME-REPL" is ..)
>     On 05/14/2016 05:47 PM, Dmitry Igrishin wrote:
>>     Hi Bill,
>>     2016-05-14 18:37 GMT+03:00 Bill St. Clair <wws at clozure.com
>>     <mailto:wws at clozure.com>>:
>>         I finally looked at the swank-helper package, and played with
>>         my Slime a little bit to determine why I’ve never noticed the
>>         problem. It’s my style of using Slime. I evaluate random
>>         forms in the *slime-repl ccl* buffer, which uses a single
>>         thread. The only evaluation I do from other lisp buffers is
>>         recompiling defining forms in file buffers. For that it very
>>         rarely matters that a new thread is spawned each time. So
>>         rarely that I have never had a problem with it.
>>     I don't tried the another IDE for Lisp called SLY -
>>     https://github.com/capitaomorte/sly
>>     but it looks interesting at the first glance. I'll try it at
>>     leisure.
>>         On Sat, May 14, 2016 at 11:19 AM, Gary Byers <gb at clozure.com
>>         <mailto:gb at clozure.com>> wrote:
>>             On 05/13/2016 04:03 PM, Dmitry Igrishin wrote:
>>>             2016-05-13 20:02 GMT+03:00 Gary Byers <gb at clozure.com
>>>             <mailto:gb at clozure.com>>:
>>>                 I don't use SLIME at all, largely because of the
>>>                 :COMMUNICATION-STYLE :SPAWN issues
>>>                 that Park Sungmin's patch tries to address and
>>>                 avoid. I have always assumed that people
>>>                 who do use SLIME with CCL either don't notice those
>>>                 issues or don't care about them as much
>>>                 as I do, and that people who use SLIME with other
>>>                 implementations don't experience the same
>>>                 issues because of (possibly very subtle)
>>>                 implementation-dependent details related to how
>>>                 threads and dynamic/special variable bindings
>>>                 interact with each other.  People do run into
>>>                 those issues fairly often, and my explanations of
>>>                 those issues seem to fall on deaf (or at
>>>                 least very bored) ears.
>>>             Gary, could you explain please your workflow on hacking
>>>             Lisp without using the SLIME? I've
>>>             always considered it as a de facto standard free IDE for
>>>             Lisp.
>>             I usually us ilisp. which only works at all under
>>             xemacs.  ilisp development nominally stopped about
>>             10-12 years ago, and whether or not xemacs is still being
>>             developed is unclear.  I don't think that
>>             using ilisp is a desirable option for anyone (including
>>             me)There have been other things that have bothered me about
>>             SLIME (as well the communication-style/spawn issues), but
>>             I would move away from ilisp in a heartbeat
>>             if not for those issues.
>>             I -think- that most people would agree that selecting and
>>             executing a set of lisp forms from an editor buffer
>>             should ideally be equivalent to (though perhaps more
>>             convenient than) executing the same set of forms by typing
>>             them directly into a REPL in some sort of terminal
>>             window. When the forms in question depend on and/or modify
>>             the dynamic execution context (thread, and
>>             thread-specific dynamic variable bindings) in which they
>>             are executed, this
>>             may not be true
>>             Whether or not someone is affected by these issues and
>>             the degree to which they are likely depends on their editing
>>             style and habits; people may find that it simply works
>>             better to select and execute an entire PROGN than it does to
>>             select and execute each of that PROGN's subforms, even if
>>             they may not be entirely clear on on why this is the case.
>>             see (for instance)
>>             <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>
>>             <https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html>,
>>             where that
>>             message was part of a discussion about apparent
>>             differences between what the language spec says and what some
>>             widely-used QuickLisp package expects.
>>             _______________________________________________
>>             Openmcl-devel mailing list
>>             Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>>             https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20160516/bc603037/attachment.htm>

More information about the Openmcl-devel mailing list