Re: Guile/Scheme development

[Bruce Korb]

Brian S McQueen wrote:
> 
> I thought I would mention how I am currently using Guile, and mention a
> Guile project I would like to undertake over the next year.  I think this
> is appropriate because there are probably many, like myself, who have
> found Guile very useful and are putting it to work, though they may not
> have any involvement with the Guile community.  Folks in this category are
> hoping or assuming someone else is maintaining or advancing the core
> libguile technology, because it is a great tool.  We can't all be masters
> of the libguile core.
> 
> If we want Guile to suceed we have to put it to work. An excellent example
> of a guy who is really putting this technology to work is Bruce Korb,
> creator of Autogen http://www.gnu.org/software/autogen/).  From his web
> site you can see he is very productive.

Either very productive, or he's been plugging away at it for a really long time.

>  Recently I revised all the CGI's on my company's web site by adding Guile
> (linking in libguile).  I was able to remove all logic from the CGIs,
> leaving them as a batch of C functions, the order and operation of which
> is specified by external config files written entirely in Scheme.  Now the
> CGIs are very adjustable, but the core is still a batch of high
> performance C executables.
> 
> I also entirely separated the UI of the web site from the logic via Guile.
> The CGIs actually produce only name=value pairs as output.  This output is
> then put into Bruce's tool to produce the output html.  This tool I must
> recommend to you all.

Thanks.  :-)

> The future project I would like to undertake in the next year is to
> produce a version of Autogen which will run as a Server, listening for
> connections, accepting data from clients and returning fully interpolated
> templates.  There are a few different approaches.  I haven't decided which
> way to get there yet.

I think you'll find the simplest would be to fork off a child process
to do the work.  Any other approach will have one of two problems:

1.  memory leaks.  Names of things sometimes get allocated and sometimes
    are passed in and sometimes come from template or definition sources.
    Since these were generally kept until template processing was complete
    and the program then exited, I did little to keep track of which
    needed deallocation.

2.  A development headache of finding and tracking all these little allocations.
    This might be accomplished with wrappers around the collection of
    allocation and deallocation routines, but chasing all that stuff down
    doesn't look like a pleasant task to me.  Even less pleasant if there
    are some allocations that really do need to be permanent.

All in all, I'd say just fork a child and let process management clean up.