From: Mark H Weaver <mhw-StlzRsPvAncdnm+yROfE0A@public.gmane.org>
To: "Jose A. Ortega Ruiz" <jao-mXXj517/zsQ@public.gmane.org>
Cc: geiser-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org,
emacs-orgmode-mXXj517/zsQ@public.gmane.org,
33403-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
Subject: Re: bug#33403: Data length limit in Guile/Geiser/Scheme evaluation
Date: Sat, 17 Nov 2018 02:09:54 -0500 [thread overview]
Message-ID: <87zhu8w55u.fsf@netris.org> (raw)
In-Reply-To: <87va4wwra7.fsf@imladris> (Jose A. Ortega Ruiz's message of "Fri, 16 Nov 2018 23:12:32 +0000")
Hello all,
"Jose A. Ortega Ruiz" <jao-mXXj517/zsQ@public.gmane.org> writes:
> On Fri, Nov 16 2018, Neil Jerram wrote:
>
>> Neil Jerram <neil-mq78CtbEgnGjF4gvJNWmbtHuzzzSOjJt@public.gmane.org> writes:
>>
>>> Mark H Weaver <mhw-StlzRsPvAncdnm+yROfE0A@public.gmane.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?
>>>
>>> Anyway, I'll see first if the stty call is effective.
>>
>> Yes, with this in my ~/.guile-geiser -
>>
>> (system* "stty" "-icanon")
>>
>> - I can do evaluations past the 4K line length limit, and the Org-driven
>> problem that I first reported [1] has disappeared.
>
> Ah, system* is a scheme call! So yeah, maybe we could add that call to
> Geiser's guile initialization... i don't really see how that would cause
> any problem elsewhere.
I think something like this should be done, not only in the Guile
initialization, but ideally in the generic Geiser code that connects to
inferior processes via pseudo-tty. After the pseudo-tty is allocated
but before launching the inferior Scheme process, something like "stty
--file=/dev/pts/N -icanon" should be run.
However, before doing this, some warnings are in order:
When in noncanonical mode, the normal processing of ERASE (usually DEL
or Ctrl-H) and KILL (usually Ctrl-U) characters are disabled, and input
characters are delivered to the subprocess immediately as they are
typed, rather than waiting for the newline as normally happens in
canonical mode.
At least in the case of the Guile REPL, one notable side effect of
running in noncanonical mode is that when a list is entered at the REPL,
the 'read' returns as soon as the final close parenthesis is entered.
Nothing after that is read, not even the usual newline. The final
newline is only read if the reader is not yet sure that it has finished
reading the token, e.g. if a number or symbol is entered. In those
cases, typically any delimiter may be typed to terminate the read,
e.g. space.
To see this, you can try running Guile from a traditional terminal
program (e.g. xterm or GNOME Terminal), and type:
(system* "stty" "-icanon")
and then:
(display "hello")
You will see that as soon as you type that close paren, "hello" is
immediately printed, followed by another REPL prompt, all on the same
line.
You might also try (use-modules (ice-9 rdelim)) and then:
(read-line)
and you'll see that the newline you type at the end of that line is read
by 'read-line', which then immediately returns the empty string. The
input that you wish for 'read-line' to see must be typed on the same
line, immediately after the close parenthesis.
So, it might be that Geiser needs to be adjusted somewhat to deal with
these differences.
Finally, you might consider the possibility that 'stty' might not be
available in PATH, or fails for some reason, and ideally this case
should be handled as well.
It might be simpler to always use REPL servers over a socket, than to
deal with these headaches, although I don't know if that will be an
option for the other Scheme implementations.
Regards,
Mark
next prev parent reply other threads:[~2018-11-17 7:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 14:21 Data length limit in Guile/Geiser/Scheme evaluation Neil Jerram
2018-11-15 14:26 ` Neil Jerram
2018-11-15 15:20 ` Nicolas Goaziou
2018-11-15 16:04 ` Neil Jerram
[not found] ` <87h8gi1g5g.fsf-mq78CtbEgnGjF4gvJNWmbtHuzzzSOjJt@public.gmane.org>
2018-11-15 17:01 ` Jose A. Ortega Ruiz
2018-11-15 17:32 ` [Geiser-users] " Neil Jerram
[not found] ` <87bm6q1c33.fsf-mq78CtbEgnGjF4gvJNWmbtHuzzzSOjJt@public.gmane.org>
2018-11-15 23:17 ` Jose A. Ortega Ruiz
[not found] ` <87o9aq55tl.fsf@ossau.homelinux.net>
[not found] ` <87d0r5349t.fsf@netris.org>
[not found] ` <87y39t1olc.fsf@netris.org>
[not found] ` <878t1t1ety.fsf@ossau.homelinux.net>
2018-11-16 11:16 ` bug#33403: [Geiser-users] " Neil Jerram
[not found] ` <875zwx1dcn.fsf-mq78CtbEgnGjF4gvJNWmbtHuzzzSOjJt@public.gmane.org>
2018-11-16 23:12 ` bug#33403: " Jose A. Ortega Ruiz
2018-11-17 7:09 ` Mark H Weaver [this message]
[not found] ` <87zhu8w55u.fsf-StlzRsPvAncdnm+yROfE0A@public.gmane.org>
2018-11-17 7:31 ` Mark H Weaver
2018-11-17 14:59 ` Jose A. Ortega Ruiz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zhu8w55u.fsf@netris.org \
--to=mhw-stlzrspvancdnm+yrofe0a@public.gmane.org \
--cc=33403-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
--cc=geiser-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
--cc=jao-mXXj517/zsQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).