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

Previous Next

Full log

View this message in rfc822 format

From: "Jose A. Ortega Ruiz" <jao <at> gnu.org>
To: Neil Jerram <neil <at> ossau.homelinux.net>
Cc: Mark H Weaver <mhw <at> netris.org>, geiser-users <at> nongnu.org, 33403 <at> debbugs.gnu.org
Subject: bug#33403: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
Date: Fri, 16 Nov 2018 22:40:13 +0000

On Fri, Nov 16 2018, Neil Jerram wrote:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> This is a documented limitation in Linux's terminal handling when in
>> canonical mode.  See the termios(3) man page, which includes this text:
>>
>>    Canonical and noncanonical mode
>>        
>>        The setting of the ICANON canon flag in c_lflag determines
>>        whether the terminal is operating in canonical mode (ICANON set)
>>        or noncanonical mode (ICANON unset).  By default, ICANON is set.
> [...]
>>        * The maximum line length is 4096 chars (including the
>>          terminating newline character); lines longer than 4096 chars
>>          are truncated.  After 4095 characters, input processing (e.g.,
>>          ISIG and ECHO* processing) continues, but any input data after
>>          4095 characters up to (but not including) any terminating
>>          newline is discarded.  This ensures that the terminal can
>>          always receive more input until at least one line can be read.
>>
>> Note that last item above.
>
> Awesome; thank you Mark.
>
> So possibly this limit can be removed, in my Org/Geiser context, by
> evaluating (system* "stty" "-icanon") when initializing the Geiser-Guile
> connection.  I'll try that.  Will the terminal that that 'stty' sees be
> the same as Guile's stdin?
>
> Jao, if that works, I wonder if it should be the default for Geiser?  It
> appears to me that Geiser shouldn't ever need the features of canonical
> mode.  Is that right?

I don't really know offhand.  Geiser simply uses comint-mode to talk to
Guile, and that in turn must be using Emacs' ability to spawn a process
and redirect its stdout and stderr, so I am not sure where the stty
kernel side enters the game, and how exactly shuold that call to system*
be performed to make sure it only affects the guile-emacs
communications.

Geiser has a mode of operation whereby it connects to a running Guile
REPL server instead of spawning its own process.  In that mode, instead
of a stdout/err redirection what is used is a TCP/IP connection, that
won't have any of this limitations.  So a cleaner solution would be to
make geiser always use a REPL server for Guile, but that requires some
non-trivial work on my side.  Another option would be for the org mode
package to setup a guile server and then use connect-to-guile (instead
of run-guile), but i don't know how difficult that would be.

Finally, a shabby workaround would be generating multiple lines instead
of a big one :)  That's of course not a real solution, but maybe can
work as a stopgap.

> Anyway, I'll see first if the stty call is effective.

Excellent.  Thanks for taking the time and please keep us posted!

Cheers,
jao
-- 
"I don't want to achieve immortality through my work... I want to
achieve it through not dying" -- Woody Allen

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.