guile as extension language

guile as extension language

[Matthew R Wette]

How is Guile intended to be used as an extension language?

Some extension languages like Perl can be fed commands from the main
application.  I believe the Apache Perl module works this way.

Other extension languages can not be run this way and need to execute
in a separate process, typically communicating via a socket
connection.  I believe the Apache Java servlet modules work this way.

I just read through the Guile 1.5.6 code and it seems that Guile
cannot be fed commands from a parent application like the first case
above.  If you want to use Guile as an *extension* language you need
to run it in a separate process and talk via sockets.  For example, if
I wanted to generate a Guile Apache module it seems I would need to do
it this way.  Is this correct?  

Matt



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile as extension language

[Matthew R Wette]

Matthew R Wette writes ...
> 
> How is Guile intended to be used as an extension language?
> 
> Some extension languages like Perl can be fed commands from the main
> application.  I believe the Apache Perl module works this way.
> 
> Other extension languages can not be run this way and need to execute
> in a separate process, typically communicating via a socket
> connection.  I believe the Apache Java servlet modules work this way.
> 
> I just read through the Guile 1.5.6 code and it seems that Guile
> cannot be fed commands from a parent application like the first case
> above.  If you want to use Guile as an *extension* language you need
> to run it in a separate process and talk via sockets.  For example, if
> I wanted to generate a Guile Apache module it seems I would need to do
> it this way.  Is this correct?  

By the way, I noticed that The GIMP uses a separate process
to run script-fu.

My interest here was in exploring the scope of work required to
make a Guile extension for Dia (the gnome graphics app).

Matt

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile as extension language

[Paul Emsley]

On Sun, 2002-04-07 at 00:47, Matthew R Wette wrote:
> Matthew R Wette writes ...
> > 
> > How is Guile intended to be used as an extension language?
> > 
> My interest here was in exploring the scope of work required to
> make a Guile extension for Dia (the gnome graphics app).
> 

This is not a reply really, more of a me-too.

I have recently written a program in C/C++ using gtk [1] and now want to
type a script (say) (or commands) at the console/terminal.  I would like
this to be interpreted by guile but cannot see how since gtk has the
control passed completely to it using gtk_main().  

Is scm_init_guile() really the way to do it?  I got the impression that
it was not, if I wanted portability (and I do).

I initially thought that that guile + gtk (not guile-gtk) would be
common combination and tried to find examples to see how they did it,
but I could not.  Can you recommend anything?

I thought that converting to guile-gtk, but since I was using glade and
gtkglarea, I was a bit nervous about doing that.  Should I have been?

Thanks, 

Paul.


[1] actually it does some sort of molecular graphics, I wrote about
something like it a few months ago.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile as extension language

[Brett Viren]

I am sure the experts will say more, but as a simple user I can say
that you can indeed embed (lib)guile into your executable w/out the
need to talk to the guile executable via sockets (ick!).

There are 2 ends of a spectrum in how you can embed guile.  On one
end, you can do everything in scheme and call scheme wrapped versions
of your library's functions.  On the other, you can do everything in
C/C++ and call into scheme either by passing strings of scheme code to
guile or via guile's scm_ C functions using "SCM" objects.

I have written both type of applications and both models are easy to
develop.  However, since dia's main loop is under GTK+'s control, you
will likely tend toward the former.

BTW, I think it would be way cool to extend dia with guile.  Do you
intend to use scheme as an output format instead of the current XML,
or just use it for run time extension, a'la emacs?

Regards,
-Brett.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile as extension language

[Neil Jerram]

>>>>> "Matthew" == Matthew R Wette <mwette@grover.jpl.nasa.gov> writes:

    Matthew> Matthew R Wette writes ...
    >> 
    >> How is Guile intended to be used as an extension language?
    >> 
    >> Some extension languages like Perl can be fed commands from the main
    >> application.  I believe the Apache Perl module works this way.
    >> 
    >> Other extension languages can not be run this way and need to execute
    >> in a separate process, typically communicating via a socket
    >> connection.  I believe the Apache Java servlet modules work this way.
    >> 
    >> I just read through the Guile 1.5.6 code and it seems that Guile
    >> cannot be fed commands from a parent application like the first case
    >> above.  If you want to use Guile as an *extension* language you need
    >> to run it in a separate process and talk via sockets.  For example, if
    >> I wanted to generate a Guile Apache module it seems I would need to do
    >> it this way.  Is this correct?  

    Matthew> By the way, I noticed that The GIMP uses a separate process
    Matthew> to run script-fu.

    Matthew> My interest here was in exploring the scope of work required to
    Matthew> make a Guile extension for Dia (the gnome graphics app).

