| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Those two procedures are gone in these 2.2 times, and things like
autodoc and xref were broken as a result. With Andy's help,
apparently good enough approximations of their functionality are now
in place: let's see how they go.
|
|
It now _slows_ performance rather than improves it. Removing it speeds
up the issue described in jaor/geiser#174
|
|
Removed all of the symbol-interning code, and in the process greatly
reduced the amount of CPU time.
Should resolve jaor/geiser#174
|
|
Chicken Scheme's apropos egg changed the identifiers in the return value
of the `apropos-information-list` from `module#name` to `(module
. name)`. This commit adds support for the new identifiers.
|
|
|
|
when eval (make-violation)
it shall return: \#<condition &violation>
but previous impletement will treat it as an ERROR.
|
|
|
|
- Capture exceptions of ChezScheme
- handles multi-value return
|
|
Should fix #188, and i'm not generating a new version for this unless
some distribution maintainer is asking.
|
|
- Also cleaned up the namespace a little.
|
|
This was causing significant typing delay with little to no benefit.
Disabled until a better solution can be found.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because Chicken allows symbols to be imported with prefixes, and because
'apropos' does not provide any utility to match with the loaded
prefixes, it is difficult to acquire information about prefixed symbols.
This solution hacks around the issue by providing naive
fuzzy-matching. If no match for a symbol can be found then the first
character is dropped and matching is attempted again; the process is
repeated until matches are found or the entire symbol is consumed.
Also removes the (now redundant and slow) geiser-chicken-prefix-delimiters.
|
|
No longer rely on Apropos for matching. Apropos would perform a slow substring or regex search at every call; as well as rebuilding the entire list of available symbols. Now the list of symb
|
|
|
|
Using cond-expand to provide support for the new world of guile 2.2
|
|
Exposes geiser-load-paths, makes add-to-load-path and find-file
'unsafe'. Those needn't be memoized and would be strange if they are.
This should finish fixing jaor/geiser#114
|
|
|
|
That was annoying.
|
|
|
|
If one were to re-evaluate a buffer with a module in it there would be
problems because it would appear as a nested request.
Solution:
- Check if a module definition is a fore-most request, and if so,
evaluate at top level
|
|
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
|
|
It doesn't make sense to memoize the following:
geiser-start-server
geiser-macroexpand
|
|
Removed the unnecessary csi reference
Added a flag to force build an so
|
|
|
|
Clears memo when anything other than a safe geiser call is made.
Removes the last calls to regex within the thing
|
|
This seems to improve speed; in a large environment I witnessed a
regular 100ms increase in speed for autodoc.
|
|
Improves speed by an order of magnitude.
|
|
|
|
|
|
Crunch is a subset of R5RS that the crunch egg can heavily optimize via
c++ compilation. This change allows geiser to report to chicken
programmers whether the function is found within that subset, easing
development.
Details on the crunch egg can be found at:
http://wiki.call-cc.org/eggref/4/crunch
|
|
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.
|
|
Should fix issue #85
|
|
We use the same trick as chicken for guile, and pretty-print the
evaluation results before writing them. The trick wasn't working at all
until i specified a value for the undocumented keyword parameter
`#:max-expr-width`, which makes me think i might be missing something.
|
