[Openmcl-devel] I made simple swank helper.

[Dmitry Igrishin]

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
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> 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>:
>>
>>> 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/20160515/774ef846/attachment.htm>