<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>let me try again ...<br>
<br>
If one wanted to use SLIME with CCL and did not want to experience
the effects of :communication-style :spawn,<br>
would using the SLIME-REPL Emacs package avoid those effects?<br>
<br>
As far as I know, that Emacs package is used if one's .emacs file
does <br>
<br>
(slime-setup '(slime-fancy))<br>
which is actually what
<a class="moz-txt-link-rfc2396E" href="http://trac.clozure.com/ccl/wiki/InstallingSlime"><http://trac.clozure.com/ccl/wiki/InstallingSlime></a> suggests.<br>
<br>
As your earlier message said. SLIME-REPL does indeed create a
persistent lisp<br>
thread, and forms read from that buffer are executed in that
thread<br>
<br>
a simpler way of demonstrating the problem is to simply create a
lisp buffer , type<br>
a few forms (e.g., a few calls to (RANDOM 100)) into that buffer,
and note how things<br>
like C-X C-E create a new thread to execute each of them in
succession. When I last<br>
tried to use SLIME, there was no slime-repl buffer or slime-repl
thread, and all <br>
interaction with SLIME took place (in a buffer named SLIME IIRC)
in freshly-created<br>
threads (via :communication-style :spawn). I think that everyone
agrees that this<br>
is undesirable in many cases; I'm tired of seeing bug reports from
people who claim<br>
that executing a sequence of calls to (RANDOM 100) - and having
them all return the<br>
same value - indicates a bug in RANDOM, and more tired of subtler
cases that people<br>
still run into and seem to rarely understand<br>
<br>
</tt><br>
<div class="moz-cite-prefix">On 05/16/2016 08:52 AM, Bill St. Clair
wrote:<br>
</div>
<blockquote
cite="mid:CAARJRB4HN6HXfyqrJHVds+wrH+fS6MxOkD-MY7tSCanfp05K_Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Bill</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, May 15, 2016 at 2:37 PM, Gary
Byers <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <tt>Bill:<br>
<br>
I didn't see the message from you (presumably because of
problems with my spam filter), but I did<br>
see (and hopefully can reply to) this reply.<br>
<br>
As far as you know, would people who use SLIME with CCL
and want to avoid at least many of the<br>
problems with :communication-style :spawn be able to do
so by using SLIME-REPL, at least until<br>
someone cam figure out how to make SWANK-HELPER easier
to load?<br>
<br>
(asked in very genuine ignorance of what "SLIME-REPL" is
..)<br>
</tt>
<div>
<div class="h5"><br>
<div>On 05/14/2016 05:47 PM, Dmitry Igrishin wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Bill,
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-05-14 18:37
GMT+03:00 Bill St. Clair <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:wws@clozure.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:wws@clozure.com">wws@clozure.com</a></a>></span>:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-size:small">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.</div>
</div>
</blockquote>
<div>I don't tried the another IDE for Lisp
called SLY - <a moz-do-not-send="true"
href="https://github.com/capitaomorte/sly"
target="_blank">https://github.com/capitaomorte/sly</a></div>
<div>but it looks interesting at the first
glance. I'll try it at leisure. </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>On Sat, May 14, 2016 at 11:19 AM,
Gary Byers <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gb@clozure.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:gb@clozure.com">gb@clozure.com</a></a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<div>
<div text="#000000"
bgcolor="#FFFFFF"><span> <br>
<br>
<div>On 05/13/2016 04:03 PM,
Dmitry Igrishin wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-05-13
20:02 GMT+03:00 Gary
Byers <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:gb@clozure.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:gb@clozure.com">gb@clozure.com</a></a>></span>:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
don't use SLIME at
all, largely because
of the
:COMMUNICATION-STYLE
:SPAWN issues<br>
that Park Sungmin's
patch tries to
address and avoid.
I have always
assumed that people<br>
who do use SLIME
with CCL either
don't notice those
issues or don't care
about them as much<br>
as I do, and that
people who use SLIME
with other
implementations
don't experience the
same<br>
issues because of
(possibly very
subtle)
implementation-dependent
details related to
how<br>
threads and
dynamic/special
variable bindings
interact with each
other. People do
run into<br>
those issues fairly
often, and my
explanations of
those issues seem to
fall on deaf (or at<br>
least very bored)
ears.<br>
</blockquote>
<div>Gary, could you
explain please your
workflow on hacking
Lisp without using
the SLIME? I've</div>
<div>always considered
it as a de facto
standard free IDE
for Lisp.</div>
<br>
</div>
</div>
</div>
</blockquote>
</span> I usually us ilisp.
which only works at all under
xemacs. ilisp development
nominally stopped about<br>
10-12 years ago, and whether or
not xemacs is still being
developed is unclear. I don't
think that <br>
using ilisp is a desirable
option for anyone (including
me)There have been other things
that have bothered me about<br>
SLIME (as well the
communication-style/spawn
issues), but I would move away
from ilisp in a heartbeat<br>
if not for those issues.<br>
<br>
I -think- that most people would
agree that selecting and
executing a set of lisp forms
from an editor buffer<br>
should ideally be equivalent to
(though perhaps more convenient
than) executing the same set of
forms by typing<br>
them directly into a REPL in
some sort of terminal window.
When the forms in question
depend on and/or modify<br>
the dynamic execution context
(thread, and thread-specific
dynamic variable bindings) in
which they are executed, this<br>
may not be true<br>
Whether or not someone is
affected by these issues and the
degree to which they are likely
depends on their editing<br>
style and habits; people may
find that it simply works better
to select and execute an entire
PROGN than it does to<br>
select and execute each of that
PROGN's subforms, even if they
may not be entirely clear on on
why this is the case.<br>
see (for instance) <a
moz-do-not-send="true"
href="https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html"
target="_blank"><a class="moz-txt-link-rfc2396E" href="https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html"><https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html></a></a>,
where that<br>
message was part of a discussion
about apparent differences
between what the language spec
says and what some<br>
widely-used QuickLisp package
expects.<br>
<br>
<br>
<br>
<br>
<br>
</div>
<br>
</div>
</div>
<span>_______________________________________________<br>
Openmcl-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openmcl-devel@clozure.com"
target="_blank">Openmcl-devel@clozure.com</a><br>
<a moz-do-not-send="true"
href="https://lists.clozure.com/mailman/listinfo/openmcl-devel"
rel="noreferrer" target="_blank">https://lists.clozure.com/mailman/listinfo/openmcl-devel</a><br>
<br>
</span></blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>