scm_* API question

scm_* API question

[rm]

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

Re: scm_* API question

[Christopher Cramer]

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

scm_* API extension? [was] scm_* API question

[rm]

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

Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer]

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

Re: scm_* API extension? [was] scm_* API question

[rm]

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

Re: scm_* API extension? [was] scm_* API question

[Rob Browning]

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

Re: scm_* API extension? [was] scm_* API question

[rm]

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

Re: scm_* API extension? [was] scm_* API question

[Rob Browning]

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

Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer]

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

Re: scm_* API extension? [was] scm_* API question

[rm]

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

Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer]

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

Re: scm_* API extension? [was] scm_* API question

[Christopher Cramer]

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

Re: scm_* API extension? [was] scm_* API question

[Rob Browning]

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

Re: scm_* API extension? [was] scm_* API question

[rm]

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

Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer]

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

Re: scm_* API extension? [was] scm_* API question

[Han-Wen Nienhuys]

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

Re: scm_* API extension? [was] scm_* API question

[Rob Browning]

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

Re: scm_* API extension? [was] scm_* API question

[Rob Browning]

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

Re: scm_* API extension? [was] scm_* API question

[rm]

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

Re: scm_* API extension? [was] scm_* API question

[Marius Vollmer]

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

Re: scm_* API question

[Marius Vollmer]

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

Re: scm_* API question

[rm]

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