* scm_* API question @ 2002-07-30 12:14 rm 2002-07-31 1:09 ` Christopher Cramer 2002-07-31 10:11 ` Marius Vollmer 0 siblings, 2 replies; 22+ messages in thread From: rm @ 2002-07-30 12:14 UTC (permalink / raw) Hello List, i have a short API question: in my application i have a SCM value that holds a list of symbols. I need to a) find the module that corresponds to this list, i.e. the scm_* counterpart of guile's resolve-module. Is: SCM my_list, my_module, my_symbol; ... my_module = scm_resolve_module(my_list); the right way? b) access symbols from the module. Is: my_symbol = scm_module_lookup(my_module, a_symbol); ok? c) use the module i found in step a. Hmm, the only thing i found so far is 'scm_c_use_module(char *)', but that takes a string (even without the enclosing brackets!) so i can't really use this (or do i have to build the string myself from my SCM list? Kind of silly, considering the fact that the list was built from a string using scm_c_read_string(char *). Oh, btw, whad _does_ scm_c_read_string return if string isn't a valid S-expression? TIA Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API question 2002-07-30 12:14 scm_* API question rm @ 2002-07-31 1:09 ` Christopher Cramer 2002-07-31 10:03 ` scm_* API extension? [was] " rm 2002-07-31 10:11 ` Marius Vollmer 1 sibling, 1 reply; 22+ messages in thread From: Christopher Cramer @ 2002-07-31 1:09 UTC (permalink / raw) Cc: guile-devel On Tue, Jul 30, 2002 at 02:14:36PM +0200, rm@fabula.de wrote: > in my application i have a SCM value that holds > a list of symbols. I need to > > a) find the module that corresponds to this list, > i.e. the scm_* counterpart of guile's resolve-module. > Is: > > SCM my_list, my_module, my_symbol; > > ... > my_module = scm_resolve_module(my_list); > > the right way? Yes. Well, I think it might fail if the module isn't already loaded. > b) access symbols from the module. Is: > > my_symbol = scm_module_lookup(my_module, a_symbol); > > ok? Yes. > c) use the module i found in step a. Hmm, the only thing i > found so far is 'scm_c_use_module(char *)', but that takes > a string (even without the enclosing brackets!) so i can't > really use this (or do i have to build the string myself > from my SCM list? Kind of silly, considering the fact that the > list was built from a string using scm_c_read_string(char *). Well, scm_c_use_module just calls process-use-modules, so you could do that directly. > Oh, btw, whad _does_ scm_c_read_string return if string isn't > a valid S-expression? It shouldn't return, but throw an exception with the misc-error key and a helpful message. -- Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/> On résiste à l'invasion des armées; on ne résiste pas à l'invasion des idées. -- Victor Hugo _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* scm_* API extension? [was] scm_* API question 2002-07-31 1:09 ` Christopher Cramer @ 2002-07-31 10:03 ` rm 2002-07-31 10:10 ` Marius Vollmer 0 siblings, 1 reply; 22+ messages in thread From: rm @ 2002-07-31 10:03 UTC (permalink / raw) On Tue, Jul 30, 2002 at 08:09:29PM -0500, Christopher Cramer wrote: > > ... > > my_module = scm_resolve_module(my_list); > > > > the right way? > > Yes. Well, I think it might fail if the module isn't already loaded. It _seems_ to work and load the requested module. > > Well, scm_c_use_module just calls process-use-modules, so you could > do that directly. hmm, 'process-use-modules' is an the _scheme_ level, i'm loking at the C level -- there seems to be no scm_* level function for this. Libguile uses a call to the function pointed by 'process_use_modules_var', but that variable is declared static in modules.c. So, if i understand right i have to duplicate the code from modules.c (i.e. lookup the 'process-use-modules' function and apply it to my list of symbols). Would it be usefull to provide a scm_* function for it? /* file: modules.c */ /* @code{scm_use_module}(@val{list}) @code{scm_use_module} imports bindings exported from the module defined by the list of symbols given as the parameter @var{list}. This function is the equivalent of the guile level call @code{(use-modules list)}. */ void scm_use_module(SCM list) { scm_call_1(SCM_VARIABLE_REF(process_use_module_var), list); } > > Oh, btw, whad _does_ scm_c_read_string return if string isn't > > a valid S-expression? > > It shouldn't return, but throw an exception with the misc-error key > and a helpful message. > Ok, thank's a lot for this information. Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 10:03 ` scm_* API extension? [was] " rm @ 2002-07-31 10:10 ` Marius Vollmer 2002-07-31 18:21 ` rm 2002-07-31 20:06 ` Christopher Cramer 0 siblings, 2 replies; 22+ messages in thread From: Marius Vollmer @ 2002-07-31 10:10 UTC (permalink / raw) Cc: guile-devel rm@fabula.de writes: > Would it be usefull to provide a scm_* function for it? Yes. I will add this to CVS. However, I'd say it is better to code all module system manipulations in Scheme and try to keep the C code 'module system ignorant' if that is possible. Why do you want to perform module system operations from C? Maybe there is a more elegant way. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 10:10 ` Marius Vollmer @ 2002-07-31 18:21 ` rm 2002-07-31 21:59 ` Rob Browning 2002-08-05 15:08 ` Marius Vollmer 2002-07-31 20:06 ` Christopher Cramer 1 sibling, 2 replies; 22+ messages in thread From: rm @ 2002-07-31 18:21 UTC (permalink / raw) Cc: rm, guile-devel On Wed, Jul 31, 2002 at 12:10:19PM +0200, Marius Vollmer wrote: > rm@fabula.de writes: > > > Would it be usefull to provide a scm_* function for it? > > Yes. I will add this to CVS. > > However, I'd say it is better to code all module system manipulations > in Scheme and try to keep the C code 'module system ignorant' if that > is possible. > > Why do you want to perform module system operations from C? Maybe > there is a more elegant way. Ok this is for my current (frankensteinish) hacking with Dave's mod_guile: i'm working on implementing a mod_guile mode in which URLs get mapped to so-called 'handlers' in modules - meaning i (ab?)use the hierarchical module space a namespace enclosures. Hmm, i guess this sounds rather confusing, so here is a small example. I the server configureation on can do the following: <Location /cool/stuff> SetHandler guile-handler GuileContentHandler (web linkdatabase cool) </Location> <Location /biblio> SetHandler guile-handler GuileContentHandler (web apps biblio) </Location> Whenever a request for http://localhost/biblio comes in the webserver invokes the 'handler' method from the module (web apps biblio). Ah, in case one wants a different name, 'GuileContentHandler' will also accept a pair of the form '(module-spec . handler)' that allows us to specifiy the name of the function that gets invoked (and hence we can define more than one handler within one module). I'll also plan to add something like GuileBind a-symbol '(arbitrary (guile data) structure) i.e. i want guile to 'read' from the configuration file and bind 'a-symbol' to whatever was read. As a side note: as a quick hack i put the symbol into the module but i'd rather like to use something like an environment i can set up myself (i hope setting up an environment isn't to expensive performance wise), but i have way too little understanding about how to do this right now. But it would make a _way_ cool web environment -- full control over the env. means secure execution as well as probably some nice passing on of context. BTW, one reasons i do use the module system is the impicit cacheing i get: a module gets loaded only once, and that does make a difference in response time compared to the initial 'eval a file per request' aproach of mod_guile. Ralf Mattes > _______________________________________________ > Guile-devel mailing list > Guile-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/guile-devel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 18:21 ` rm @ 2002-07-31 21:59 ` Rob Browning 2002-08-01 10:10 ` rm 2002-08-05 15:08 ` Marius Vollmer 1 sibling, 1 reply; 22+ messages in thread From: Rob Browning @ 2002-07-31 21:59 UTC (permalink / raw) Cc: Marius Vollmer, guile-devel rm@fabula.de writes: > GuileBind a-symbol '(arbitrary (guile data) structure) > i.e. i want guile to 'read' from the configuration file and bind > 'a-symbol' to whatever was read. As a side note: as a quick hack i > put the symbol into the module but i'd rather like to use something > like an environment i can set up myself (i hope setting up an > environment isn't to expensive performance wise), but i have way too > little understanding about how to do this right now. But it would > make a _way_ cool web environment -- full control over the env. > means secure execution as well as probably some nice passing on of > context. You may want to look at ice-9/safe.scm and ice-9/safe-r5rs.scm. You can see how to at least create your own anonymous modules: (use-modules (ice-9 safe)) (define my-module (make-safe-module)) (eval 'car my-module) #<primitive-procedure car> or if you want an even more limited envt: (use-modules (ice-9 safe-r5rs)) (define my-module (null-environment 5)) (eval 'if my-module) #<primitive-macro! if> (eval 'car my-module) ABORT: (unbound-variable) and then: (module-define! my-module 'my-func (lambda (x) x)) etc. There's also a module-ref function and a module-use! function... > BTW, one reasons i do use the module system is the impicit cacheing > i get: a module gets loaded only once, and that does make a > difference in response time compared to the initial 'eval a file per > request' aproach of mod_guile. Well that may or may not be the right thing to do if you're *just* using the module system for the caching. In that case, you may be better off to implement the caching yourself (via a hash table or whatever) and leave the module system to more static modules. For example, depending on what you're wanting to do, you might want to allow different requests to be handled inside separate namespaces, though they're all using a common set of code. OTTOMH, I think you could do this by putting the common functionality into a module, say foo.scm, then doing something like this for *each* request: (use-modules (foo)) (define foo-module (resolve-module '(foo))) ;; For each request... (define next-request-envt (make-safe-module)) (module-use! next-request-envt (module-public-interface foo-module)) (define request-form (list handler-sym current-url-string)) (eval request-form next-request-envt) Marius, etc. Please correct any inaccuracies above -- I'm just going from what I've gathered while poking around. I suspect we need more thorough documentation of the acceptable usage of the anonymous module stuff. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 21:59 ` Rob Browning @ 2002-08-01 10:10 ` rm 2002-08-01 16:51 ` Rob Browning 0 siblings, 1 reply; 22+ messages in thread From: rm @ 2002-08-01 10:10 UTC (permalink / raw) Cc: rm, Marius Vollmer, guile-devel On Wed, Jul 31, 2002 at 04:59:35PM -0500, Rob Browning wrote: [ nice samples removed ] > > etc. There's also a module-ref function and a module-use! function... I konw these, but this is all done from the scheme side. I just want to be able to do the same cool things from C (other than scm_call_*ing the functions from (ice-9 safe) etc.). > > BTW, one reasons i do use the module system is the impicit cacheing > > i get: a module gets loaded only once, and that does make a > > difference in response time compared to the initial 'eval a file per > > request' aproach of mod_guile. > > Well that may or may not be the right thing to do if you're *just* > using the module system for the caching. In that case, you may be > better off to implement the caching yourself (via a hash table or > whatever) and leave the module system to more static modules. No, cacheing is just a (very) nice side effect. My main rationale is the namespace encapsulation. In general i think these modules should be considered static -- during the lifetime of a server the code for a handler shouldn't change. I put things like 'GuileBind ... ' into the handler's module since i haven't understood how to do the same with environments so far. > For example, depending on what you're wanting to do, you might want to > allow different requests to be handled inside separate namespaces, > though they're all using a common set of code. OTTOMH, I think you > could do this by putting the common functionality into a module, say > foo.scm, then doing something like this for *each* request: > > (use-modules (foo)) > (define foo-module (resolve-module '(foo))) > > ;; For each request... > (define next-request-envt (make-safe-module)) ^ ^ | | *----------------* | Does this mean: module <=> environment in guile? > (module-use! next-request-envt (module-public-interface foo-module)) > (define request-form (list handler-sym current-url-string)) > (eval request-form next-request-envt) > > Marius, etc. Please correct any inaccuracies above -- I'm just going > from what I've gathered while poking around. I suspect we need more > thorough documentation of the acceptable usage of the anonymous module > stuff. Would be highly welcome ;-) Ralf _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-01 10:10 ` rm @ 2002-08-01 16:51 ` Rob Browning 0 siblings, 0 replies; 22+ messages in thread From: Rob Browning @ 2002-08-01 16:51 UTC (permalink / raw) Cc: Marius Vollmer, guile-devel rm@fabula.de writes: >> For example, depending on what you're wanting to do, you might want to >> allow different requests to be handled inside separate namespaces, >> though they're all using a common set of code. OTTOMH, I think you >> could do this by putting the common functionality into a module, say >> foo.scm, then doing something like this for *each* request: >> >> (use-modules (foo)) >> (define foo-module (resolve-module '(foo))) >> >> ;; For each request... >> (define next-request-envt (make-safe-module)) > ^ ^ > | | > *----------------* > | > > Does this mean: module <=> environment in guile? Hmm -- I suspect that depends on what we mean by each of those terms. If it helps, in the above I just used envt loosely, I could have just as easily used "-sandbox" as "-envt". -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 18:21 ` rm 2002-07-31 21:59 ` Rob Browning @ 2002-08-05 15:08 ` Marius Vollmer 2002-08-05 16:06 ` rm 1 sibling, 1 reply; 22+ messages in thread From: Marius Vollmer @ 2002-08-05 15:08 UTC (permalink / raw) Cc: guile-devel rm@fabula.de writes: > > Why do you want to perform module system operations from C? Maybe > > there is a more elegant way. > > Ok this is for my current (frankensteinish) hacking with Dave's mod_guile: > i'm working on implementing a mod_guile mode in which URLs get mapped to > so-called 'handlers' in modules - meaning i (ab?)use the hierarchical module > space a namespace enclosures. That sounds rather reasonable to me. But do you need to invoke 'use-modules' for this? What I would probably do is to have a single Scheme function that gets called from C, and perform all the dispatching in Scheme. That function would be called with different arguments for different <Location>s. I suppose, all Apache can really handle in its configuration file are strings. So I would make my Scheme function take a string as its argument. When the function wants to interpret that string as a Scheme form, it can do so. (Calling 'read' from Scheme is no less efficient than calling it from C, but more convenient.) Maybe I would even require the Scheme code to register the dispatching function with the C code before it can be used. That way, the C code is completely independent from the Scheme code and the interactions between the too are not via magic names but by explicit API calls. > I'll also plan to add something like > > GuileBind a-symbol '(arbitrary (guile data) structure) > > i.e. i want guile to 'read' from the configuration file and bind > 'a-symbol' to whatever was read. I think I would pass extra information via the handler callback, not as a variable, but of course I can't say whether that will be feasible in your case. > BTW, one reasons i do use the module system is the impicit cacheing i get: > a module gets loaded only once, and that does make a difference in response > time compared to the initial 'eval a file per request' aproach of mod_guile. I see. mod_guile should probably have a 'call a function per request' kind of model. That is just as flexible but does not have to be slow. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-05 15:08 ` Marius Vollmer @ 2002-08-05 16:06 ` rm 2002-08-05 16:49 ` Marius Vollmer 0 siblings, 1 reply; 22+ messages in thread From: rm @ 2002-08-05 16:06 UTC (permalink / raw) Cc: rm, guile-devel On Mon, Aug 05, 2002 at 05:08:45PM +0200, Marius Vollmer wrote: > rm@fabula.de writes: > > Ok this is for my current (frankensteinish) hacking with Dave's mod_guile: > > i'm working on implementing a mod_guile mode in which URLs get mapped to > > so-called 'handlers' in modules - meaning i (ab?)use the hierarchical module > > space a namespace enclosures. > > That sounds rather reasonable to me. But do you need to invoke > 'use-modules' for this? As i just found out, no ;-) > What I would probably do is to have a single Scheme function that gets > called from C, and perform all the dispatching in Scheme. That > function would be called with different arguments for different > <Location>s. This is probably a matter of taste, but i'd like to reuse guiles allready existing dispatch mechanisms. > > I suppose, all Apache can really handle in its configuration file are > strings. Well, on one level, yes (since a configuration file _is_ a looong string). Currently i handle these configuration options as 'raw' options, i.e. Apache does no tokenisation at all -- the character stream gets fed to scm_read_string, so after reading of the configuration file i have all configuration settings as SCM structures. It would be trivial to extend the configuration process to actually have the handler defined in the configuration file: <Location /fou> GuileContentLamda (lambda (request) (let ((user (req:remote-user request)) (hist (req:host request)) ..... ) </Location> > So I would make my Scheme function take a string as its > argument. When the function wants to interpret that string as a > Scheme form, it can do so. (Calling 'read' from Scheme is no less > efficient than calling it from C, but more convenient.) > > Maybe I would even require the Scheme code to register the dispatching > function with the C code before it can be used. That way, the C code > is completely independent from the Scheme code and the interactions > between the too are not via magic names but by explicit API calls. > > > I'll also plan to add something like > > > > GuileBind a-symbol '(arbitrary (guile data) structure) > > > > i.e. i want guile to 'read' from the configuration file and bind > > 'a-symbol' to whatever was read. > > I think I would pass extra information via the handler callback, not > as a variable, but of course I can't say whether that will be feasible > in your case. Hmmm, "filling up" the environment in which the handler executes with some predifined values can be rather handy. I wanted to implement this because it's a feature i often used in mod_perl projects. Imagine an online shop: <Location /golfers-online> ... GuileDefine bg-color "PapayaWhip" GuileDefine text-color "DarkSlateGey" <Location> <Location /heavy-metal/shop> ... GuileDefine bg-color "black" GuileDefine text-color "orange" <Location> > > I see. mod_guile should probably have a 'call a function per request' > kind of model. That is just as flexible but does not have to be slow. Right now, i try to get my hands on the actual handler function during configuration reading/parsing (as a side effect we can raise an error if there's a problem with the configuration). The SCM value gets stored in Apache's per-location configuration. Whenever a location (URL) that's handled by mod_guile gets requested the appropriate hander function gets appied to the request [scm_call_1(...)] (possibly after setting up the environment). Thank's for your input Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-05 16:06 ` rm @ 2002-08-05 16:49 ` Marius Vollmer 0 siblings, 0 replies; 22+ messages in thread From: Marius Vollmer @ 2002-08-05 16:49 UTC (permalink / raw) Cc: guile-devel rm@fabula.de writes: > > What I would probably do is to have a single Scheme function that gets > > called from C, and perform all the dispatching in Scheme. That > > function would be called with different arguments for different > > <Location>s. > > This is probably a matter of taste, but i'd like to reuse guiles > allready existing dispatch mechanisms. Yes, and you can do that from Scheme as well. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 10:10 ` Marius Vollmer 2002-07-31 18:21 ` rm @ 2002-07-31 20:06 ` Christopher Cramer 2002-07-31 22:14 ` Rob Browning ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Christopher Cramer @ 2002-07-31 20:06 UTC (permalink / raw) Cc: guile-devel On Wed, Jul 31, 2002 at 12:10:19PM +0200, Marius Vollmer wrote: > rm@fabula.de writes: > > > Would it be usefull to provide a scm_* function for it? > > Yes. I will add this to CVS. > > However, I'd say it is better to code all module system manipulations > in Scheme and try to keep the C code 'module system ignorant' if that > is possible. > > Why do you want to perform module system operations from C? Maybe > there is a more elegant way. I have no idea why you think it would better, but with certain types of applications, it's impossible. For sake of argument, let's say there are two different ways to use Guile. One way is to extend Guile through C, by using load-extension. This works fine if the C code is ignorant of the module system (writing a wrapper module in Scheme handles everything). The other way is to extend C through Guile, which cannot stay module system ignorant, because you typically want to load multiple Scheme scripts without worrying about clashing symbols from the different scripts -- this is currently impossible without getting deep into the details of the module system. I can provide examples of what I had to do with Recluse; roughly 300 lines of C code are devoted to dealing with the module system. -- Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/> On résiste à l'invasion des armées; on ne résiste pas à l'invasion des idées. -- Victor Hugo _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 20:06 ` Christopher Cramer @ 2002-07-31 22:14 ` Rob Browning 2002-08-01 9:41 ` rm 2002-08-05 15:12 ` Marius Vollmer 2 siblings, 0 replies; 22+ messages in thread From: Rob Browning @ 2002-07-31 22:14 UTC (permalink / raw) Cc: guile-devel Christopher Cramer <crayc@pyro.net> writes: > I have no idea why you think it would better, but with certain types > of applications, it's impossible. There are also cases where it seems clearer if the C side deals with modules explicitly. For example, we had a decent amount of trouble in gnucash because we were using gh_eval_str on the C side to get scheme side bindings we needed in certain situations. This was a while back (started years ago in fact), and before we fully realized how guile's module system worked. Switching to scm_c_module_ref (or other forms of explicit lookup) makes it much clearer in the code what's actually going on, and certainly makes it more likely to "do what we mean :>". I think at least initially it can be easy to forget that on the C side, there's no such thing as a lexical current-module. In the cases I've run in to, one of the most common situations was that the C code needed to look up a variable or function on the scheme side and then use it. In many cases the code *could* have been rewritten to avoid the use of the C->scheme lookup, but in some cases such a change would have made the code a lot more complex than necessary. Sometimes all you want is (this is definitely just psuedo-code): void magic_button_callback () { gh_call0(scm_c_module_lookup(..., "magic-button-callback")); } sometoolkit_button_attach_callback(button, magic_button_callback); and in this case, maybe you *want* the button press to use whatever's currently bound to 'magic-button-callback -- a-la emacs 'foo rather than just what was bound when you attached the callback. There are defintely other ways you could handle this, but this seems pretty straightforward... FWIW -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 20:06 ` Christopher Cramer 2002-07-31 22:14 ` Rob Browning @ 2002-08-01 9:41 ` rm 2002-08-05 17:51 ` Marius Vollmer 2002-08-05 15:12 ` Marius Vollmer 2 siblings, 1 reply; 22+ messages in thread From: rm @ 2002-08-01 9:41 UTC (permalink / raw) On Wed, Jul 31, 2002 at 03:06:02PM -0500, Christopher Cramer wrote: > I have no idea why you think it would better, but with certain types of > applications, it's impossible. > > For sake of argument, let's say there are two different ways to use Guile. > One way is to extend Guile through C, by using load-extension. This works > fine if the C code is ignorant of the module system (writing a wrapper > module in Scheme handles everything). The other way is to extend C through > Guile, which cannot stay module system ignorant, because you typically > want to load multiple Scheme scripts without worrying about clashing > symbols from the different scripts -- this is currently impossible > without getting deep into the details of the module system. Yes, this is exactly the situation i just encountered. I know that everyone and their grandmother tells me to write everything in the scripting language but i just don't feel like rewriting Apache in guile -- besides: that might p**s of a lot of perl hackers ;-) As a user of _embedded_ guile there a a few specific things i'd expect from my ideal scripting language: - clear encapsulation of namespaces and scope (something i missed in TCL for example) - for this is currently use guile's module system, but i need to have access to the module mechanics from my C side. - save execution/evaluation of script code. I need to ensure that i can reliably dissable certain things: a user script should not be allowed to call (exit 0) and bring down the whole webserver ;-) - An (opaque) representation of an 'interpreter'. One thing i found rather elegant in TCL (perl to, if i recall correctly) was the possiblility to run several interpreters in parallel. Guile seems to completly lack this (i think i understand why, but i still miss it). - Thread support. I'm personally not a big friend of threaded apps, but it seems that more and more code assumes thread awareness. For example i'd love to port mod_guile to Apache2, but unfortunately Apache2 _can_ be configured at runtime to work in multithread mode (or even a mixture of prefork and multithread). For my personal use i don't care since i can just _not_ enable multithreaded operation but a mod_guile that doesn't work in certain operation modes will just not make it into any distribution. > I can provide examples of what I had to do with Recluse; roughly 300 lines > of C code are devoted to dealing with the module system. (define Ralf idiot) I should've just looked at your code instead of bugging the list ;-) Ralf _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-01 9:41 ` rm @ 2002-08-05 17:51 ` Marius Vollmer 2002-08-05 18:12 ` Han-Wen Nienhuys ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Marius Vollmer @ 2002-08-05 17:51 UTC (permalink / raw) Cc: guile-devel rm@fabula.de writes: > On Wed, Jul 31, 2002 at 03:06:02PM -0500, Christopher Cramer wrote: > > I have no idea why you think it would better, but with certain types of > > applications, it's impossible. > > > > For sake of argument, let's say there are two different ways to use Guile. > > One way is to extend Guile through C, by using load-extension. This works > > fine if the C code is ignorant of the module system (writing a wrapper > > module in Scheme handles everything). The other way is to extend C through > > Guile, which cannot stay module system ignorant, because you typically > > want to load multiple Scheme scripts without worrying about clashing > > symbols from the different scripts -- this is currently impossible > > without getting deep into the details of the module system. > > Yes, this is exactly the situation i just encountered. I know that > everyone and their grandmother tells me to write everything in the > scripting language but i just don't feel like rewriting Apache in guile -- > besides: that might p**s of a lot of perl hackers ;-) I think just makes sense to write as much of your system in the extension language as possible, once you have an extension language. If you'd rather write it in C..., well, I guess we have to just accept that. > - save execution/evaluation of script code. I need to ensure that i > can reliably dissable certain things: a user script should not be > allowed to call (exit 0) and bring down the whole webserver ;-) However, you should be careful not to accidentally reimplement the OS's security features in your application. The fewer code you have to trust the better. I don't want to trust Java to keep its sandboxes clean. I'd rather factor the application into a number of processes that run in a chroot jail with their own uid/gid and have the kernel/hardware watch them. Untrusted external code would be run inside such a restricted process. > - An (opaque) representation of an 'interpreter'. One thing i found > rather elegant in TCL (perl to, if i recall correctly) was the > possiblility to run several interpreters in parallel. Guile seems > to completly lack this (i think i understand why, but i still miss > it). What is an 'interpreter'? What do multiple instances of the interpreter have in common, what is specific to each instance? I think that once you know what you want from multiple interpreters, you can implement them easily with the features we already have. Or with fork. > - Thread support. Yep, but it seems to be hard in its full generality. Cooperative threads work fine, tho. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-05 17:51 ` Marius Vollmer @ 2002-08-05 18:12 ` Han-Wen Nienhuys 2002-08-05 18:45 ` Rob Browning 2002-08-05 18:31 ` Rob Browning 2002-08-05 18:33 ` rm 2 siblings, 1 reply; 22+ messages in thread From: Han-Wen Nienhuys @ 2002-08-05 18:12 UTC (permalink / raw) Cc: rm, guile-devel marius.vollmer@uni-dortmund.de writes: > > What is an 'interpreter'? What do multiple instances of the > interpreter have in common, what is specific to each instance? I > think that once you know what you want from multiple interpreters, you > can implement them easily with the features we already have. Or with > fork. What I want is a way to encapsulate state changes; modules give a nice way to deal with naming variables, but not with their values. When I have two lilypond files, one doing f1.ly #(set! global-foo-option #t) ;; default = #f \score {\notes { .. } } f2.ly \score { \notes { ..other notes.. } } What really happens during execution depends on the order of execution: if you do lilypond f1 f2 then f2 is processed with global-foo-option set to #t. If you change the order, then f2 is processed with global-foo-option set to #f. It would be nice if we could have some kind of copy-on-write system for variables, so that I can reset the state of the variables before processing each new file. [disclaimer, I know nothing of advanced Scheme techniques, I might be missing some basic idiom here completely.] -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen/ _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-05 18:12 ` Han-Wen Nienhuys @ 2002-08-05 18:45 ` Rob Browning 0 siblings, 0 replies; 22+ messages in thread From: Rob Browning @ 2002-08-05 18:45 UTC (permalink / raw) Cc: Marius Vollmer, rm, guile-devel Han-Wen Nienhuys <hanwen@cs.uu.nl> writes: > f1.ly > > #(set! global-foo-option #t) ;; default = #f > \score {\notes { .. } } > > f2.ly > > \score { \notes { ..other notes.. } } > > What really happens during execution depends on the order of > execution: if you do > > lilypond f1 f2 > > then f2 is processed with global-foo-option set to #t. If you change > the order, then f2 is processed with global-foo-option set to #f. > > It would be nice if we could have some kind of copy-on-write system > for variables, so that I can reset the state of the variables before > processing each new file. > > [disclaimer, I know nothing of advanced Scheme techniques, I might be > missing some basic idiom here completely.] I'm not familiar with what lilypond is doing, but can you do one of: * create a new "anonymous module" (as I described in an answer to the mod_guile thread) for each file/"session" you're going to load, initialize the module by calling (eval '(ly-initialize-sandbox) *current-user-module*) then execute the user's code in there with another appropriate eval. * Don't use globals. Hide all the lilypond specific state inside a relevant per-load-file data structure that's either newly created or reinitialized with each file load. * Have a suitable initialization function that resets the state of the global envt appropriately and call that between .ly files loads. In general, this is easier if you don't make changing global variables part of the public API -- i.e. *everything* should be a function like (ly-set-global-foo-option! value). This way you have a lot more control over what's going on and it's a lot easier to keep track or clean up after user changes. For (simplistic) example, if you write an editor and don't make raw set!'s part of the public API, then you can more easily implement undo: (define (sillyedit-change-margin-width! width) (push-undo! (let ((old-width (silly-edit-get-margin-width))) (lambda () (se-lowlevel-set-margin-width! old-width)))) (se-lowlevel-set-margin-width width)) With this approach, multiple levels of undo just involve replaying the undo list (of course *really* getting undo/redo right is *much* harder). Anyway, IMO it's often better not to expose variables -- use functions for everyhing so you'll be able to rearrange your internal semantics later if you want/need to. It's also easier if/when you ever want to migrate to a threaded environment. * create your own recursive descent mini-parser for the language in question (if it's sufficiently different from plain scheme, or if you need super-anal security or error checking), and just load and "evaluate" the .ly files with that parser. You can reinitialize it between runs. Hope this helps. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-05 17:51 ` Marius Vollmer 2002-08-05 18:12 ` Han-Wen Nienhuys @ 2002-08-05 18:31 ` Rob Browning 2002-08-05 18:33 ` rm 2 siblings, 0 replies; 22+ messages in thread From: Rob Browning @ 2002-08-05 18:31 UTC (permalink / raw) Cc: rm, guile-devel Marius Vollmer <marius.vollmer@uni-dortmund.de> writes: >> - Thread support. > > Yep, but it seems to be hard in its full generality. Cooperative > threads work fine, tho. Yeah. Fully blown preemptive threads would be hard, and would likely have non-trivial attendant costs, but without solving that problem right now (if ever), does anyone know how we stand on the POSIX threads front? Can we coexist with them OK, or are there fundamental issues(TM). -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-08-05 17:51 ` Marius Vollmer 2002-08-05 18:12 ` Han-Wen Nienhuys 2002-08-05 18:31 ` Rob Browning @ 2002-08-05 18:33 ` rm 2 siblings, 0 replies; 22+ messages in thread From: rm @ 2002-08-05 18:33 UTC (permalink / raw) Cc: rm, guile-devel On Mon, Aug 05, 2002 at 07:51:11PM +0200, Marius Vollmer wrote: [...] > > > > Yes, this is exactly the situation i just encountered. I know that > > everyone and their grandmother tells me to write everything in the > > scripting language but i just don't feel like rewriting Apache in guile -- > > besides: that might p**s of a lot of perl hackers ;-) > > I think just makes sense to write as much of your system in the > extension language as possible, once you have an extension language. I'd fully agree with you if we where talking about an application that has _one_ extension language ([X]emacs comes to mind). If most of the code lives in extension space the whole system gets more felxible. BUT, here we talk about Apache, where we have mod_{perl python lisp haskell ...} and a plehora of utility functions so mighty that they got factored into their own library. If i where to write my own webserver i'd probaby code the URL dispatch in scheme, but i think it would be a waste of time not using Apaches existing functionality for that (and, i have to admit, it's pretty impressive fast :) As a side effect, a can mix extensions written in different languages (have my access controlled by a C-level LDAP module and have my logging done in TCL ... > If you'd rather write it in C..., well, I guess we have to just accept > that. Not a question of language preference. Maybe i got to much used to "how mod_perl" does it, but then, it's not the worst way. > > - save execution/evaluation of script code. I need to ensure that i > > can reliably dissable certain things: a user script should not be > > allowed to call (exit 0) and bring down the whole webserver ;-) > > However, you should be careful not to accidentally reimplement the > OS's security features in your application. The fewer code you have > to trust the better. I don't want to trust Java to keep its sandboxes > clean. I'd rather factor the application into a number of processes > that run in a chroot jail with their own uid/gid and have the > kernel/hardware watch them. Untrusted external code would be run > inside such a restricted process. Hmm, i don't think these things exclude each other -- i'd say: use both. Especially with webserver you need both. Apache, for example can be con- figured to provide 'Virtual Servers'. Often on server process has to server requests for many different domains (read: probably many different customers) the one jailed process per security realm doesn't realy work. > > - An (opaque) representation of an 'interpreter'. One thing i found > > rather elegant in TCL (perl to, if i recall correctly) was the > > possiblility to run several interpreters in parallel. Guile seems > > to completly lack this (i think i understand why, but i still miss > > it). > > What is an 'interpreter'? What do multiple instances of the > interpreter have in common, what is specific to each instance? I > think that once you know what you want from multiple interpreters, you > can implement them easily with the features we already have. Or with > fork. I try to define my needs a bit clearer (need more time). > > - Thread support. > > Yep, but it seems to be hard in its full generality. Cooperative > threads work fine, tho. Oh, i understand. It just makes things hard if you have to live in an mutithreaded application (like Apache2). Ralf _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API extension? [was] scm_* API question 2002-07-31 20:06 ` Christopher Cramer 2002-07-31 22:14 ` Rob Browning 2002-08-01 9:41 ` rm @ 2002-08-05 15:12 ` Marius Vollmer 2 siblings, 0 replies; 22+ messages in thread From: Marius Vollmer @ 2002-08-05 15:12 UTC (permalink / raw) Cc: guile-devel Christopher Cramer <crayc@pyro.net> writes: > For sake of argument, let's say there are two different ways to use Guile. > One way is to extend Guile through C, by using load-extension. This works > fine if the C code is ignorant of the module system (writing a wrapper > module in Scheme handles everything). The other way is to extend C through > Guile, which cannot stay module system ignorant, because you typically > want to load multiple Scheme scripts without worrying about clashing > symbols from the different scripts -- this is currently impossible > without getting deep into the details of the module system. But the code that loads the scripts could be written in Scheme, no? > I can provide examples of what I had to do with Recluse; roughly 300 lines > of C code are devoted to dealing with the module system. Can you say from that experience how we should extend the module system API for C? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API question 2002-07-30 12:14 scm_* API question rm 2002-07-31 1:09 ` Christopher Cramer @ 2002-07-31 10:11 ` Marius Vollmer 2002-07-31 10:30 ` rm 1 sibling, 1 reply; 22+ messages in thread From: Marius Vollmer @ 2002-07-31 10:11 UTC (permalink / raw) Cc: guile-devel rm@fabula.de writes: > b) access symbols from the module. Is: > > my_symbol = scm_module_lookup(my_module, a_symbol); > > ok? Yes, but note that "my_symbol" is actually a _variable_ that you need to treat with scm_variable_ref, etc. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: scm_* API question 2002-07-31 10:11 ` Marius Vollmer @ 2002-07-31 10:30 ` rm 0 siblings, 0 replies; 22+ messages in thread From: rm @ 2002-07-31 10:30 UTC (permalink / raw) Cc: rm, guile-devel On Wed, Jul 31, 2002 at 12:11:24PM +0200, Marius Vollmer wrote: > rm@fabula.de writes: > > > b) access symbols from the module. Is: > > > > my_symbol = scm_module_lookup(my_module, a_symbol); > > > > ok? > > Yes, but note that "my_symbol" is actually a _variable_ that you need > to treat with scm_variable_ref, etc. Jup, my error log revealed this when i tried to 'call' my_symbol. More on the "use" of all this in a later mail. Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-08-05 18:45 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-07-30 12:14 scm_* API question rm 2002-07-31 1:09 ` Christopher Cramer 2002-07-31 10:03 ` scm_* API extension? [was] " rm 2002-07-31 10:10 ` Marius Vollmer 2002-07-31 18:21 ` rm 2002-07-31 21:59 ` Rob Browning 2002-08-01 10:10 ` rm 2002-08-01 16:51 ` Rob Browning 2002-08-05 15:08 ` Marius Vollmer 2002-08-05 16:06 ` rm 2002-08-05 16:49 ` Marius Vollmer 2002-07-31 20:06 ` Christopher Cramer 2002-07-31 22:14 ` Rob Browning 2002-08-01 9:41 ` rm 2002-08-05 17:51 ` Marius Vollmer 2002-08-05 18:12 ` Han-Wen Nienhuys 2002-08-05 18:45 ` Rob Browning 2002-08-05 18:31 ` Rob Browning 2002-08-05 18:33 ` rm 2002-08-05 15:12 ` Marius Vollmer 2002-07-31 10:11 ` Marius Vollmer 2002-07-31 10:30 ` rm
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).