[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
lisp
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
freshly-created
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