bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation

[Neil Jerram]

Hi, this is a report for Guile 2.2:

    address@hidden:~$ guile --version
    guile (GNU Guile) 2.2.3
    Packaged by Debian (2.2.3-deb+1-3ubuntu0.1)

I'm seeing something that looks like a line or sexp length limit when
reading from a terminal.  Sample inputs are in the attached file.

prob3.scm
Description: Text document

If I run guile in a terminal (GNOME Terminal 3.28.2), select the first
block from the file, and use my middle mouse button to paste it into the
guile prompt, I get the expected answer:

    $4 = 139
    scheme@(guile-user)> 

If I do the same with the second block, I get no response, and it
appears that Guile has hung in some way.  I have to type C-c to get a
new prompt:

    ^C^CWhile reading expression:
    User interrupt
    scheme@(guile-user)> 

The max line length for the first block is 4087.  For the second it's
4113.  Could there be a 4K buffer or limit involved somewhere?

I tried to simulate this in code as follows:

    (define (make-sexp n)
      (define (accum s n)
        (if (zero? n)
        s
        (accum (string-append s " (\"AAAAAAAAAAAAAAA\" \"aaa\")") (- n 1))))
      (string-append "(" (accum "" n) ")"))

    (length (with-input-from-string (make-sexp 5000) read))

But that is fine, so it appears there isn't a problem in the reader
itself.

Any ideas?  This is a problem for me in practice when evaluating Guile
code (via Geiser) from an Org file, with data coming from large Org
tables (as initially reported here:
https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00177.html).

Many thanks,
    Neil




Neil Jerram <address@hidden> writes:

> "Jose A. Ortega Ruiz" <address@hidden> writes:
>
>> I cannot see what it is, but there's something in that expression that
>> makes scheme readers hang.  I just pasted it in a vanilla guile repl
>> (started with run-scheme, no geiser involved), and it never gets
>> evaluated.  The same thing happens with a MIT scheme vanilla repl.  And
>> the same thing happens if i try to evaluate it in a guile repl in a
>> terminal, so it's not even emacs fault.  Maybe there's some non-ascii
>> char in there?  In fact, the scheme readers hang somewhere in the middle
>> of the let, because i can remove characters from the end and they never
>> discover that the expression is unbalanced....
>
> Thanks Jao; the plot thickens...
>
> The line length is quite close to 4K; I wonder if that could be
> relevant?
>
> Anyway, I will also check for odd characters...
>
>     Neil