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

[Helmut Eller]

Luke Gorrie <luke at bluetail.com> writes:

> Maybe a better idea would have been to go for chaos? We send N
> requests to Lisp at a time, and it replies in any order (with an ID
> tag to identify the result), we can get multiple unknown threads
> hitting the debugger at the same time, etc.

I tried to remove the state machine some time ago, but wasn't very
successful.  The id argument in eval-string stems from that attempt.

Here some problems I encountered:

The current state stack contains (state-name . variables) pairs.  It
wasn't obvious to me where I should store the variables instead.
Including the variables in the request itself doesn't work, because
the variables contain things like window configurations.  Storing them
in a buffer -- e.g., the variables of the debugging state in the sldb
buffer -- doesn't work because the user can delete the buffer.  So I
stored them on a stack again :-)

Another problem was that there where no 'activate' events anymore.
When you exited from the debugger at level 3 to level 2, Emacs didn't
notice it.  My idea was to generate the activate events at the Lisp
side.  So I changed the Lisp sldb-loop and sent an 'activate-debugger'
event every time before reading the next request. The sldb-loop looked
like this:

 (send-to-emacs '(:initialize-debugger ...))
 (loop
   (send-to-emacs '(:activate-debugger ...))
   (read-from-emacs))

This too was problematic, because the :initialize-debugger event could
cause a RPC from Emacs to Lisp (e.g., fetching the backtrace).  But
the result of the RPC arrived after the :activate-event.  I gave at
this point.

I think we cannot blindly accept every event at any time.  Maybe we
need something like a mailbox with Erlang-style selective receive :-)

Helmut.