[slime-devel] Re: OpenMCL

[Luke Gorrie]

Sven Van Caekenberghe <sven at beta9.be> writes:

> In the general discussion about SLIME and debugging, I think that a
> way to recover better from 'problems' (i.e. SLIME losing control and
> an error appearing in the inferior lisp) so that one can continue to
> work. The greatest showstopper is that you have to relaunch the
> inferior lisp (or worse, that emacs hangs waiting for something).

Does this happen to you with single-threaded code, or just
multithreaded? If single-threaded, please post more details -- those
bugs must be fixed, and I rarely hit them myself (under CMUCL).

If multithreaded, well, it's a miracle if SLIME works at all at the
moment :-)

> Is there some release tagging for SLIME ? I think it would be useful
> for users to be able to report bugs against version numbers - just a
> thought.

We do have these, you can find them like this:

  $ cvs status -v slime.el
  ===================================================================
  File: slime.el          Status: Needs Patch

     Working revision:    1.143
     Repository revision: 1.144   /project/slime/cvsroot/slime/slime.el,v
     Sticky Tag:          (none)
     Sticky Date:         (none)
     Sticky Options:      (none)

     Existing Tags:
          SLIME-0-9                       (revision: 1.135)
          SLIME-0-8                       (revision: 1.101)
          SLIME-0-7                       (revision: 1.86)
          SLIME-0-6                       (revision: 1.59)
          backhackattack-1                (branch: 1.59.2)
          BACKHACKATTACK-1                (revision: 1.59)
          SLIME-0-5                       (revision: 1.56)
          SLIME-0-4                       (revision: 1.32)
          FAIRLY-STABLE                   (revision: 1.135)
          SLIME-0-3                       (revision: 1.26)
          SLIME-0-2                       (revision: 1.1)

The tag FAIRLY-STABLE is always the same as the highest SLIME-x-y. I
think we mostly assume that current SLIME users are bleeding-edge
masochists and will be running from CVS HEAD, and only reverting to
FAIRLY-STABLE temporarily when they have problems.

However, it's perfectly fine and sensible to run off FAIRLY-STABLE all
the time :-). If you want to do this and you hit a bug, you might want
to check if it's been fixed in HEAD by looking at the ChangeLog diff
like this:

  cvs diff -r FAIRLY-STABLE -r HEAD ChangeLog

When reporting a bug, please do mention the code vintage you're
running.

Cheers,
Luke