From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Remco Bras" Newsgroups: gmane.lisp.guile.user Subject: Re: Can scm_shell be interrupted? Date: Fri, 16 May 2008 17:29:00 +0200 Message-ID: <20028b570805160829s6d7e83a8rc634f4dc0338c3c4@mail.gmail.com> References: <200805102254.59603.vrsoft@gmail.com> <87prrruuba.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1210971411 17514 80.91.229.12 (16 May 2008 20:56:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 May 2008 20:56:51 +0000 (UTC) Cc: guile-user@gnu.org To: "Neil Jerram" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri May 16 22:57:27 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jx6zX-0006vk-0E for guile-user@m.gmane.org; Fri, 16 May 2008 22:57:27 +0200 Original-Received: from localhost ([127.0.0.1]:52801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jx6yn-0004b4-C9 for guile-user@m.gmane.org; Fri, 16 May 2008 16:56:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jx1rk-0004Lm-D8 for guile-user@gnu.org; Fri, 16 May 2008 11:29:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jx1rh-0004Kc-P2 for guile-user@gnu.org; Fri, 16 May 2008 11:29:03 -0400 Original-Received: from [199.232.76.173] (port=47904 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jx1rh-0004KZ-G2 for guile-user@gnu.org; Fri, 16 May 2008 11:29:01 -0400 Original-Received: from wr-out-0506.google.com ([64.233.184.238]:1509) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jx1rh-0007yH-3O for guile-user@gnu.org; Fri, 16 May 2008 11:29:01 -0400 Original-Received: by wr-out-0506.google.com with SMTP id 57so451405wri.12 for ; Fri, 16 May 2008 08:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8tFLvxPpiNEmAW6/gC4U7xySNMYOee7CokvQszOjc3g=; b=v63irlEuhV4pZK/nTkfokX1ySG7vxL1X06b4F/lIWhA8uBlKKZaWMm5z0RgRO8syLeZU1O1b1gHXlSBFde3T/PbI4RC82D/XXyy9xonWrHRsXhcO3lJNIx+FYAp14Xp1FaDDtv/RiC1QGg9cCvhFx29f69C1DCn0Wob4ty80HtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WEvUXypkgRCAySHQyndHzRMlXweZiYJ/93y2YV9+ny3zcD3vZquvVe4+Ucbxbsfw1fpBcfJ4p1FioBsFiyHhCVILCD4XXbrwhH/ra0kqUJ2QW3jrgKinGPrEH2bufwTSa4NFiH7CokrTpm+Tsxx403YpjBxd3HRQq7bd7KVl9PA= Original-Received: by 10.114.136.1 with SMTP id j1mr3869688wad.85.1210951740208; Fri, 16 May 2008 08:29:00 -0700 (PDT) Original-Received: by 10.114.183.6 with HTTP; Fri, 16 May 2008 08:29:00 -0700 (PDT) In-Reply-To: <87prrruuba.fsf@ossau.uklinux.net> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-Mailman-Approved-At: Fri, 16 May 2008 16:55:58 -0400 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6566 Archived-At: Hi Neil, The REPL's input comes directly from stdin, usually attached to a terminal. My app is a game engine whose games are written in guile. Currently, the engine runs scm_shell in a separate thread on startup, so the user can interactively program his games. However, this causes issues if someone decides to distribute a game written for this engine and doesn't want players to play around interactively with the game data. Perhaps the simplest solution is to only run the REPL on demand, since the engine executes user-defined scheme files on startup anyway. If this is done, perhaps the repl thread could execute a loop, checking a POSIX condition variable or something similar and using scm_eval to evaluate code read from stdin, only switching the REPL off between reading expressions. That approach does solve the problem where a user types half an expression on a line, without finishing it on the next line. If a user's REPL is suddenly turned off while he is still typing an expression, that would be annoying, but probably the game code's fault as I intend to offer this functionality as a part of the interface, rather than controlling the REPL in the engine. Regards, Remco On 5/12/08, Neil Jerram wrote: > Remco Bras writes: > >> Hello, >> >> I have a question about guile. I'd like to know if it is feasible to run a >> >> guile REPL and control when it runs. For example, consider the following >> scenario. A package may or may not have a thread running scm_shell, when >> the >> user requests that the package runs an REPL. The package responds by >> running >> scm_shell in a thread and keeping that thread's ID. If the user wants the >> package to stop the REPL at any moment, is there a way to do this safely? > > Where does the REPL's input come from? > > If its stdin, being read in a blocking way (as is the default), it > would be tricky if the REPL thread did the read directly. But you > could have a special stdin-reader thread, responsible for reading and > buffering lines of input, and then supplying them to whichever REPL > runs next. > > What happens if the user wants to stop a package's REPL when the user > has already typed half a line of input into that REPL? > > It might also be possible to make stdin non-blocking, and use select > to avoid trying to read before there is a whole line available. > > If its a GUI app, it becomes less a matter of a REPL reading from a > port, and more a matter of a widget collecting input which can then be > passed into the REPL. (Although the two approaches can be reconciled; > see graphical-repl.scm in guile-gnome.) I think that fits slightly > more naturally with your idea of a selectable REPL, so may be easier > to implement in your app. > > In summary: lots of options, need more detail about how your overall > app works and what you want it to look like. > > Regards, > Neil > >