From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: Guile bugs Date: Fri, 15 Sep 2017 09:56:54 +0200 Message-ID: <871sn875tl.fsf@gnu.org> References: <87lgtajpkc.fsf@web.de> <87h8y7ruuz.fsf_-_@gnu.org> <87y3pm7l6j.fsf@gnu.org> <87wp55elvs.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1505462248 7094 195.159.176.226 (15 Sep 2017 07:57:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 15 Sep 2017 07:57:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: Guile User To: Linas Vepstas Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Sep 15 09:57:21 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dslV0-0001Zg-RY for guile-user@m.gmane.org; Fri, 15 Sep 2017 09:57:18 +0200 Original-Received: from localhost ([::1]:51805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dslV8-0005HZ-46 for guile-user@m.gmane.org; Fri, 15 Sep 2017 03:57:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dslUi-0005Cs-7Y for guile-user@gnu.org; Fri, 15 Sep 2017 03:57:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dslUe-0006Vy-B4 for guile-user@gnu.org; Fri, 15 Sep 2017 03:57:00 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dslUe-0006Vu-7A; Fri, 15 Sep 2017 03:56:56 -0400 Original-Received: from [193.50.110.249] (port=37294 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dslUd-0006hw-O6; Fri, 15 Sep 2017 03:56:56 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 29 Fructidor an 225 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: (Linas Vepstas's message of "Thu, 14 Sep 2017 12:54:51 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:14154 Archived-At: Linas Vepstas skribis: > On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Court=C3=A8s wrot= e: > >> Hello, >> >> Linas Vepstas skribis: >> >> > The stuff coming over the network sockets are bytes, not s-exps. Since >> none >> > of the bytes are ever zero, they are effectively C/C++ strings, and are >> > handled as such. These C strings are sent to scm_eval_string() wrapped >> > by scm_c_catch(). >> >> I don=E2=80=99t know to what extent that is applicable to your software,= but my >> recommendation would be to treat that network socket as a Scheme port, >> pass it to =E2=80=98read=E2=80=99, and pass the result to =E2=80=98eval= =E2=80=99 (as opposed to reading >> the whole string from C++ and passing it to =E2=80=98scm_eval_string=E2= =80=99.) >> > > Why? What advantage does this offer? It avoids copies and conversions, which is big deal if you deal with very big strings. > Its not clear that guile eval is smart enough to manage a network socket = -- > if the user starts a long-running process with intermittent prints, will = it > send that to the socket? What if the user hits cntrl-C in the middle of = it > all? What if the code that came over the socket happened to throw an > exception? These are important considerations, but it=E2=80=99s not eval=E2=80=99s bus= iness IMO. Instead, I suggest building your own protocol around it, and having a way in that protocol to report both exceptions and normal returns. > I've had to deal with all of these issues in the past, and have a stable > code base; but if I had to start all over again, its not clear that these > issues have gone away. I mean, eval was designed to eval -- it was not > designed to support multi-threaded, concurrent network operations, right? Right. > To support my point: the default guile network REPL server is painfully > slow, and frequently crashes/hangs. It works well enough to do some demos > but is not stable enough for production use ... if its just read+eval, th= at > might explain why its unstable. I=E2=80=99ve never noticed slowness of the REPL server, nor crashes. That said, if you run a REPL server in a separate thread and mutate the global state of the program, you could possibly crash it=E2=80=94no wonders here. Likewise, the REPL server is meant to be used for debugging on localhost. If you talk to a REPL server over the network with high latency, it=E2=80=99s going to be slow, not surprisingly. So yes, I find the REPL server to be a really pleasant tool when debugging an application locally, but that=E2=80=99s all it is=E2=80=94it= =E2=80=99s not a remote procedure call framework or anything like that. Thanks, Ludo=E2=80=99.