[Openmcl-devel] I made simple swank helper.

[Bill St. Clair]

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> 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>:
>
>> 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>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>
>> 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>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
>>> 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/e914c0db/attachment.htm>