X-Loop: help-debbugs@HIDDEN
Subject: bug#22095: FATAL: Cannot use remote repl server, possible dupe of bug#21993 ??
Resent-From: emacstheviking <objitsu@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sat, 05 Dec 2015 00:36:03 +0000
Resent-Message-ID: <handler.22095.B.144927575222782 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 22095
X-GNU-PR-Package: guile
X-GNU-PR-Keywords:
To: 22095 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-guile@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.144927575222782
(code B ref -1); Sat, 05 Dec 2015 00:36:03 +0000
Received: (at submit) by debbugs.gnu.org; 5 Dec 2015 00:35:52 +0000
Received: from localhost ([127.0.0.1]:39519 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1a50pJ-0005vL-JE
for submit <at> debbugs.gnu.org; Fri, 04 Dec 2015 19:35:50 -0500
Received: from eggs.gnu.org ([208.118.235.92]:54110)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <objitsu@HIDDEN>) id 1a50lS-0005pV-Hw
for submit <at> debbugs.gnu.org; Fri, 04 Dec 2015 19:32:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <objitsu@HIDDEN>) id 1a50lQ-0005r7-2Z
for submit <at> debbugs.gnu.org; Fri, 04 Dec 2015 19:31:50 -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,FREEMAIL_FROM,
HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:38724)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <objitsu@HIDDEN>) id 1a50lQ-0005r3-0Y
for submit <at> debbugs.gnu.org; Fri, 04 Dec 2015 19:31:48 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35874)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <objitsu@HIDDEN>) id 1a50lN-0007B1-Qq
for bug-guile@HIDDEN; Fri, 04 Dec 2015 19:31:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <objitsu@HIDDEN>) id 1a50lL-0005pd-UT
for bug-guile@HIDDEN; Fri, 04 Dec 2015 19:31:45 -0500
Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:35998)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <objitsu@HIDDEN>) id 1a50lL-0005pM-Ip
for bug-guile@HIDDEN; Fri, 04 Dec 2015 19:31:43 -0500
Received: by lbblt2 with SMTP id lt2so29793544lbb.3
for <bug-guile@HIDDEN>; Fri, 04 Dec 2015 16:31:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=8+y6bfNWWX5NTQiImAtHUPL5IrhdrO6r5octI9Pqeig=;
b=Y+LiUMaEIb6lumPdaYrLFysI5IgFy+AaYNN1sdUt8EwBRGfZCShvkipFKNLDG1N21E
1P6rAJAr/TGvKTECYv2w42hSOo9dvCqL/8Atfa6daRhfwL12rg5HNOH5PfaMVA7si8jg
pEhF9KocAK8NCagyVY6u0+CRmYl92j0t1YPFC9qdFutdjyY36oK3jqQEMnEqu9dXdR6u
qvXPAvXMae3bZTDERTTTpAJvAa3r9qg2zAPkpHyjQs3SPQipCBdNfPLqFVzNE1LnmVol
4FpcJ20paJopytov2MMHk5mYlAawv6XUa39WM49rSE92CfaB2zeMIFaMlsnofxtQSgrq
U6zA==
X-Received: by 10.112.205.10 with SMTP id lc10mr8976763lbc.31.1449275502334;
Fri, 04 Dec 2015 16:31:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.82.208 with HTTP; Fri, 4 Dec 2015 16:31:02 -0800 (PST)
From: emacstheviking <objitsu@HIDDEN>
Date: Sat, 5 Dec 2015 00:31:02 +0000
Message-ID: <CAEiEuUKEsGCshr+TmUiiW5e7iRNunKxV-eB4AuH8JKsY56DXOg@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c3c0287f981805261bbf96
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: -4.0 (----)
X-Mailman-Approved-At: Fri, 04 Dec 2015 19:35:47 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)
--001a11c3c0287f981805261bbf96
Content-Type: text/plain; charset=UTF-8
Hi,
This bug is possibly the same as:
http://lists.gnu.org/archive/html/bug-guile/2015-11/msg00030.html
I am using OS X as well, the same as the above report mentions, 10.11.1.
I can only offer some additional information to the above report... it's a
blocker for me.
I have tried using both telnet and netcat with both TCP/IP and Unix domain
sockets and the problem persists whichever is used. It happens both when
--listen is used or if explicitly starred from the REPL using the server
module functions.
*Strangely I can still launch a REPL from emacs with "M-x run-geiser"* and
specify "guile" as the scheme.
I am assuming the geiser code uses "com-int" to do the dirty work at the
bottom so it's interesting that it works but the REPL server per se doesn't
work. I don't yet know why that should be the case.
I enclose my trace of an attempt at using the default unix domains socket
"/tmp/guile-socket" as stated in the source code.
I am a seasoned C developer (30 years) but my socket knowledge is not that
hot these days nor is my Scheme, something I decided to come back to and
right now it feels terrible because of this! Bummer.
If I can get a reliable build of guile from the sources I will attempt to
put in some logging and tracing and actually see what the problem might be
on OSX. There is probably some subtle socket default difference between it
and Ubuntu; "bug#21993: REPL Servers broken on OSX" states the problem
does not exist on that distro.
In the file: module/system/repl/server.scm at line 127:
;; Put the socket into non-blocking mode.
(fcntl server-socket F_SETFL
(logior O_NONBLOCK
(fcntl server-socket F_GETFL)))
and I then refer you to this page:
http://stackoverflow.com/questions/14370489/what-can-cause-a-resource-temporarily-unavailable-on-sock-send-command
of which the essence is, from the send() man page:
That's because you're using a non-blocking socket and the output buffer is
full.
When the message does not fit into the send buffer of the socket,
send() normally blocks, unless the socket has been placed in non-block-
ing I/O mode. In non-blocking mode it would return EAGAIN in this
case.
The blowout seems to happen immediately the socket connects, that makes me
think that the send buffer should be initially empty to the new client
connection so I can only imagine that either something filled it really
quick or there is some kind of edge case with socket options being managed
slightly differently across platform stacks. Just a wild guess.
Also worth a mention is this part of the trace, which may not mean anything
but to me at least it is also noteworthy:
scheme@(guile-user) [1]> Backtrace:
In ice-9/boot-9.scm:
157: 13 [catch #t #<catch-closure 109170c40> ...]
In unknown file:
?: 12 [apply-smob/1 #<catch-closure 109170c40>]
What if there is some memory corruption with the SMOB on OSX which then
fails and manifests as a socket failure??? That's pure speculation and
without looking harder and deeper I really couldn't say. Gut feeling: It's
just the spawned session bleeding out as the ice-9 stuff is the first thing
loaded or something?!
Many thanks I love Guile by the way, having used Gambit and Chicken in the
past I decided to use GNU tools for my SDL2 application, I wanted to REPL
in and hack the code while it was running... I will but this is in the way!
All the very best,
Hope it helps!
Sean Charles.
-- stack trace --
scheme@(guile-user)> (make-unix-domain-server-socket )
;;; <stdin>:1:0: warning: possibly unbound variable
`make-unix-domain-server-socket'
<unnamed port>:1:0: In procedure #<procedure 10930e0c0 at <current
input>:1:0 ()>:
<unnamed port>:1:0: In procedure module-lookup: Unbound variable:
make-unix-domain-server-socket
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> (use-modules (system repl server))
scheme@(guile-user) [1]> (make-unix-domain-server-socket )
$1 = #<input-output: socket 9>
scheme@(guile-user) [1]> (spawn-server $1)
$2 = #<thread 123145304985600 (10915ca00)>
scheme@(guile-user) [1]> Backtrace:
In ice-9/boot-9.scm:
157: 13 [catch #t #<catch-closure 109170c40> ...]
In unknown file:
?: 12 [apply-smob/1 #<catch-closure 109170c40>]
In ice-9/boot-9.scm:
157: 11 [catch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10
()> ...]
In unknown file:
?: 10 [with-continuation-barrier #<procedure 109170540 at
system/repl/server.scm:158:3 ()>]
In ice-9/boot-9.scm:
157: 9 [catch #t #<catch-closure 109170500> ...]
In unknown file:
?: 8 [apply-smob/1 #<catch-closure 109170500>]
In system/repl/server.scm:
164: 7 [#<procedure 109170540 at system/repl/server.scm:158:3 ()>]
In system/repl/repl.scm:
142: 6 [start-repl* scheme #f #<procedure prompting-meta-read (repl)>]
168: 5 [run-repl* # #<procedure prompting-meta-read (repl)>]
123: 4 [#<procedure 108da0520 at system/repl/repl.scm:118:4 (key . args)>
system-error ...]
In ice-9/format.scm:
1593: 3 [format #<input-output: socket 16> "While reading expression:\n"]
766: 2 [format:format-work "While reading expression:\n" ()]
81: 1 [anychar-dispatch]
In unknown file:
?: 0 [write-char #\i #<input-output: socket 16>]
ERROR: In procedure write-char:
ERROR: In procedure fport_write: Broken pipe
Backtrace:
In ice-9/boot-9.scm:
157: 2 [catch #t #<catch-closure 109170c40> ...]
In unknown file:
?: 1 [apply-smob/1 #<catch-closure 109170c40>]
In ice-9/boot-9.scm:
157: 0 [catch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10
()> ...]
ice-9/boot-9.scm:157:17: In procedure catch:
ice-9/boot-9.scm:157:17: In procedure fport_write: Broken pipe
--001a11c3c0287f981805261bbf96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>This bug is possibly the same as: <=
a href=3D"http://lists.gnu.org/archive/html/bug-guile/2015-11/msg00030.html=
">http://lists.gnu.org/archive/html/bug-guile/2015-11/msg00030.html</a></di=
v><div><br></div><div>I am using OS X as well, the same as the above report=
mentions, 10.11.1.</div><div>I can only offer some additional information =
to the above report... it's a blocker for =C2=A0me.</div><div><br></div=
><div>I have tried using both telnet and netcat with both TCP/IP and Unix d=
omain sockets and the problem persists whichever is used. It happens both w=
hen --listen is used or if explicitly starred from the REPL using the serve=
r module functions.</div><div><br></div><div><b>Strangely I can still launc=
h a REPL from emacs with "M-x run-geiser"</b> and specify "g=
uile" as the scheme.</div><div><br></div><div>I am assuming the geiser=
code uses "com-int" to do the dirty work at the bottom so it'=
;s interesting that it works but the REPL server per se doesn't work. I=
don't yet know why that should be the case.</div><div><br></div><div>I=
enclose my trace of an attempt at using the default unix domains socket &q=
uot;/tmp/guile-socket" as stated in the source code.</div><div><br></d=
iv><div>I am a seasoned C developer (30 years) but my socket knowledge is n=
ot that hot these days nor is my Scheme, something I decided to come back t=
o and right now it feels terrible because of this! Bummer.<br></div><div><b=
r></div><div>If I can get a reliable build of guile from the sources I will=
attempt to put in some logging and tracing and actually see what the probl=
em might be on OSX. There is probably some subtle socket default difference=
between it and Ubuntu; =C2=A0 "bug#21993: REPL Servers broken on OSX&=
quot; states the problem does not exist on that distro.</div><div><br></div=
><div>In the file: module/system/repl/server.scm at line 127:</div><div><fo=
nt face=3D"monospace, monospace"><br></font></div><div><div><font face=3D"m=
onospace, monospace">=C2=A0 ;; Put the socket into non-blocking mode.</font=
></div><div><font face=3D"monospace, monospace">=C2=A0 (fcntl server-socket=
F_SETFL</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0(logior O_NONBLOCK</font></div><div><font face=3D"mono=
space, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0(fcntl server-socket F_GETFL)))</font></div></div><div><br></div><div=
>and I then refer you to this page:</div><div><a href=3D"http://stackoverfl=
ow.com/questions/14370489/what-can-cause-a-resource-temporarily-unavailable=
-on-sock-send-command">http://stackoverflow.com/questions/14370489/what-can=
-cause-a-resource-temporarily-unavailable-on-sock-send-command</a><br></div=
><div><br></div><div>of which the essence is, from the send() man page:</di=
v><div><span style=3D"font-family:Arial,'Helvetica Neue',Helvetica,=
sans-serif;font-size:15px;line-height:19.5px"><br></span></div><div><span s=
tyle=3D"font-family:Arial,'Helvetica Neue',Helvetica,sans-serif;fon=
t-size:15px;line-height:19.5px">That's because you're using a=C2=A0=
</span><code style=3D"margin:0px;padding:1px 5px;border:0px;font-size:13px;=
font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation =
Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono',=
9;Courier New',monospace,sans-serif;white-space:pre-wrap;background-col=
or:rgb(238,238,238)">non-blocking</code><span style=3D"font-family:Arial,&#=
39;Helvetica Neue',Helvetica,sans-serif;font-size:15px;line-height:19.5=
px">=C2=A0socket and the output buffer is full.</span><br></div><div><br></=
div><div><pre class=3D"" style=3D"margin-top:0px;margin-bottom:1em;padding:=
5px;border:0px;font-size:13px;overflow:auto;width:auto;max-height:600px;fon=
t-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mon=
o','DejaVu Sans Mono','Bitstream Vera Sans Mono','C=
ourier New',monospace,sans-serif;color:rgb(57,51,24);word-wrap:normal;b=
ackground-color:rgb(238,238,238)"><code style=3D"margin:0px;padding:0px;bor=
der:0px;font-family:Consolas,Menlo,Monaco,'Lucida Console','Lib=
eration Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono&=
#39;,'Courier New',monospace,sans-serif;white-space:inherit"><span =
class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)"> </=
span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(=
43,145,175)">When</span><span class=3D"" style=3D"margin:0px;padding:0px;bo=
rder:0px;color:rgb(0,0,0)"> the message does not fit into the send buffe=
r of the socket</span><span class=3D"" style=3D"margin:0px;padding:0px;b=
order:0px;color:rgb(0,0,0)">,</span><span class=3D"" style=3D"margin:0px;pa=
dding:0px;border:0px;color:rgb(0,0,0)">
send</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;c=
olor:rgb(0,0,0)">()</span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px;color:rgb(0,0,0)"> normally blocks</span><span class=3D"" style=
=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)">,</span><span class=
=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)"> unless =
the socket has been placed in non</span><span class=3D"" style=3D"margin:0p=
x;padding:0px;border:0px;color:rgb(0,0,0)">-</span><span class=3D"" style=
=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)">block</span><span c=
lass=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)">-</s=
pan><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(0=
,0,0)">
ing I</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;=
color:rgb(0,0,0)">/</span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px;color:rgb(0,0,0)">O mode</span><span class=3D"" style=3D"margin:=
0px;padding:0px;border:0px;color:rgb(0,0,0)">.</span><span class=3D"" style=
=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)"> </span><span clas=
s=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(43,145,175)">In=
</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rg=
b(0,0,0)"> non</span><span class=3D"" style=3D"margin:0px;padding:0px;borde=
r:0px;color:rgb(0,0,0)">-</span><span class=3D"" style=3D"margin:0px;paddin=
g:0px;border:0px;color:rgb(0,0,0)">blocking mode it would </span><span cl=
ass=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(0,0,139)">ret=
urn</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color=
:rgb(0,0,0)"> EAGAIN in </span><span class=3D"" style=3D"margin:0px;padd=
ing:0px;border:0px;color:rgb(0,0,139)">this</span><span class=3D"" style=3D=
"margin:0px;padding:0px;border:0px;color:rgb(0,0,0)">
</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color=
:rgb(0,0,139)">case</span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px;color:rgb(0,0,0)">.</span><span class=3D"" style=3D"margin:0px;p=
adding:0px;border:0px;color:rgb(0,0,0)"> </span></code></pre></div><div>Th=
e blowout seems to happen immediately the socket connects, that makes me th=
ink that the send buffer should be initially empty to the new client connec=
tion so I can only imagine that either something filled it really quick or =
there is some kind of edge case with socket options being managed slightly =
differently across platform stacks. Just a wild guess.</div><div><br></div>=
<div>Also worth a mention is this part of the trace, which may not mean any=
thing but to me at least it is also noteworthy:</div><div><br></div><div><d=
iv><font face=3D"monospace, monospace">scheme@(guile-user) [1]> Backtrac=
e:</font></div><div><font face=3D"monospace, monospace">In ice-9/boot-9.scm=
:</font></div><div><font face=3D"monospace, monospace">=C2=A0157: 13 [catch=
#t #<catch-closure 109170c40> ...]</font></div><div><font face=3D"mo=
nospace, monospace">In unknown file:</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0?: 12 [apply-smob/1 #<catch-closure 109170c4=
0>]</font></div></div><div><br></div><div>What if there is some memory c=
orruption with the SMOB on OSX which then fails and manifests as a socket f=
ailure??? That's pure speculation and without looking harder and deeper=
I really couldn't say. Gut feeling: It's just the spawned session =
bleeding out as the ice-9 stuff is the first thing loaded or something?!</d=
iv><div><br></div><div><br></div><div><br></div><div>Many thanks I love Gui=
le by the way, having used Gambit and Chicken in the past I decided to use =
GNU tools for my SDL2 application, I wanted to REPL in and hack the code wh=
ile it was running... I will but this is in the way!</div><div><br></div><d=
iv>All the very best,</div><div>Hope it helps!</div><div><br></div><div>Sea=
n Charles.</div><div><br></div><div>-- stack trace --</div><div><br></div><=
div><div>scheme@(guile-user)> (make-unix-domain-server-socket )</div><di=
v>;;; <stdin>:1:0: warning: possibly unbound variable `make-unix-doma=
in-server-socket'</div><div><unnamed port>:1:0: In procedure #<=
;procedure 10930e0c0 at <current input>:1:0 ()>:</div><div><unn=
amed port>:1:0: In procedure module-lookup: Unbound variable: make-unix-=
domain-server-socket</div><div><br></div><div>Entering a new prompt.=C2=A0 =
Type `,bt' for a backtrace or `,q' to continue.</div><div>scheme@(g=
uile-user) [1]> (use-modules (system repl server))</div><div>scheme@(gui=
le-user) [1]> (make-unix-domain-server-socket )</div><div>$1 =3D #<in=
put-output: socket 9></div><div>scheme@(guile-user) [1]> (spawn-serve=
r $1)</div><div>$2 =3D #<thread 123145304985600 (10915ca00)></div><di=
v>scheme@(guile-user) [1]> Backtrace:</div><div>In ice-9/boot-9.scm:</di=
v><div>=C2=A0157: 13 [catch #t #<catch-closure 109170c40> ...]</div><=
div>In unknown file:</div><div>=C2=A0 =C2=A0?: 12 [apply-smob/1 #<catch-=
closure 109170c40>]</div><div>In ice-9/boot-9.scm:</div><div>=C2=A0157: =
11 [catch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10 ()&g=
t; ...]</div><div>In unknown file:</div><div>=C2=A0 =C2=A0?: 10 [with-conti=
nuation-barrier #<procedure 109170540 at system/repl/server.scm:158:3 ()=
>]</div><div>In ice-9/boot-9.scm:</div><div>=C2=A0157: 9 [catch #t #<=
catch-closure 109170500> ...]</div><div>In unknown file:</div><div>=C2=
=A0 =C2=A0?: 8 [apply-smob/1 #<catch-closure 109170500>]</div><div>In=
system/repl/server.scm:</div><div>=C2=A0164: 7 [#<procedure 109170540 a=
t system/repl/server.scm:158:3 ()>]</div><div>In system/repl/repl.scm:</=
div><div>=C2=A0142: 6 [start-repl* scheme #f #<procedure prompting-meta-=
read (repl)>]</div><div>=C2=A0168: 5 [run-repl* # #<procedure prompti=
ng-meta-read (repl)>]</div><div>=C2=A0123: 4 [#<procedure 108da0520 a=
t system/repl/repl.scm:118:4 (key . args)> system-error ...]</div><div>I=
n ice-9/format.scm:</div><div>1593: 3 [format #<input-output: socket 16&=
gt; "While reading expression:\n"]</div><div>=C2=A0766: 2 [format=
:format-work "While reading expression:\n" ()]</div><div>=C2=A0 8=
1: 1 [anychar-dispatch]</div><div>In unknown file:</div><div>=C2=A0 =C2=A0?=
: 0 [write-char #\i #<input-output: socket 16>]</div><div><br></div><=
div>ERROR: In procedure write-char:</div><div>ERROR: In procedure fport_wri=
te: Broken pipe</div><div>Backtrace:</div><div>In ice-9/boot-9.scm:</div><d=
iv>=C2=A0157: 2 [catch #t #<catch-closure 109170c40> ...]</div><div>I=
n unknown file:</div><div>=C2=A0 =C2=A0?: 1 [apply-smob/1 #<catch-closur=
e 109170c40>]</div><div>In ice-9/boot-9.scm:</div><div>=C2=A0157: 0 [cat=
ch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10 ()> ...]=
</div><div><br></div><div>ice-9/boot-9.scm:157:17: In procedure catch:</div=
><div>ice-9/boot-9.scm:157:17: In procedure fport_write: Broken pipe</div><=
/div><div><br></div><div><br></div></div>
--001a11c3c0287f981805261bbf96--
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: emacstheviking <objitsu@HIDDEN> Subject: bug#22095: Acknowledgement (FATAL: Cannot use remote repl server, possible dupe of bug#21993 ??) Message-ID: <handler.22095.B.144927575222782.ack <at> debbugs.gnu.org> References: <CAEiEuUKEsGCshr+TmUiiW5e7iRNunKxV-eB4AuH8JKsY56DXOg@HIDDEN> X-Gnu-PR-Message: ack 22095 X-Gnu-PR-Package: guile Reply-To: 22095 <at> debbugs.gnu.org Date: Sat, 05 Dec 2015 00:36:05 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-guile@HIDDEN If you wish to submit further information on this problem, please send it to 22095 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 22095: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D22095 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.