Good question!  There's the beginnings of an attempt to explain this
in the reference manual, in the node `Programming Options', but
currently it's pretty sparse, so let's see ...

What are the constituents of the Dia application?

- Most importantly, the `application domain objects' - i.e. shapes,
  templates, connectors, pages, plus the properties of all these
  things.

- The code that manages the graphical face of the application,
  including the layout of the objects above.

- The code that handles input events, which indicate that the
  application user is wanting to do something.

(I guess I could've just said `model - view - controller'.)

So, what do you see Guile being able to do for you once you've
incorporated it (in a way yet to be determined)?  I don't know what
you envisage, but my guess is that you're mostly thinking of being
able to manipulate the application domain objects from Scheme.  For
example:

    (for-each-shape current-page
      (lambda (shape)
        (if (square? shape)
            (change-fill-pattern shape diagonal-hatch))))

Assuming that this is the objective, two kinds of thing are needed to
achieve it:

1. You need to write code for "primitives" like `for-each-shape' and
   `shape' such that they access and manipulate your existing data
   structures correctly, and then make these "primitives" available on
   the Scheme level.

2. You need to provide some kind of hook from Dia's main loop that a
   user can use to cause arbitrary Scheme code to be evaluated.

2 is pretty easy, you just have to decide on a mechanism.  Compare
Emacs, for example: when I type `ESC :', I get a prompt where I can
type in any Elisp code, which Emacs will then evaluate.  Or, again
like Emacs, you could provide a mechanism to allow Scheme code to be
bound to a particular key sequence, and evaluate the code when that
key sequence is entered.  Once you have the code that you want to
evaluate, as a null terminated string, you can evaluate it by calling
the `scm_c_eval_string' function.

1 is harder because, for all but the most trivial applications, you
will probably want to allow some representation of your domain objects
to exist on the Scheme level.  This is where the idea of SMOBs comes
in, and with it issues of lifetime management and garbage collection.

To get more concrete about this, consider `shape' in the sample code
above.  For each shape on the current page, the `for-each-shape'
primitive calls `(lambda (shape) ...)' with an argument representing
that shape.  Question is: how is that argument represented on the
Scheme level?  The issues are:

- Whatever the representation, it has to be decodable again by the C
  code for the `square?' and `change-fill-pattern' primitives.

- What happens if the Scheme code stores `shape' in a global variable,
  then that shape is deleted, and later on some other Scheme code
  uses that global variable in a call to, say, `square?' ?

Generally speaking, the answer is something like this:

- Create a structure that wraps the underlying C structure together
  with a status field indicating whether than underlying structure is
  still valid or not:

struct dia_guile_shape
{
  int c_shape_status;       /* 0=dead, 1=alive */
  struct dia_shape * c_shape;
}

- Add a field in `struct dia_shape' that points to its `struct
  dia_guile_shape' if it has one, so that C code can update the
  c_shape_status field when the underlying shape is deleted.

- Turn `struct dia_guile_shape' into a SMOB type - see node `Defining
  New Types (Smobs)' in the reference manual.

- Whenever you need to represent a C shape onto the Scheme level,
  create a SMOB instance for it, and pass that.

- In primitive code that receives a shape SMOB instance, check the
  c_shape_status field when decoding it, to find out whether the
  underlying C shape is still there.

