From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Volkan YAZICI Newsgroups: gmane.lisp.guile.user Subject: Re: Guile Interpreter as a Standalone Server Date: Sat, 14 Oct 2006 23:27:35 +0300 Message-ID: <20061014202735.GA1317@alamut> References: <20061005180035.GA1376@alamut> <87zmc0760m.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1160857782 3400 80.91.229.2 (14 Oct 2006 20:29:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2006 20:29:42 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Oct 14 22:29:40 2006 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GYq8V-0007n0-B4 for guile-user@m.gmane.org; Sat, 14 Oct 2006 22:29:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GYq8U-0005px-Ri for guile-user@m.gmane.org; Sat, 14 Oct 2006 16:29:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GYq8P-0005l5-2v for guile-user@gnu.org; Sat, 14 Oct 2006 16:29:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GYq8N-0005gT-Q1 for guile-user@gnu.org; Sat, 14 Oct 2006 16:29:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GYq8N-0005fp-Jv for guile-user@gnu.org; Sat, 14 Oct 2006 16:29:27 -0400 Original-Received: from [212.175.13.129] (helo=fep07.ttnet.net.tr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GYqH7-00039S-GU for guile-user@gnu.org; Sat, 14 Oct 2006 16:38:29 -0400 Original-Received: from (unknown [192.168.8.107]) by AVGW-I-4.ttnet.net.tr with smtp id 3585_aedfb1e2_5bc2_11db_92b9_001422175f2f; Sat, 14 Oct 2006 23:29:26 +0300 Original-Received: from alamut ([85.97.14.253]) by fep07.ttnet.net.tr with ESMTP id <20061014202922.PMBB12702.fep07.ttnet.net.tr@alamut>; Sat, 14 Oct 2006 23:29:22 +0300 Original-Received: from (dsl.dynamic859714253.ttnet.net.tr [85.97.14.253]) by AVGW-I-5.ttnet.net.tr with smtp id 3f2a_a882e3fa_5bc2_11db_8a47_001422143cb8; Sat, 14 Oct 2006 23:29:19 +0300 Original-To: Ludovic =?iso-8859-1?Q?Court=E8s?= Content-Disposition: inline In-Reply-To: <87zmc0760m.fsf@laas.fr> User-Agent: Mutt/1.4.2.1i X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-2.5 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:5603 Archived-At: Hi, On Oct 13 02:30, Ludovic Courtès wrote: > Looks like nobody answered you, so here we go. Thanks so much for your detailed post. I solved (a small part of) my problem by invoking scm_init_guile() just at the start of the backend process. (But caching parse plans is still a PITA for now.) OTOH, in this design I've some other problems about restoring global values after execution code supplied by the user. (I'll talk about this later in another thread.) > Neil's new debugging framework (`guile-debugging', available in CVS HEAD > or on gna.org [0]) has support to send code for execution to a remote > Guile process so that might be useful to you. > > However, as far as improving efficiency is concerned, I do not think > that running a single process is the right approach. Profiling and then > improving Guile's startup may be a smarter approach. ;-) > > As for sharing information among processes: One could argue that the > notion of a process (and address space) is only vital for > non-memory-safe languages (such as C), and that memory-safe languages > (such as Scheme and Java) do not need such a mechanism because they > already provide other mechanisms to achieve memory safety (closures, > module systems, etc. --- see [1] on that topic). > > Thus, providing mechanisms to share information among "processes" (or > "modules", or "programs") would more likely be the job of a "shell", > i.e., some sort of an enhanced REPL that has all the authority of the > user behind the keyboard (i.e., it can access all the data, programs and > resources the user has access to). GUSH (``GNU User's Shell'') was more > or less an attempt to provide such a shell based on Guile, and indeed, > it would have been able to execute any Guile program _within_ the GUSH > process. SCSH [2] is similar to that, and there's also a Guile port [3] > (not sure whether this is the last version). > > Hope this helps, > Ludovic. > > [0] https://gna.org/projects/guile-debugging > [1] Jonathan Rees, "A Security Kernel Based on the Lambda-Calculus", > http://mumble.net/~jar/pubs/secureos/ --- a enlightening paper. > [2] http://scsh.net/ > [3] http://arglist.com/guile/ Thanks again, Regards. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user