[slime-devel] Re: eval-string bug?

[Luke Gorrie]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> A single variable for slime-read-string-tag could cause some trouble.
> Reading from the REPL can be invoked recursively, because the user can
> evaluate arbitrary code, e.g, with C-c C-:.

True, thanks.

I've been working on getting it through the test suite. I'm down to
two failing tests, but there are other missing things (like this
read-string bit).

For read-string maybe the solution is for Emacs to just send
(repl-input <string>) and let Lisp decide what to do with it.

I also found an exciting new class of dastardly hard bug :-) example:

  Make async request
  Make sync request A
  Async reply arrives, in continuation:
    Make sync request B
    Result of A arrives and is thrown up the stack past B's handler

Can involve a lot of "what happened to A?" head-scratching :-)

With the old protocol we didn't have this problem since it was illegal
to make two requests in a row. On the other hand, this wasn't as hard
to debug as an `activate'-related bug in the state machine once, and I
_think_ it can be solved by the rule "don't make synchronous requests
from asynchronous continuations".

Currently the "interesting" bit is figuring out what slime-sync,
slime-busy-p, etc are supposed to do, or how to change their
callers. This is the chance to make it compatible with out-of-order
(e.g. thread-per-request) operation.

> Lots of code deleted! That's good :-)

Let's hope it can stay deleted :-) will see how far I can get tonight.

Current patch attached. It contains "more than a couple" of
debug-printfs, mostly as a relic of chasing the aforementioned bug :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: slime-chaos2.patch
Type: text/x-patch
Size: 40600 bytes
Desc: More chaos!
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20040125/beb2f596/attachment.bin>