Once these details of object representation are decided, writing the
rest of the primitive function code should be pretty straightforward.
All that then remains is to export the primitives to Scheme by calling
the `scm_c_define_gsubr' function.

Finally, what does the overall structure look like?

Assuming that Dia currently looks like this:

- main ()
  - do lots of initialization and setup stuff
  - enter Gtk main loop

the simplest thing is to change it to look like this:

- main ()
  - do lots of initialization and setup stuff
  - scm_boot_guile (argc, argv, inner_main, NULL)

- inner_main ()
  - define all SMOB types
  - export primitives to Scheme using scm_c_define_gsubr
  - enter Gtk main loop

OK, there's lots more that one could say, but let me know if this is
any help so far.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile as extension language

[Neil Jerram]

>>>>> "Paul" == Paul Emsley <paule@chem.gla.ac.uk> writes:

    Paul> On Sun, 2002-04-07 at 00:47, Matthew R Wette wrote:
    >> Matthew R Wette writes ...
    >> > 
    >> > How is Guile intended to be used as an extension language?
    >> > 
    >> My interest here was in exploring the scope of work required to
    >> make a Guile extension for Dia (the gnome graphics app).
    >> 

    Paul> This is not a reply really, more of a me-too.

I've replied separately to Matthew's question, and most of what I say
there should apply to your case as well, when it comes to deciding
what you want your script to be able to control, and how to achieve that.

Which just leaves ...

    Paul> I have recently written a program in C/C++ using gtk [1] and now want to
    Paul> type a script (say) (or commands) at the console/terminal.  I would like
    Paul> this to be interpreted by guile but cannot see how since gtk has the
    Paul> control passed completely to it using gtk_main().  

This question keeps cropping up, so this time I'll try my best to give
a definitive answer.

1. Do you really want this I/O at the console?  You could choose
   instead to use a GtkEntry widget for typing in, and a GtkText for
   the output, and include these widgets in your overall GUI.  Then
   everything would be under the control of gtk_main(), so you avoid
   the main issue.

   If you followed this route, the basic mechanism for getting
   commands evaluated would be to add an "activate" signal handler to
   the GtkEntry widget that calls scm_c_eval_string to evaluate the
   line of input in the widget.

2. If you definitely want I/O at the console, you can use gtk_idle_add
   to register a function that gtk_main should call when nothing is
   happening in the GUI.  The function that you register should

   - do a non-blocking select on standard input to find whether
     there's anything to read

   - read characters 1 at a time into an input buffer

   - when newline is read, call scm_c_eval_string to evaluate the
     buffered input.

3. However, both the above are suboptimal for two main reasons:

   3.1. They only work if the expression entered on a line is always
        balanced.

   3.2. They don't support the reading of input that is not meant to
        be evaluated, or that should be evaluated in a different way.
        (e.g. input for the Guile debugger).

   What you really want, IMO, to overcome these issues, is for the
   GtkEntry widget (case 1) or the console (case 2) to act like input
   ports with two properties:

   - From the point of view of code like `(top-repl)' (which
     implements the standard Guile REPL), they can be used as input
     ports just like any others.

   - But, whenever there isn't any immediate input available, they
     call gtk_main.

   The good news is that Scheme continuations make it possible to do
   exactly this!  Suppose in C that you

   - define and export a Scheme primitive `call-gtk-main', which just
     calls gtk_main

   - define and export a Scheme primitive `store-continuation', which
     saves its continuation argument in a global variable

   - write a Gtk idle function `check_stdin', which checks for input
     available on standard input and, if there is any, calls the
     continuation stored above

   - use gtk_idle_add to register this idle function with gtk_main.

   Now you can make a soft input port with this read-char procedure:

       (lambda ()
         (call-with-current-continuation
           (lambda (cont)
             (store-continuation cont)
             (call-gtk-main)))
         (read-char standard-input))

   (This is for case 2.  For case 1 you need something a bit trickier,
   where the continuation is called from the "activate" handler, and
   the read-char procedure uses an input buffer.)

   Finally, to get everything rolling, you need to

   - do all your usual application initialization

   - define the soft port as shown above, and call it, say,
     `soft-port'

   - evaluate `(set-current-input-port soft-port)'

   - evaluate `(top-repl)'.

   (Probably the last 3 steps are most conveniently achieved by
   loading a Scheme file.)

