Re: [Sbcl-devel] sb-aclrepl package lossage

[Christophe R. <cs...@ca...>]

David Lichteblau <da...@li...> writes:

> Quoting Kevin Rosenberg (ke...@ro...):
>> Since multiple listeners is not an supported (at least by me) option,
>> I'm likely to revert the patch and ensure that single-listener REPL
>> works correctly.
>
> FWIW, I agree that reverting the patch makes sb-aclrepl more usable
> right now, both for single-thread and multi-thread users.  The bug makes
> sb-aclrepl misbehave quite horribly.
>
>> Of course, this is not to damper enthusiasm of anyone who wants to
>> supply a patch and support multiple listeners for threaded SBCL.
>
> Still, IMHO it would be a pity if multiple listeners did not work.
>
> Also, I cannot really say that I find my patch to be incorrect.  It is
> the rest of the toplevel machinery which is incorrect. :-)  That does
> not excuse my error.  But something feels wrong about the interaction of
> TOPLEVEL-REPL and *REPL-FUN*.

Shouldn't the bindings you introduced in SB-ACLREPL actually be done
outside the thing that calls *REPL-FUN*?  Handwavily: instead of

  (with-simple-restart (abort ...)
    (funcall *repl-fun*)) ; where *repl-fun* happens to bind *package* et al
we'd have
  (let ((*package* *package*) ...)
    (with-simple-restart (abort ...)
      (funcall *repl-fun*))) ; now *repl-fun* doesn't bind anything

Surely REPL functions are about reading, evaling and printing, and
what calls them is what is responsible for them having a sane
state... am I missing something?

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)