Fwd: [g-wrap and guile-gnome/gtk]

Fwd: [g-wrap and guile-gnome/gtk]

[Ariel Rios]

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

Re: g-wrap and guile-gnome/gtk

[Marius Vollmer]

> From: Rob Browning <rlb@cs.utexas.edu>
> Subject: g-wrap and guile-gnome/gtk
> To: Ariel Rios <jarios@usa.net>
> Date: 02 Nov 2000 13:28:49 -0600
> 
> 
> What I'm wondering is if we ought to at least discuss whether or not
> we could collaborate on a common solution.  Right now I think your
> solution has a few things g-wrap doesn't and vice-versa.

If I remember correctly, build-guile-gtk is actually derived from a
early version of g-wrap.  I quickly decided to `roll my own' because
that was easy to do and I didn't know what I wanted precisely.

Build-guile-gtk is still a one-off hack and needs to be redone
completely to make it reasonably clean.  This includes the syntax of
the defs files themselves, but hopefully we can clean that up in a
backward compatible way because they are already defs files out there
that are distributed independently from guile-gtk.

Working towards g-wrap would be the right thing, this time.

Because g-wrap def files are just Scheme code, I think we should start
by trying to write implementations for define-object, define-func etc
in terms of the normal g-wrap features.  A *.defs file could then
start like this

    (use-modules (gtk g-wrap-defs))

    (define-object GtkObject
      (fields ...))

or build-guile-gtk could be a thin wrapper that invokes g-wrap in the
right way.

Does that make sense?

Re: g-wrap and guile-gnome/gtk

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> If I remember correctly, build-guile-gtk is actually derived from a
> early version of g-wrap.  I quickly decided to `roll my own' because
> that was easy to do and I didn't know what I wanted precisely.

Ahh.  That makes sense.

> Build-guile-gtk is still a one-off hack and needs to be redone
> completely to make it reasonably clean.  This includes the syntax of
> the defs files themselves, but hopefully we can clean that up in a
> backward compatible way because they are already defs files out there
> that are distributed independently from guile-gtk.

Well, since everything's just scheme forms, and since the .defs files
aren't even allowed to be general scheme syntax, this should be easy.
We could probably even just write a translator script that was nothing
more than a set of guile macros that rewrote and "displayed" their
contents as g-wrap specs.

> Working towards g-wrap would be the right thing, this time.

Well, I want to make it clear that I'm not hung up on g-wrap as it is.
If we need to change things, or even if we decide that we need to work
on some other common effort, it sounds to me like a joint solution
would benefit everyone.

Also, g-wrap's pretty good, but I think it could use some cleaning up.
I need to rewrite some of the internals to be clearer now Christopher
Lee and I have agreed that guile will be the only implementation
language (not the only target language).  In the past g-wrap was
implemented in both rscheme and guile, and that required some
complexities that are now irrelevant...

> Because g-wrap def files are just Scheme code, I think we should start
> by trying to write implementations for define-object, define-func etc
> in terms of the normal g-wrap features.  A *.defs file could then
> start like this
> 
>     (use-modules (gtk g-wrap-defs))
> 
>     (define-object GtkObject
>       (fields ...))
> 
> or build-guile-gtk could be a thin wrapper that invokes g-wrap in the
> right way.
> 
> Does that make sense?

Perfect sense.  One thing we might want to decide is if it's OK that
the API spec files are just scheme code.  G-wrap handles it that way
right now, but that could be changed.  Allowing arbitrary scheme code
does have its advantages since it's really easy to do things like
conditional inclusion, and other things you haven't thought of, and so
I tend to favor it, but it also has its weaknesses (like making it
harder to spot and flag syntax errors), so I'd certainly be willing to
consider the issue.

Also, it might be easier to maintain in the long run to just create a
simple .defs -> .gwp translator script than to support two syntaxes in
the front end.  This might be a good approach across the board.  Who
knows, one day we might even be able to "steal" specs from other
places by creating other translators.

Also, I think that as soon as I finish incorporating Robert Merkel's
new patch, which adds C enum support to g-wrap, g-wrap may be a
functional superset of what the .defs can do, though I'm not
absolutely sure of that.  I know that the way he handles enums is more
flexible, if a little more complex (for example, we designed it so
that you can use enums as either symbols or integers from the Scheme
side).  I should be finished incorporating that patch in a day or so.

Also, if all goes well, I might even be able to get the dlopen loading
working by then, so whta you'd be able to say things like:

  (use-modules (gwp opengl))
  (use-modules (gwp curses))

and have the thing you think would be cool to have happen, actually
happen :>  We'll see...

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: g-wrap and guile-gnome/gtk

[Michael Livshin]

Rob Browning <rlb@cs.utexas.edu> writes:

> Well, since everything's just scheme forms, and since the .defs files
> aren't even allowed to be general scheme syntax, this should be easy.
> We could probably even just write a translator script that was nothing
> more than a set of guile macros that rewrote and "displayed" their
> contents as g-wrap specs.

note that the .defs files are apparently supposed to become the
standard way to specify the bindable interface of the various
Gnome-affiliated C libraries.  i.e. they are not just for Guile
anymore.  so .defs -> .gwp translation approach seems like a very
sensible idea to me, whatever way you happen to implement it.

-- 
All ITS machines now have hardware for a new machine instruction --
CIZ
Clear If Zero.
Please update your programs.

Re: g-wrap and guile-gnome/gtk

[Ariel Rios]