For a working example of approach 3, using guile-gtk and the GtkEntry
widget, you might like to grab my guile-gui distro from
http://www.ossau.uklinux.net/guile.

    Paul> Is scm_init_guile() really the way to do it?  I got the impression that
    Paul> it was not, if I wanted portability (and I do).

scm_init_guile is mostly a red herring.  Since you have control of
your source code's main function, you can just as easily do the
scm_boot_guile structure:

- main ()
  - scm_boot_guile (..., inner_main, ...)

- inner_main ()
  - rest of application

as the scm_init_guile structure:

- main ()
  - scm_init_guile ()
  - rest of application

It may be true that scm_init_guile is marginally less portable; I
don't know for sure.

(scm_init_guile is designed for libraries that don't have access to
main().)

    Paul> I initially thought that that guile + gtk (not guile-gtk) would be
    Paul> common combination and tried to find examples to see how they did it,
    Paul> but I could not.  Can you recommend anything?

Bill Schottstaedt has previously posted examples using both Motif and
Gtk, and Ariel Rios has written a `GuileRepl' widget using Gtk.  All
of these are examples of case 1 above.  I'd guess that Bill's example
is available in the Snd source, and Ariel's in Gnome CVS.

    Paul> I thought that converting to guile-gtk, but since I was using glade and
    Paul> gtkglarea, I was a bit nervous about doing that.  Should I have been?

Suggest looking at guile-gtk (and perhaps also my guile-gui) to see
what guile-gtk can do for you.  Given that you're already using glade,
it might be that the only thing of use to you would be calling
`gtk-main' from Scheme instead of `gtk_main' from C - i.e. not much
difference!

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile as extension language

[Bill Schottstaedt]

> Bill Schottstaedt has previously posted examples using both Motif and
> Gtk, and Ariel Rios has written a `GuileRepl' widget using Gtk.  All
> of these are examples of case 1 above.  I'd guess that Bill's example
> is available in the Snd source, and Ariel's in Gnome CVS.

Snd is available via:

  ftp://ccrma-ftp.stanford.edu/pub/Lisp/snd-5.tar.gz
  http://www-ccrma.stanford.edu/software/snd/
  http://sourceforge.net/projects/snd/

It makes extensive use of Guile as an extension language, and has a
"listener" (a sort of shell-like text entry widget to accept and
edit scheme code).  I haven't had time recently to keep up with
Gtk changes, so I'd recommend trying the Motif version; there are
prebuilt images for Linux, Sun, and Mac OSX at ccrma-ftp.
The GUI extensions are based on xm.c (X/Xt/Xm) or xg.c (glib/gdk/gtk) --
there are examples in the documentation, and very extensive
examples in the scheme code included in the Snd tarball.
I think you can see screen shots of the Motif extensions in:

  http://linux.oreillynet.com/pub/a/linux/2001/10/05/snd_partone.html
  http://linux.oreillynet.com/pub/a/linux/2001/10/18/snd_parttwo.html


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

HELP: crash while using Guile on a Win32 multithreaded development context

[Daniel CAUNE]

Hi, 

I'm encountering some problems with a development at home of a small
server application in C++ using the Guile dynamic libraries for the
Windows platform, included in the file guile-1.4.zip downloaded from
http://www.textsure.net/~ela/download/. 

One of my application's thread dynamically loads the Guile library
(dynamic binding) and calls the gh_enter function (i.e. scm_boot_guile)
to initialize the Scheme interpreter, and then... all the application's
process shutdowns brutally! I was a bit confused, so I've developped a
mono-threaded application to test this Guile library (static binding),
and it rocks!

So I've trie to investigate further, debugging the assembly code of the
Guile library called by my server application code (this library doesn't
include debug information, but I get the Guile source files from GNU web
site), and trying to understand where it sucks.

I've followed my instruction pointer until the scm_internal_lazy_catch
code (throw.c) where I lost it, my baby crying and asking for her milk
in the darkness of the night... Return to the reallity! I'll certainly
continue my quest tonight, but I would prefer that a valiant knight, or
a magician, gives here the exact reason of my trouble, if he've already
encountered it.

Thanks!


Daniel 

________________________________________ 
"Thuong nhau qua, can nhau dau..." 



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user