* Guile Interpreter as a Standalone Server @ 2006-10-05 18:00 Volkan YAZICI 2006-10-13 12:30 ` Ludovic Courtès 2006-10-20 20:45 ` Neil Jerram 0 siblings, 2 replies; 5+ messages in thread From: Volkan YAZICI @ 2006-10-05 18:00 UTC (permalink / raw) Hi, I need such a feature: /* * If there's an already running guile process in the background, * return it, otherwise create a new one and return new process. */ interp = guile_interp(...); With such a functionality, it'd be possible to - Parse & execute faster. (We won't need to create a new process everytime.) - Cache parse plans. - Use global variables that's accessible by any process using the same interpreter. Is such a feature already supported by Guile? Can I achieve above 3 functionalities with using another method? Regards. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Guile Interpreter as a Standalone Server 2006-10-05 18:00 Guile Interpreter as a Standalone Server Volkan YAZICI @ 2006-10-13 12:30 ` Ludovic Courtès 2006-10-14 20:27 ` Volkan YAZICI 2006-10-20 20:45 ` Neil Jerram 1 sibling, 1 reply; 5+ messages in thread From: Ludovic Courtès @ 2006-10-13 12:30 UTC (permalink / raw) Cc: guile-user Hi, Looks like nobody answered you, so here we go. Volkan YAZICI <yazicivo@ttnet.net.tr> writes: > I need such a feature: > > /* > * If there's an already running guile process in the background, > * return it, otherwise create a new one and return new process. > */ > interp = guile_interp(...); > > With such a functionality, it'd be possible to > > - Parse & execute faster. (We won't need to create a new process > everytime.) > - Cache parse plans. > - Use global variables that's accessible by any process using the > same interpreter. > > Is such a feature already supported by Guile? Can I achieve above 3 > functionalities with using another method? 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/ _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Guile Interpreter as a Standalone Server 2006-10-13 12:30 ` Ludovic Courtès @ 2006-10-14 20:27 ` Volkan YAZICI 0 siblings, 0 replies; 5+ messages in thread From: Volkan YAZICI @ 2006-10-14 20:27 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Guile Interpreter as a Standalone Server 2006-10-05 18:00 Guile Interpreter as a Standalone Server Volkan YAZICI 2006-10-13 12:30 ` Ludovic Courtès @ 2006-10-20 20:45 ` Neil Jerram 2006-10-20 21:26 ` Volkan YAZICI 1 sibling, 1 reply; 5+ messages in thread From: Neil Jerram @ 2006-10-20 20:45 UTC (permalink / raw) Cc: guile-user Volkan YAZICI <yazicivo@ttnet.net.tr> writes: > Hi, > > I need such a feature: > > /* > * If there's an already running guile process in the background, > * return it, otherwise create a new one and return new process. > */ > interp = guile_interp(...); I appreciate that Ludovic has already replied to you about this, but I thought I'd some more thoughts. I think the core of this idea is pretty simple to implement, and I've appended a basic (and untested!) implementation of the server below. After the basics, however, I think you would quickly run into practical problems that are more tricky, such as whether you really want an eval from one client to affect global data for another one; what to do about error handling; what to do if an evaluation hangs; whether you want to constrain evaluations so that they take place in a "safe" environment; and so on. In my view, addressing all of these things carefully would make for an interesting project. > With such a functionality, it'd be possible to > > - Parse & execute faster. (We won't need to create a new process > everytime.) Is this for a specific application, out of interest? > - Cache parse plans. I don't understand what this item means. > - Use global variables that's accessible by any process using the > same interpreter. Yes - assuming that that is a desirable feature, in general. > Is such a feature already supported by Guile? Can I achieve above 3 > functionalities with using another method? This doesn't feel to me like something that needs to be supported by core Guile; it feels like a useful application that can be built on top of Guile. Regards, Neil (let loop ((server (let ((s (socket PF_INET SOCK_STREAM 0))) (setsockopt s SOL_SOCKET SO_REUSEADDR 1) (bind s AF_INET INADDR_ANY port) (listen s 5) s)) (clients '()) (readable '())) (if (null? readable) ;; Do a new select. (loop server clients (car (select (cons server clients) '() '()))) ;; Handle next readable socket. (let ((s (car readable))) (if (eq? s server) ;; Accept new connection. (loop server (cons (car (accept s)) clients) (cdr readable)) ;; Read from existing connection. (let ((x (read s))) (if (eof-object? x) ;; Connection closed. (loop server (delq s clients) (cdr readable)) ;; New form to evaluate. (begin (write (eval x (current-module)) s) (loop server clients (cdr readable))))))))) _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Guile Interpreter as a Standalone Server 2006-10-20 20:45 ` Neil Jerram @ 2006-10-20 21:26 ` Volkan YAZICI 0 siblings, 0 replies; 5+ messages in thread From: Volkan YAZICI @ 2006-10-20 21:26 UTC (permalink / raw) Cc: guile-user Hi, On Oct 20 09:45, Neil Jerram wrote: > Volkan YAZICI <yazicivo@ttnet.net.tr> writes: > > - Parse & execute faster. (We won't need to create a new process > > everytime.) > > Is this for a specific application, out of interest? Yes, it's for PL/scheme. [http://plscheme.projects.postgresql.org/] > > - Cache parse plans. > > I don't understand what this item means. You know, there're some procedure volatility levels in SQL. For instance, non-volatile (mmiutable) procedures always return same result as long as you supply same argument values. (Yes, we've caching for this in PL/scheme.) For volatile procedures, result depends on lots of outsource data, therefore its result is undeterminable. But, I had thought that at least I can make PL/scheme perform better by just executing the previously cached parse plan (by skipping parsing from scracth phase) parameters) of a volatile procedure called with exactly the same arguments. Regards. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-10-20 21:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-10-05 18:00 Guile Interpreter as a Standalone Server Volkan YAZICI 2006-10-13 12:30 ` Ludovic Courtès 2006-10-14 20:27 ` Volkan YAZICI 2006-10-20 20:45 ` Neil Jerram 2006-10-20 21:26 ` Volkan YAZICI
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).