Helmut Eller e9626484@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 :-)