<div dir="ltr"><div class="gmail_default" 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><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 11:19 AM, 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"><span class="">
    <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">gb@clozure.com</a>></span>:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">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></blockquote></div><br></div>