From 58484400fd3dde3ec28057159ce55f22fcb6c919 Mon Sep 17 00:00:00 2001 From: Jose Antonio Ortega Ruiz Date: Thu, 10 Sep 2015 04:22:10 +0200 Subject: Speeding up debugger check (addresses #64) 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. --- geiser/evaluation.scm | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/geiser/evaluation.scm b/geiser/evaluation.scm index ea4071d..4c87532 100644 --- a/geiser/evaluation.scm +++ b/geiser/evaluation.scm @@ -49,11 +49,6 @@ (ge:set-warnings 'none) -(define (stringify obj) - (object->string obj - (lambda (o . ps) - (pretty-print o (car ps) #:max-expr-width 100)))) - (define (call-with-result thunk) (letrec* ((result #f) (output @@ -62,7 +57,8 @@ (with-fluids ((*current-warning-port* (current-output-port)) (*current-warning-prefix* "")) (with-error-to-port (current-output-port) - (lambda () (set! result (map stringify (thunk)))))))))) + (lambda () (set! result + (map object->string (thunk)))))))))) (write `((result ,@result) (output . ,output))) (newline))) -- cgit v1.2.3