| Age | Commit message (Collapse) | Author |
|---|
|
If literals were present chicken wouldn't provide any autodocumentation
due to an error. Module evaluation was failing due to poor
input. Chicken's Error output was failing to parse
- Filter out all non-symbols from the autodoc set
- Properly escape module names
- Add "Error" to the set of accepted error prefixes
|
|
Soooo, the long delay experienced when evaluating long string lists in
Guile had nothing to do with the time took by emacs to read the response
from the scheme process; that process is always a breeze, no matter or
its format or number of newlines. The delay was provoked by an innocent
looking function that scans the received string (which includes a prompt
at the end as an EOT marker) to check whether Guile (or any other
scheme) has just entered the debugger (that's done inside
`geiser-con--connection-update-debugging`). For some reason,
`string-match` on that kind of string using Guile's regexp for a debug
prompt takes forever. Instead of trying to optimize the regular
expression, i've just applied it to the *second* line of the received
string, which is the one that contains the response's prompt.
|
|
Such as (values), which produce a retort of the form ((result) ...),
which has nothing wrong in it! Thanks to Diogo.
|
|
Autodoc was firing while the REPL was waiting for input of a (read)
call, causing all kinds of misbehaviour. We now inhibit autodoc on
sending a form for evaluation and re-inhibit it once a prompt is read
back again.
|
|
|
|
|
|
We weren't tracking the "enter debugger" event correctly, and all
evaluations in debug mode were failing. There's still (at least)
another bug, because error navigation in backtraces seems broken.
|
|
Some schemes (okay, Guile) may output spurious messages besides a
well-formed retort. This will be eventually fixed; in the meantime,
we try to skip the noise (and may fail miserably if that noise has a
form similar to the signal we search).
|
|
My previous attempt was bogus! Also, i'm taking advantage of our
sending queries serially to simplify transaction queue processing, and
to clean after ourserlves on error.
|
|
I've observed that autodoc requests in connections to tekuti processes
often miss their deadline. This was causing serialization problems,
fixed (i think) by this patch; but we still have the problem of too
many misses, which could be fixed by making autodoc asynchronous (and
we probably need this for really remote connections anyway).
|
|
I've eliminated the annoying *spurious* popup produced by tq, so that
Geiser can recover from error conditions arising from unexpected
input to a transaction queue that has no active transaction. We now
log the offending input and keep going.
Greg, over at racket's list, reported such a happening when leaving
the REPL after C-u C-c C-z; but i've been unable to reproduce the
problem. Probably, we have a bug lurking somewhere that this patch
doesn't fix, but at least it should work as a palliative.
|
|
Let's not wait for active connections to clear their queue when we're
shutting down the REPL.
|
|
Nothing here, move on.
|
|
Separate connections for the REPL and Geiser commands was kind of
neat, but it had the problem of synchronising the current namespace
for both connections. A quick fix would have been to ask the scheme
for the current namespace for every Geiser command in the REPL, but
that, besides clunky, would add potentially prohibitive overhead for
(real) remote connections.
As it happens, using a single connection turned out to be not that
difficult and relatively clean code-wise. We could even turn back to
not use inferior schemes, and the net result of this refactoring would
be the replacement of comint-redirect (which wasn't able to match the
whole EOT token if it didn't arrive all at once) by transaction queues
(which also makes geiser-connection's implementation cleaner).
But using an inferior scheme has a dog-food value, and allows external
processes to connect to the scheme being used by Geiser without
further ado, which could be useful for debugging (although this is a
lame excuse: nothing prevents you from starting a REPL server from
emacs if you want). We'll see.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
comes with a pony too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
