<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 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 href="mailto:wws@clozure.com" target="_blank">wws@clozure.com</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 href="https://github.com/capitaomorte/sly" target="_blank"></a><a 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 href="mailto:gb@clozure.com" target="_blank"></a><a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</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 href="mailto:gb@clozure.com" target="_blank"></a><a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</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 href="https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html" target="_blank"><https://lists.clozure.com/pipermail/openmcl-devel/2015-November/011091.html></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 href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
<a 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>