On 12 Nov 2000, Rob Browning wrote:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> 
> > Build-guile-gtk is still a one-off hack and needs to be redone
> > completely to make it reasonably clean.  This includes the syntax of
> > the defs files themselves, but hopefully we can clean that up in a
> > backward compatible way because they are already defs files out there
> > that are distributed independently from guile-gtk.
There is a new spec file format that was created for general use.
The document is located somewhere in the GTK+ module. It is important
that g-wrap works with these new format. I think that in the case
of Guile-gtk / Gnome-guile we do want to keep using these format.
 
> Well, I want to make it clear that I'm not hung up on g-wrap as it is.
> If we need to change things, or even if we decide that we need to work
> on some other common effort, it sounds to me like a joint solution
> would benefit everyone.
I am especially interested in knowing how fast do libraries
binded using g-wrap is.
 
> 
> Perfect sense.  One thing we might want to decide is if it's OK that
> the API spec files are just scheme code.  G-wrap handles it that way
> right now, but that could be changed.  
We can even have some macros to deal with the defs file if necessary...

ariel

Re: g-wrap and guile-gnome/gtk

[Rob Browning]

Ariel Rios <ariel@arcavia.com> writes:

> > Well, I want to make it clear that I'm not hung up on g-wrap as it is.
> > If we need to change things, or even if we decide that we need to work
> > on some other common effort, it sounds to me like a joint solution
> > would benefit everyone.
>
> I am especially interested in knowing how fast do libraries
> binded using g-wrap is.

Well, since Marius told me that guile-{gtk,gnome} is basically using
an earlier version of g-wrap's guts, I'd guess, since I don't think
I've really changed anything performance related, that the performance
should be roughly equivalent.

> We can even have some macros to deal with the defs file if necessary...

Right.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: g-wrap and guile-gnome/gtk

[Ariel Rios]

On 12 Nov 2000, Rob Browning wrote:

> Well, since Marius told me that guile-{gtk,gnome} is basically using
> an earlier version of g-wrap's guts, I'd guess, since I don't think
> I've really changed anything performance related, that the performance
> should be roughly equivalent.
If there is a way of having a performance icnrease it would be
even better ;) I am interested in doing the Corba /ORBit bindings
using g-wrap or whatever new schema we came up with

ariel
 

Re: g-wrap and guile-gnome/gtk

[Rob Browning]

Ariel Rios <ariel@arcavia.com> writes:

> If there is a way of having a performance icnrease it would be even
> better ;) I am interested in doing the Corba /ORBit bindings using
> g-wrap or whatever new schema we came up with

Well, I think we can probably separate this into two issues.

  1) What should an API spec look like (say for gtk, glib, opengl,
     curses, etc.).

  2) How should the implementation work?  (i.e. we can potentially
     change that for performance later in any way we like without
     having to change the spec).

Also, after noticing the in, out, inout, arg bits of your latest .defs
proposal, it looks like it's somewhat mirroring other IDLs (of which,
I'm only really passingly familiar with ILU).

One thing I've wondered about for a while now is whether or not it
might make sense to mirror (in scheme forms) the semantics of one of
the IDLs (CORBA being the biggest elephant on the block).

However, on the other side of that fence, I also wonder, whether or
not there might be a legitimate place for a tool (and perhaps g-wrap
should be that tool), that's exclusively focused on providing very
well integrated, efficient, and clear (both in specification and in
execution) bindings for C APIs from guile.  Basically the question
comes down to "Is it possible in this case to server all masters
well?".

Or in more concrete terms, say I were to try to do something very
CORBA-esque with g-wrap's spec.  Would I end up with a tool that was
much more complex, harder to implement and understand, and didn't
really provide any substantial improvments as compared to a tool
that's specifically aimed at just the guile<->C API problem?

I don't really know, and I'd love to hear arguments either way.  To a
substantial extent, I'm not the best person to evaluate this argument,
since I have little or no experience with CORBA, though I've done
plenty of DO/RPC related work.

Thanks
-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: g-wrap and guile-gnome/gtk

[Marius Vollmer]

Rob Browning <rlb@cs.utexas.edu> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > Build-guile-gtk is still a one-off hack and needs to be redone
> > completely to make it reasonably clean.  This includes the syntax
> > of the defs files themselves, but hopefully we can clean that up
> > in a backward compatible way because they are already defs files
> > out there that are distributed independently from guile-gtk.
> 
> Well, since everything's just scheme forms, and since the .defs
> files aren't even allowed to be general scheme syntax, this should
> be easy.  We could probably even just write a translator script that
> was nothing more than a set of guile macros that rewrote and
> "displayed" their contents as g-wrap specs.

Hmm, I'm more leaning towards keeping the existing syntax of the defs
files and using g-wrap as a back-end.  The defs file syntax is quite
specialized and not really general but that's actually a feature, I
think.  With a specialized syntax, tzhere is less opportunity for
making mistakes and it's easier for people to add their own things
confidently.  And when a defs file is just Scheme code, people can
> always fall back to the g-wrap features when the need arises.

> One thing we might want to decide is if it's OK that the API spec
> files are just scheme code.

Yes, I think that's the right thing.

> G-wrap handles it that way right now, but that could be changed.
> Allowing arbitrary scheme code does have its advantages since it's
> really easy to do things like conditional inclusion, and other
> things you haven't thought of, and so I tend to favor it, but it
> also has its weaknesses (like making it harder to spot and flag
> syntax errors), so I'd certainly be willing to consider the issue.

Reporting errors is a challange, but I think we can make that work.
Maybe Guile needs to be changed a bit, but this problem should be
quite general.  For example, I have a simulator that uses Scheme as
its description language and I want to report errors in user code in a
nice way.  I found a way to make this work, but it could be improved
with support from Guile itself.