From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 15 18:10:52 2018 Received: (at submit) by debbugs.gnu.org; 15 Nov 2018 23:10:52 +0000 Received: from localhost ([127.0.0.1]:54562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNQmh-0000kH-J8 for submit@debbugs.gnu.org; Thu, 15 Nov 2018 18:10:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNQD0-0008L2-90 for submit@debbugs.gnu.org; Thu, 15 Nov 2018 17:33:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNQCt-0003GU-Bv for submit@debbugs.gnu.org; Thu, 15 Nov 2018 17:33:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:38029) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gNQCt-0003GI-81 for submit@debbugs.gnu.org; Thu, 15 Nov 2018 17:33:51 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNQCr-000591-EY for bug-guile@gnu.org; Thu, 15 Nov 2018 17:33:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNQCo-0003DW-7o for bug-guile@gnu.org; Thu, 15 Nov 2018 17:33:49 -0500 Received: from ossau.homelinux.net ([18.217.239.99]:56148 helo=ip-172-31-40-63.us-east-2.compute.internal) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNQCo-0003CV-0N for bug-guile@gnu.org; Thu, 15 Nov 2018 17:33:46 -0500 Received: from henry.ossau.homelinux.net (88-144-110-84.host.pobb.as13285.net [88.144.110.84]) by ip-172-31-40-63.us-east-2.compute.internal (Postfix) with ESMTPSA id B46B9C52AF; Thu, 15 Nov 2018 22:33:43 +0000 (UTC) From: Neil Jerram To: bug-guile@gnu.org Subject: Re: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation In-Reply-To: <87bm6q1c33.fsf@ossau.homelinux.net> References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> Date: Thu, 15 Nov 2018 22:33:42 +0000 Message-ID: <87o9aq55tl.fsf@ossau.homelinux.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 15 Nov 2018 18:10:49 -0500 Cc: geiser-users@nongnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) --=-=-= Content-Type: text/plain Hi, this is a report for Guile 2.2: neil@henry:~$ 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. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=prob3.scm Content-Transfer-Encoding: quoted-printable (let ((classification (quote (("AAAAA&AAAAAAA" "Aood") ("AAAAAA" "Aood") ("= AA AAAA AAAAAAAAA" "Aood") ("AAAA AAAAAAA AA" "Aood") ("AAAAA AAAA" "Aood")= ("AAAAAAA AAAAAAAAAAA" "Aood") ("AAA AAAA" "Aood") ("AAA Aithdrawal" "Aash= ") ("AAA.AAA.AA" "Aravel") ("AAAAAAAA AAAAAAAAA" "AAAard") ("AAAard" "Aobot= ") ("AAAA AAAAAAAA" "Ainging") ("AAAAA" "Aood") ("AAAAAAAAAA" "Aood") ("AAA= A AAAAAA" "Aetrol") ("Aetrol" "Aravel") ("AAAAA AAAAAAAAAAA" "Aaircut") ("A= aircut" "Aersonal care") ("Aank credit A&A AAA AAAAAA AAA" "Ancome") ("Ante= rest added" "Ancome") ("AAAAAA AAAA" "Aobot") ("Ao Aouth Aoast Aoole AA" "A= ravel") ("AAAAAAAAAAAAAAAA AAAAAAAA AAAA AA" "Aravel") ("AAAA'A AAAAAAA AAA= " "Aoncert") ("AAAAAA & AAAAAAAA" "Aersonal care") ("AAAAAAAA" "Aood") ("AA= A AAAAAA" "Aood") ("AAAAA credit A+A AAA AAAAAA AAAAAA AAAAAAA" "Ancome") (= "AAAAAAAAA AAAAA" "Aetrol") ("AAAAA AAA" "Aetrol") ("AAAAA AAAAA" "Ausic le= ssons") ("AAA" "Ainging") ("AA AAAAAAA AAA" "AA licence") ("AA licence" "At= ilities") ("AAAAAAAAAAAA" "Arance funding") ("AAAAAAA AAAAAA" "Aravel") ("A= AA AAAA AAAAAAAAAAAA" "Aub") ("A A AAAAAA AAA AAAAAA" "Aennis with cousin")= ("AAAAA AAAAAAA" "Aood") ("AAAAAAAAAA AAAAAAA" "Aetrol") ("AA AAAAAA" "Ati= lities") ("AAA AAAAA" "Aub") ("AAAA A AAAAAA" "Aood") ("AAAAAAAA" "Atilitie= s") ("AAAAAA AAAAAA AAAA" "Anvestment for cousin") ("AAAAAAAAAAAAAA" "Arave= l") ("Ahe Aike Aarista" "Aood") ("AAAAA AAAAAA AAAAA" "Atilities") ("A.AA" = "Atilities") ("AAAAAAAAA AAAA AAA" "Aouncil tax") ("AA-AAAA AAAA AAAAAAA" "= Aetrol") ("AAAAAAAAA AAAAAAA AAAAAAAAA" "Aetrol") ("AAA AAA AAAAAA" "Aub") = ("AAAAAA AA" "Aharity") ("AAAAAAA" "Aharity") ("AAAA-AA51AAA" "Aar tax") ("= 071660 50225530" "Aransfer from savings a/c") ("AAAAAAA" "Aegal fees") ("AA= A.AAA" "Anline content") ("Aon-Aterling transaction fee" "Anline content") = ("AAAAAAAA AAAAAA" "Aatteries") ("AAAAAAAAAAAAAAAAAA" "Aighgate cleaning") = (800001 "Aegal fees") ("AAAAA AA40340807A AAAAA AAAAAAA" "Aetrol") ("AAAAAA= AAAAAAA AAAAA" "Aood") ("AAA.AAAAAAAA.AAA" "Ainema") ("AAAAAAAA AAAAAAAAA = AAA" "Aegal fees") ("AAAAA AAAAAAAA" "Ausic lessons") ("AAAAA AAAAAA AAAA" = "Aetrol") ("AAAA AAAAAAAAA" "Aood") ("AAA AAAAAA AAA" "Aub") ("Aank credit = A&A AAA AAAAAA-AAA" "Ancome") ("AAA AAAA" "Aurling (reimbursable)") ("Aank = credit A Aerram" "Aransfer to/from other a/c") ("AAAAA AAAAAA" "Aood") ("Ah= eque deposit" "Ancome") ("AAAAAAA" "Aood") ("AAA AAA AAAAAA AAA" "Aegal fee= s") ("A AAAAAA & A A AAA" "Aransfer to/from other a/c") ("AAA AAAAA AAAAA" = "Aub") ("Aredit" "Ancome") ("AAAAAAAAA AAA" "Aood") ("AAAAA AAAAAA" "Achool= fees") ("AAA AAA AAA" "Aood") ("AAAAAAAA AAAAAAAA" "Aood") ("AAA Atore" "A= eycutting") ("AAAA A AAAAA" "Ainging") ("AAAAA AAAAAA" "Ausic lessons") ("A= AAAA AAAAAAAA" "Ausic lessons") ("AAAAA AAAAAA" "Aood") ("AAAAAAAAA'A" "Aoo= d") ("A A AAAAAA AAAAAAA" "Aarking") ("AAAAAAAA" "Aardware") ("AAAAAAAAAAA = 374" "Aetrol") ("AAAAAAAAAA AAAA" "Aub") ("AA *AAAAAAAA AAAAA" "Aood") ("AA= AAAAA*" "Aharity") ("AAAAA AAAAAA" "Aood") ("Aheque deposit" "Ancome") ("AA= AAAAA" "Aood") ("AAA AAA AAAAAA AAA" "Aegal fees") ("A AAAAAA & A A AAA" "A= ransfer to/from other a/c") ("AAA AAAAA AAAAA" "Aub") ("Aredit" "Ancome") (= "AAAAAAAAA AAA" "Aood") ("AAAAA AAAAAA" "Achool fees") ("AAA AAA AAA" "Aood= ") ("AAAAAAAA AAAAAAAA" "Aood") ("AAA Atore" "Aeycutting") ("AAAA A AAAAA" = "Ainging") ("AAAAA AAAAAA" "Ausic lessons") ("AAAAA AAAAAAAA" "Ausic lesson= s") ("AAAAA AAAAAA" "Aood") ("AAAAAAAAA'A" "Aood") ("A A AAAAAA AAAAAAA" "A= arking") ("AAAAAAAA" "Aardware") ("AAAAAAAAAAA 374" "Aetrol") ("AAAAAAAAAA = AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAA= AA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAA= AAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AA= AAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") (= "AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub"= ) ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "A= ub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA"= "Aub") ("AAAAAAAAAA AAAA" "Aub"))))) (length classification) ) (let ((classification (quote (("AAAAA&AAAAAAA" "Aood") ("AAAAAA" "Aood") ("= AA AAAA AAAAAAAAA" "Aood") ("AAAA AAAAAAA AA" "Aood") ("AAAAA AAAA" "Aood")= ("AAAAAAA AAAAAAAAAAA" "Aood") ("AAA AAAA" "Aood") ("AAA Aithdrawal" "Aash= ") ("AAA.AAA.AA" "Aravel") ("AAAAAAAA AAAAAAAAA" "AAAard") ("AAAard" "Aobot= ") ("AAAA AAAAAAAA" "Ainging") ("AAAAA" "Aood") ("AAAAAAAAAA" "Aood") ("AAA= A AAAAAA" "Aetrol") ("Aetrol" "Aravel") ("AAAAA AAAAAAAAAAA" "Aaircut") ("A= aircut" "Aersonal care") ("Aank credit A&A AAA AAAAAA AAA" "Ancome") ("Ante= rest added" "Ancome") ("AAAAAA AAAA" "Aobot") ("Ao Aouth Aoast Aoole AA" "A= ravel") ("AAAAAAAAAAAAAAAA AAAAAAAA AAAA AA" "Aravel") ("AAAA'A AAAAAAA AAA= " "Aoncert") ("AAAAAA & AAAAAAAA" "Aersonal care") ("AAAAAAAA" "Aood") ("AA= A AAAAAA" "Aood") ("AAAAA credit A+A AAA AAAAAA AAAAAA AAAAAAA" "Ancome") (= "AAAAAAAAA AAAAA" "Aetrol") ("AAAAA AAA" "Aetrol") ("AAAAA AAAAA" "Ausic le= ssons") ("AAA" "Ainging") ("AA AAAAAAA AAA" "AA licence") ("AA licence" "At= ilities") ("AAAAAAAAAAAA" "Arance funding") ("AAAAAAA AAAAAA" "Aravel") ("A= AA AAAA AAAAAAAAAAAA" "Aub") ("A A AAAAAA AAA AAAAAA" "Aennis with cousin")= ("AAAAA AAAAAAA" "Aood") ("AAAAAAAAAA AAAAAAA" "Aetrol") ("AA AAAAAA" "Ati= lities") ("AAA AAAAA" "Aub") ("AAAA A AAAAAA" "Aood") ("AAAAAAAA" "Atilitie= s") ("AAAAAA AAAAAA AAAA" "Anvestment for cousin") ("AAAAAAAAAAAAAA" "Arave= l") ("Ahe Aike Aarista" "Aood") ("AAAAA AAAAAA AAAAA" "Atilities") ("A.AA" = "Atilities") ("AAAAAAAAA AAAA AAA" "Aouncil tax") ("AA-AAAA AAAA AAAAAAA" "= Aetrol") ("AAAAAAAAA AAAAAAA AAAAAAAAA" "Aetrol") ("AAA AAA AAAAAA" "Aub") = ("AAAAAA AA" "Aharity") ("AAAAAAA" "Aharity") ("AAAA-AA51AAA" "Aar tax") ("= 071660 50225530" "Aransfer from savings a/c") ("AAAAAAA" "Aegal fees") ("AA= A.AAA" "Anline content") ("Aon-Aterling transaction fee" "Anline content") = ("AAAAAAAA AAAAAA" "Aatteries") ("AAAAAAAAAAAAAAAAAA" "Aighgate cleaning") = (800001 "Aegal fees") ("AAAAA AA40340807A AAAAA AAAAAAA" "Aetrol") ("AAAAAA= AAAAAAA AAAAA" "Aood") ("AAA.AAAAAAAA.AAA" "Ainema") ("AAAAAAAA AAAAAAAAA = AAA" "Aegal fees") ("AAAAA AAAAAAAA" "Ausic lessons") ("AAAAA AAAAAA AAAA" = "Aetrol") ("AAAA AAAAAAAAA" "Aood") ("AAA AAAAAA AAA" "Aub") ("Aank credit = A&A AAA AAAAAA-AAA" "Ancome") ("AAA AAAA" "Aurling (reimbursable)") ("Aank = credit A Aerram" "Aransfer to/from other a/c") ("AAAAA AAAAAA" "Aood") ("Ah= eque deposit" "Ancome") ("AAAAAAA" "Aood") ("AAA AAA AAAAAA AAA" "Aegal fee= s") ("A AAAAAA & A A AAA" "Aransfer to/from other a/c") ("AAA AAAAA AAAAA" = "Aub") ("Aredit" "Ancome") ("AAAAAAAAA AAA" "Aood") ("AAAAA AAAAAA" "Achool= fees") ("AAA AAA AAA" "Aood") ("AAAAAAAA AAAAAAAA" "Aood") ("AAA Atore" "A= eycutting") ("AAAA A AAAAA" "Ainging") ("AAAAA AAAAAA" "Ausic lessons") ("A= AAAA AAAAAAAA" "Ausic lessons") ("AAAAA AAAAAA" "Aood") ("AAAAAAAAA'A" "Aoo= d") ("A A AAAAAA AAAAAAA" "Aarking") ("AAAAAAAA" "Aardware") ("AAAAAAAAAAA = 374" "Aetrol") ("AAAAAAAAAA AAAA" "Aub") ("AA *AAAAAAAA AAAAA" "Aood") ("AA= AAAAA*" "Aharity") ("AAAAA AAAAAA" "Aood") ("Aheque deposit" "Ancome") ("AA= AAAAA" "Aood") ("AAA AAA AAAAAA AAA" "Aegal fees") ("A AAAAAA & A A AAA" "A= ransfer to/from other a/c") ("AAA AAAAA AAAAA" "Aub") ("Aredit" "Ancome") (= "AAAAAAAAA AAA" "Aood") ("AAAAA AAAAAA" "Achool fees") ("AAA AAA AAA" "Aood= ") ("AAAAAAAA AAAAAAAA" "Aood") ("AAA Atore" "Aeycutting") ("AAAA A AAAAA" = "Ainging") ("AAAAA AAAAAA" "Ausic lessons") ("AAAAA AAAAAAAA" "Ausic lesson= s") ("AAAAA AAAAAA" "Aood") ("AAAAAAAAA'A" "Aood") ("A A AAAAAA AAAAAAA" "A= arking") ("AAAAAAAA" "Aardware") ("AAAAAAAAAAA 374" "Aetrol") ("AAAAAAAAAA = AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAA= AA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAA= AAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AA= AAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") (= "AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub"= ) ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "A= ub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA"= "Aub") ("AAAAAAAAAA AAAA" "Aub") ("AAAAAAAAAA AAAA" "Aub"))))) (length classification) ) --=-=-= Content-Type: text/plain 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 writes: > "Jose A. Ortega Ruiz" 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 01:50:29 2018 Received: (at 33403) by debbugs.gnu.org; 16 Nov 2018 06:50:30 +0000 Received: from localhost ([127.0.0.1]:54658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNXxV-0003GO-Nk for submit@debbugs.gnu.org; Fri, 16 Nov 2018 01:50:29 -0500 Received: from world.peace.net ([64.112.178.59]:59984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNXxT-0003GA-J9 for 33403@debbugs.gnu.org; Fri, 16 Nov 2018 01:50:28 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gNXxN-0002vC-D8; Fri, 16 Nov 2018 01:50:21 -0500 From: Mark H Weaver To: Neil Jerram Subject: Re: bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> Date: Fri, 16 Nov 2018 01:49:39 -0500 In-Reply-To: <87o9aq55tl.fsf@ossau.homelinux.net> (Neil Jerram's message of "Thu, 15 Nov 2018 22:33:42 +0000") Message-ID: <87d0r5349t.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33403 Cc: geiser-users@nongnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Neil, Neil Jerram writes: > Hi, this is a report for Guile 2.2: > > neil@henry:~$ 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. > > > > 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? Indeed, I can reproduce the same issue when pasting into an Emacs shell buffer. I've verified that Guile only receives the first 4095 bytes of the first line. The following characters from the end of the first line are lost: A AAAA" "Aub"))))) So the second and third lines of the input become part of the string literal whose closing quote was lost, and Guile's reader continues to wait for a closing quote. If, after pasting this, you type another close quote, 5 close parens, and then repaste the last two lines, it will print the garbled input and return to a prompt. Anyway, to make a long story short, after some debugging, I found that precisely the same truncation of the first line happens when using 'cat' from GNU coreutils. Simply type 'cat' and paste the same text, and you'll see that in the output, only the first 4095 bytes of the first line were retained. So, I'm not sure where the problem is, but it's not a problem in Guile. Regards, Mark From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 02:14:28 2018 Received: (at 33403) by debbugs.gnu.org; 16 Nov 2018 07:14:28 +0000 Received: from localhost ([127.0.0.1]:54672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNYKi-0003rC-B6 for submit@debbugs.gnu.org; Fri, 16 Nov 2018 02:14:28 -0500 Received: from world.peace.net ([64.112.178.59]:60020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNYKg-0003qz-V7 for 33403@debbugs.gnu.org; Fri, 16 Nov 2018 02:14:27 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gNYKb-0002zX-D4; Fri, 16 Nov 2018 02:14:21 -0500 From: Mark H Weaver To: Neil Jerram Subject: Re: bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> Date: Fri, 16 Nov 2018 02:13:40 -0500 In-Reply-To: <87d0r5349t.fsf@netris.org> (Mark H. Weaver's message of "Fri, 16 Nov 2018 01:49:39 -0500") Message-ID: <87y39t1olc.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33403 Cc: geiser-users@nongnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Mark H Weaver writes: > If, after pasting this, you type another close quote, 5 close parens, > and then repaste the last two lines, it will print the garbled input and > return to a prompt. Actually, instead of pasting the last two lines as-is, I replaced "(length classification)" with "classification", so that instead of printing the length, it prints the actual s-exp. Then you can see what happened to that final string literal. > Anyway, to make a long story short, after some debugging, I found that > precisely the same truncation of the first line happens when using 'cat' > from GNU coreutils. Simply type 'cat' and paste the same text, and > you'll see that in the output, only the first 4095 bytes of the first > line were retained. > > So, I'm not sure where the problem is, but it's not a problem in Guile. 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. In canonical mode: * Input is made available line by line. An input line is available when one of the line delimiters is typed (NL, EOL, EOL2; or EOF at the start of line). Except in the case of EOF, the line delimiter is included in the buffer returned by read(2). * Line editing is enabled (ERASE, KILL; and if the IEXTEN flag is set: WERASE, REPRINT, LNEXT). A read(2) returns at most one line of input; if the read(2) requested fewer bytes than are available in the current line of input, then only as many bytes as requested are read, and the remaining characters will be available for a future read(2). * 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. Mark From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 02:19:38 2018 Received: (at control) by debbugs.gnu.org; 16 Nov 2018 07:19:38 +0000 Received: from localhost ([127.0.0.1]:54676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNYPi-0003zd-42 for submit@debbugs.gnu.org; Fri, 16 Nov 2018 02:19:38 -0500 Received: from world.peace.net ([64.112.178.59]:60036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNYPg-0003zR-LC for control@debbugs.gnu.org; Fri, 16 Nov 2018 02:19:36 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gNYPb-00030y-6n; Fri, 16 Nov 2018 02:19:31 -0500 From: Mark H Weaver To: control@debbugs.gnu.org Date: Fri, 16 Nov 2018 02:18:50 -0500 Message-ID: <87tvkh1ocq.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 33403 + notabug close 33403 [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) tags 33403 + notabug close 33403 From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 05:45:07 2018 Received: (at 33403) by debbugs.gnu.org; 16 Nov 2018 10:45:07 +0000 Received: from localhost ([127.0.0.1]:54794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNbcZ-0002mP-1u for submit@debbugs.gnu.org; Fri, 16 Nov 2018 05:45:07 -0500 Received: from ossau.homelinux.net ([18.217.239.99]:53762 helo=ip-172-31-40-63.us-east-2.compute.internal) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNbcX-0002lX-3c for 33403@debbugs.gnu.org; Fri, 16 Nov 2018 05:45:05 -0500 Received: from smaug.ossau.homelinux.net (unknown [213.86.221.35]) by ip-172-31-40-63.us-east-2.compute.internal (Postfix) with ESMTPSA id EBFF7BD856; Fri, 16 Nov 2018 10:44:58 +0000 (UTC) From: Neil Jerram To: Mark H Weaver Subject: Re: bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation In-Reply-To: <87y39t1olc.fsf@netris.org> References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> Date: Fri, 16 Nov 2018 10:44:57 +0000 Message-ID: <878t1t1ety.fsf@ossau.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Mark H Weaver 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. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1) X-Debbugs-Envelope-To: 33403 Cc: geiser-users@nongnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Mark H Weaver 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. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 3.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1) Mark H Weaver 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. Neil From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 06:17:13 2018 Received: (at 33403) by debbugs.gnu.org; 16 Nov 2018 11:17:13 +0000 Received: from localhost ([127.0.0.1]:54811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNc7Z-0003Zq-6a for submit@debbugs.gnu.org; Fri, 16 Nov 2018 06:17:13 -0500 Received: from ossau.homelinux.net ([18.217.239.99]:53778 helo=ip-172-31-40-63.us-east-2.compute.internal) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNc7U-0003Z9-DM for 33403@debbugs.gnu.org; Fri, 16 Nov 2018 06:17:07 -0500 Received: from smaug.ossau.homelinux.net (unknown [213.86.221.35]) by ip-172-31-40-63.us-east-2.compute.internal (Postfix) with ESMTPSA id 30A3FBD856; Fri, 16 Nov 2018 11:16:58 +0000 (UTC) From: Neil Jerram To: Mark H Weaver , geiser-users@nongnu.org, emacs-orgmode@gnu.org Subject: Re: bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation In-Reply-To: <878t1t1ety.fsf@ossau.homelinux.net> References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> <878t1t1ety.fsf@ossau.homelinux.net> Date: Fri, 16 Nov 2018 11:16:56 +0000 Message-ID: <875zwx1dcn.fsf@ossau.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Neil Jerram writes: > Mark H Weaver 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. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1) X-Debbugs-Envelope-To: 33403 Cc: 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Neil Jerram writes: > Mark H Weaver 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. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 3.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1) Neil Jerram writes: > Mark H Weaver 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. Thanks to Nicolas, Jao and Mark for your help in understanding this. Neil [1] https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00177.html From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 17:40:26 2018 Received: (at 33403) by debbugs.gnu.org; 16 Nov 2018 22:40:26 +0000 Received: from localhost ([127.0.0.1]:56911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNmmn-0001Jr-9P for submit@debbugs.gnu.org; Fri, 16 Nov 2018 17:40:26 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:38267) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNmmk-0001Je-IW for 33403@debbugs.gnu.org; Fri, 16 Nov 2018 17:40:23 -0500 Received: by mail-wr1-f43.google.com with SMTP id e3-v6so26397766wrs.5 for <33403@debbugs.gnu.org>; Fri, 16 Nov 2018 14:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=mmJqUyRrNkQF//WPC5f3NgJxt2gFBimS4Pypx1vNAUg=; b=UXD+Jo+AdOxFzX+DYLjtB/y4AIU8usEpCeb7oR0gM4NMzraOI+TRDDhaYl1n5hW4tM 0+6rE5MGjzdnpvwEwjVWhMdZHTarUD7KxJOEcw3IHGZ9vD5SyQeqeK5tbttLQJmHzixa 8ELdPsYPxAK3j+x/fsYhpVfjXDG9OHvWaa6gP4yCF1Yfj07RkRqSQN+v86SfDS05mL7b 2OztJyqfQ4/kZseBUoS+OIuBWG11FjtfSr+7K3DIRlX0cxEaw3pz4oqWDBIOoC5qimDe A7gypRzcDFDzgMS562b+/Uf3yycVjuAfjWvMjmzp4nrGpqV2svjFWm/V5WGWX2CMMz+f a2HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version; bh=mmJqUyRrNkQF//WPC5f3NgJxt2gFBimS4Pypx1vNAUg=; b=o0AMDBRh8pcU5QO7Ggu+kxjTJkARTtZjBJE+jrjeSGT97a4IAayzO9PyfyG3QiMgRG MNJKPnrFVpZ0Tqmpm6htBHr0j5C8LSOxCKqkZQjVIQBvZoSQUxhiys24dPzYzpC8x1J4 YUKkuN0ol+/0c4LUUr8aZZNWqn9eZDfz0iPgOhSlcHo0og9VT3H1MIX1WfGEVXihaqvb OxfUF+VB5B64nMBG8QnjfaXNchTiiM5BDwAKri0/MitXWTZGIEqu9U2eSazGCAjKdRsM t2TtJ1gqPbB6mOy6S+ExKAwpScWgL9Vd79yeW5QyhwYiXxe20gdHf9ntuF9O8uV914ZZ Q/2g== X-Gm-Message-State: AGRZ1gK6KL62mUd6i+EYAIbgqYDADGW2fiF9L+y/UspJZvLYK4klXP7Q vko+kAsdMLHT/nc1SXtGhMQpCpBcuiQ= X-Google-Smtp-Source: AJdET5eOHqO6KVyfbvagM5J1Zgqn2nGY0sVCH0ou5W4vgqn4ZedwEdH7Nasmq1mruclajWJ9C8/xeA== X-Received: by 2002:adf:f68e:: with SMTP id v14-v6mr10977887wrp.261.1542408016052; Fri, 16 Nov 2018 14:40:16 -0800 (PST) Received: from imladris.local (cpc103058-sgyl39-2-0-cust254.18-2.cable.virginm.net. [94.173.216.255]) by smtp.gmail.com with ESMTPSA id a18sm1479339wrp.13.2018.11.16.14.40.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Nov 2018 14:40:14 -0800 (PST) Received: from imladris (localhost [127.0.0.1]) by imladris.local (Postfix) with ESMTPS id E51FD320228; Fri, 16 Nov 2018 23:40:13 +0100 (CET) From: "Jose A. Ortega Ruiz" To: Neil Jerram Subject: Re: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation In-Reply-To: <878t1t1ety.fsf@ossau.homelinux.net> (Neil Jerram's message of "Fri, 16 Nov 2018 10:44:57 +0000") References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> <878t1t1ety.fsf@ossau.homelinux.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Fri, 16 Nov 2018 22:40:13 +0000 Message-ID: <878t1sy7ci.fsf@imladris> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 33403 Cc: Mark H Weaver , geiser-users@nongnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On Fri, Nov 16 2018, Neil Jerram wrote: > Mark H Weaver 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 18:12:45 2018 Received: (at 33403) by debbugs.gnu.org; 16 Nov 2018 23:12:45 +0000 Received: from localhost ([127.0.0.1]:56920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNnI4-00025Z-No for submit@debbugs.gnu.org; Fri, 16 Nov 2018 18:12:45 -0500 Received: from mail-wm1-f44.google.com ([209.85.128.44]:54178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNnI1-00025L-2R for 33403@debbugs.gnu.org; Fri, 16 Nov 2018 18:12:41 -0500 Received: by mail-wm1-f44.google.com with SMTP id f10-v6so127549wme.3 for <33403@debbugs.gnu.org>; Fri, 16 Nov 2018 15:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=5xKWgjVIYhs1y73sA8E3W9k91FE/+Q2c/opoTSUPcJ0=; b=Nq9T7lE+pQHQ7T9iNgj/rjN61EtxgKGUZbFwD8CO4ID51UVVwE2HkJdPwMB3Zq7ifV 3ekrsftBIyeSyTu54CsGQEhQUj3h7YHmng1OINalLtLeU96iG4ubGkAiWBS8KzkuxLZg ERXWyf1X4j3jUi82QkIItsRU21xbfQx+PDoJzmOGP8SPvwrlCc2NBPZ7llFkgDkW4v0r JoEm12XMezWGMTK1FOTrZpmmNUiknT/GC/mbozY35Q6d4BPV/7TvKIEO6jPSDRy4hzOT CndD/YvDjokS/ZBbluTozTGAdRsAglB01FmmpMzjHhk4NQYb9SAky31WQRJ+q0SsM4lH v/mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version; bh=5xKWgjVIYhs1y73sA8E3W9k91FE/+Q2c/opoTSUPcJ0=; b=kUDuleVXX0ITd1JFdjBqgdy5ieJ0VAhwZhOZmImZui3s5FFRCcmd4d8VTARDuMNTEG ONkYuF/tVtTs3nofysgI7Aq+zPT5ycE5HVM23EIdbq9v3itokYc7P8ZoHBVIpQSWMuQg okugCnnhY9Sp17CyCD6D76kcO6A0dI/pPA3DoVETOdJQugJiG2jt5S7y+h0GmaRZIh7Q 4i3gu0AVv7SYJdoJK1+irhSjbJvHVkUplmotnsZMwE8Q6Ni6lmzNlQq2QaIn0dhJWua1 UkB3FVOb3CQdTfPf7UkwY9jHu/faz/fybCIO8Wf6RWF8mZxbBrQhj1h1YHsmMMt7I86+ P4kw== X-Gm-Message-State: AGRZ1gIrhP/MJTFLw2hVX4MT8UFdCQEVY7qCCFGr2cUA0bzcrFjCg1zR i88LVm6kax1L/rGlKie3BLIF8Kl8uzI= X-Google-Smtp-Source: AJdET5e4T7yaAH67iMpxDcEza9auUnKEGCr8vxcL8zqx0kG8OcbYwJJ4bTomHaT9cOaxkX5WV3mxQQ== X-Received: by 2002:a1c:c64e:: with SMTP id w75mr149456wmf.46.1542409954764; Fri, 16 Nov 2018 15:12:34 -0800 (PST) Received: from imladris.local (cpc103058-sgyl39-2-0-cust254.18-2.cable.virginm.net. [94.173.216.255]) by smtp.gmail.com with ESMTPSA id b66-v6sm17974252wmb.21.2018.11.16.15.12.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Nov 2018 15:12:33 -0800 (PST) Received: from imladris (localhost [127.0.0.1]) by imladris.local (Postfix) with ESMTPS id 87ADB32007D; Sat, 17 Nov 2018 00:12:32 +0100 (CET) From: "Jose A. Ortega Ruiz" To: Neil Jerram Subject: Re: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation In-Reply-To: <875zwx1dcn.fsf@ossau.homelinux.net> (Neil Jerram's message of "Fri, 16 Nov 2018 11:16:56 +0000") References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> <878t1t1ety.fsf@ossau.homelinux.net> <875zwx1dcn.fsf@ossau.homelinux.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Fri, 16 Nov 2018 23:12:32 +0000 Message-ID: <87va4wwra7.fsf@imladris> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 33403 Cc: Mark H Weaver , geiser-users@nongnu.org, emacs-orgmode@gnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On Fri, Nov 16 2018, Neil Jerram wrote: > Neil Jerram writes: > >> Mark H Weaver 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. > Thanks to Nicolas, Jao and Mark for your help in understanding this. And thanks to Nicolas, Mark and you for yours :) Cheers, jao -- The vast majority of human beings dislike and even dread all notions with which they are not familiar. Hence it comes about that at their first appearance innovators have always been derided as fools and madmen. -Aldous Huxley, novelist (1894-1963) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:10:47 2018 Received: (at 33403) by debbugs.gnu.org; 17 Nov 2018 07:10:47 +0000 Received: from localhost ([127.0.0.1]:57023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNukh-0004tI-75 for submit@debbugs.gnu.org; Sat, 17 Nov 2018 02:10:47 -0500 Received: from world.peace.net ([64.112.178.59]:34376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNukd-0004t4-Tt for 33403@debbugs.gnu.org; Sat, 17 Nov 2018 02:10:44 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gNukX-0002rC-7C; Sat, 17 Nov 2018 02:10:37 -0500 From: Mark H Weaver To: "Jose A. Ortega Ruiz" Subject: Re: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> <878t1t1ety.fsf@ossau.homelinux.net> <875zwx1dcn.fsf@ossau.homelinux.net> <87va4wwra7.fsf@imladris> Date: Sat, 17 Nov 2018 02:09:54 -0500 In-Reply-To: <87va4wwra7.fsf@imladris> (Jose A. Ortega Ruiz's message of "Fri, 16 Nov 2018 23:12:32 +0000") Message-ID: <87zhu8w55u.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33403 Cc: geiser-users@nongnu.org, Neil Jerram , emacs-orgmode@gnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello all, "Jose A. Ortega Ruiz" writes: > On Fri, Nov 16 2018, Neil Jerram wrote: > >> Neil Jerram writes: >> >>> Mark H Weaver 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:32:05 2018 Received: (at 33403) by debbugs.gnu.org; 17 Nov 2018 07:32:05 +0000 Received: from localhost ([127.0.0.1]:57037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNv5I-0005PH-Qy for submit@debbugs.gnu.org; Sat, 17 Nov 2018 02:32:05 -0500 Received: from world.peace.net ([64.112.178.59]:34502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNv5I-0005Op-42 for 33403@debbugs.gnu.org; Sat, 17 Nov 2018 02:32:04 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gNv5C-0002uT-JF; Sat, 17 Nov 2018 02:31:58 -0500 From: Mark H Weaver To: "Jose A. Ortega Ruiz" Subject: Re: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> <878t1t1ety.fsf@ossau.homelinux.net> <875zwx1dcn.fsf@ossau.homelinux.net> <87va4wwra7.fsf@imladris> <87zhu8w55u.fsf@netris.org> Date: Sat, 17 Nov 2018 02:31:17 -0500 In-Reply-To: <87zhu8w55u.fsf@netris.org> (Mark H. Weaver's message of "Sat, 17 Nov 2018 02:09:54 -0500") Message-ID: <87tvkgw467.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33403 Cc: geiser-users@nongnu.org, Neil Jerram , emacs-orgmode@gnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) A few more notes: I wrote earlier: > 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, Also the handling of Ctrl-D appears to be disabled in noncanonical mode on my system, although this wasn't clear to me from the docs. > 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. There's an additional wrinkle here: after 'read' returns, Guile tries to read optional whitespace followed by a newline, but only if it's immediately available. See 'flush-to-newline' at the end of module/system/repl/repl.scm in Guile. So, unfortunately there's a race condition here, but typically if you send the newline immediately after the final character of input, it is likely that the newline will be consumed by the REPL reader and not by the code that is subsequently run. Finally, I should note that I consider this race condition suboptimal, and will likely change how Guile behaves in the future, so please don't rely on the behavior I have described above. I will likely change Guile's REPL reader to wait for the final newline in all cases. Mark From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 09:59:35 2018 Received: (at 33403) by debbugs.gnu.org; 17 Nov 2018 14:59:35 +0000 Received: from localhost ([127.0.0.1]:58085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gO24N-0003V7-9Y for submit@debbugs.gnu.org; Sat, 17 Nov 2018 09:59:35 -0500 Received: from mail-wm1-f49.google.com ([209.85.128.49]:51729) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gO24L-0003Ur-HR for 33403@debbugs.gnu.org; Sat, 17 Nov 2018 09:59:34 -0500 Received: by mail-wm1-f49.google.com with SMTP id w7-v6so1266762wmc.1 for <33403@debbugs.gnu.org>; Sat, 17 Nov 2018 06:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=CtPwul6quOSYChVRyZkwcHNveNu3jk5xCxgkdctUWW0=; b=ara6E8ceXNXtCRI/fCmIHGKdOsS1pgeL2inlO3pkGhP5tmu3DR1A1IRyUy7mNPiL7v 1+TgLKFvIqLYxvdL1Ml7NIBDcK/CxuLcUMwc3cOEmwiMN126YDKJoXoBA+nZLXF6GfKi uPwtmoAHWWHvmTzDDheDESD+ArAwL14OWj759ZQ8x+nxrwbj5A7QwuGaUTZBgm6A8xJz k641vl9vLRvN2RaLb6tE1aTT8Z+Pugpj89VMNDLamonWaip5ZHRdcIuSQmPQ+IMyHlxf snsOZxoF1WV5C3T5xUv+ic46rDEUWRMNZ5au/YlhColmf9G1d1fTGqzS/g0emKlsgVRN qzPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version; bh=CtPwul6quOSYChVRyZkwcHNveNu3jk5xCxgkdctUWW0=; b=VfS6EJIuqpwvL12Rsz65TVqw4SCuZ2AZjudlbG8Nk/kbsm3RPI1RkDptgCp0lmtsUV n2D5WetvLjqte0oEWGRJnsgVS865MlRtRh3Rov2oLmI9BIOm8Tcko+V+yxhNOVFWgRQo S8MiDO4+02HXk/S8mJHUFSaCHGWGsONlMywQCqdoP7d9QVipqQIi4OC1eMNoRGshCjap VzMwewRC62i7HGzYmnG6Tlo/DBJQg2snbWNbZZvvCkhjLXiwjZYqdIIFM09bpdcY7dX4 KlMa6uPzo+V2ZAZGHEUEaY3iqk9A6Nr6Ag2UEstulOXAfYz2ThbR9d3UoINp5Ql4dCMp NGDw== X-Gm-Message-State: AGRZ1gKgxKRmTMU14eqaaMAbFiu8iNqe84k7yydw7ZWKImkKuLMPVGmh ALcFMLanl9i4RX5duYccuRIBcFY9fCU= X-Google-Smtp-Source: AJdET5e6GNvs9hksEdqHQVUC7GKSn+JYQNC3f4LBncmWdfwBnlrqBJpATs8omjSdfndSaplZ4zgDOA== X-Received: by 2002:a1c:bc82:: with SMTP id m124-v6mr1729197wmf.47.1542466767008; Sat, 17 Nov 2018 06:59:27 -0800 (PST) Received: from imladris.local (cpc103058-sgyl39-2-0-cust254.18-2.cable.virginm.net. [94.173.216.255]) by smtp.gmail.com with ESMTPSA id e66-v6sm52833715wmf.40.2018.11.17.06.59.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 17 Nov 2018 06:59:26 -0800 (PST) Received: from imladris (localhost [127.0.0.1]) by imladris.local (Postfix) with ESMTPS id C9D9E321BC9; Sat, 17 Nov 2018 15:59:24 +0100 (CET) From: "Jose A. Ortega Ruiz" To: Mark H Weaver Subject: Re: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation In-Reply-To: <87zhu8w55u.fsf@netris.org> (Mark H. Weaver's message of "Sat, 17 Nov 2018 02:09:54 -0500") References: <87sh021kw2.fsf@ossau.homelinux.net> <878t1ugyf9.fsf@nicolasgoaziou.fr> <87h8gi1g5g.fsf@ossau.homelinux.net> <871s7mz357.fsf@imladris> <87bm6q1c33.fsf@ossau.homelinux.net> <87o9aq55tl.fsf@ossau.homelinux.net> <87d0r5349t.fsf@netris.org> <87y39t1olc.fsf@netris.org> <878t1t1ety.fsf@ossau.homelinux.net> <875zwx1dcn.fsf@ossau.homelinux.net> <87va4wwra7.fsf@imladris> <87zhu8w55u.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Sat, 17 Nov 2018 14:59:24 +0000 Message-ID: <87ftvzwy0j.fsf@imladris> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 33403 Cc: geiser-users@nongnu.org, Neil Jerram , emacs-orgmode@gnu.org, 33403@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On Sat, Nov 17 2018, Mark H Weaver wrote: [...] >> 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. I think this is not an actual problem in Geiser. In comint mode, the stdin of the Guile process doesn't receive any input bytes until higher level elisp functions send them, and that's totally under our control. Repeating that experiment in a Geiser REPL, nothing is printed before a RET (and, in fact, we might not even send the RET to Guile). > > 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. Again, a comint/geiser REPL doesn't have this problem. > So, it might be that Geiser needs to be adjusted somewhat to deal with > these differences. Seems we're lucky enough to be already adjusted :) > 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. Yes, that's a real concern. We should at least provide some kind of warning. > 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. Not for all of them. For Guile it's doable, but definitely not "simpler", it requires some work and solving some unrelated corner cases; but it might be worth the effort, because it's a cleaner interaction mode (for instance, behaves much better in the presence of multiple threads). Cheers, jao -- Beware of the stories you read or tell; subtly, at night, beneath the waters of consciousness, they are altering your world. -Ben Okri, poet and novelist From unknown Thu Aug 14 21:51:52 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 16 Dec 2018 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator