<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/13/2016 04:03 PM, Dmitry Igrishin
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP+w2GrDucL8GL7FpMcWjYC0PWA7y3WO=pX5_qEHbrp8w7oVrQ@mail.gmail.com"
      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">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>
    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 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>,
    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>
  </body>
</html>