* Fwd: [g-wrap and guile-gnome/gtk] @ 2000-11-11 9:30 Ariel Rios 2000-11-11 12:11 ` g-wrap and guile-gnome/gtk Marius Vollmer 0 siblings, 1 reply; 9+ messages in thread From: Ariel Rios @ 2000-11-11 9:30 UTC (permalink / raw) To: guile-gtk, Marius Vollmer, Miroslav silovic ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-11 9:30 Fwd: [g-wrap and guile-gnome/gtk] Ariel Rios @ 2000-11-11 12:11 ` Marius Vollmer 2000-11-12 9:02 ` Rob Browning 0 siblings, 1 reply; 9+ messages in thread From: Marius Vollmer @ 2000-11-11 12:11 UTC (permalink / raw) To: Rob Browning, Ariel Rios; +Cc: guile-gtk, Miroslav silovic > 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-11 12:11 ` g-wrap and guile-gnome/gtk Marius Vollmer @ 2000-11-12 9:02 ` Rob Browning 2000-11-12 9:42 ` Michael Livshin ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Rob Browning @ 2000-11-12 9:02 UTC (permalink / raw) To: Marius Vollmer; +Cc: Ariel Rios, guile-gtk, Miroslav silovic 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-12 9:02 ` Rob Browning @ 2000-11-12 9:42 ` Michael Livshin 2000-11-12 11:07 ` Ariel Rios 2000-11-15 6:42 ` Marius Vollmer 2 siblings, 0 replies; 9+ messages in thread From: Michael Livshin @ 2000-11-12 9:42 UTC (permalink / raw) To: Rob Browning; +Cc: Marius Vollmer, Ariel Rios, guile-gtk, Miroslav silovic 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-12 9:02 ` Rob Browning 2000-11-12 9:42 ` Michael Livshin @ 2000-11-12 11:07 ` Ariel Rios 2000-11-12 12:09 ` Rob Browning 2000-11-15 6:42 ` Marius Vollmer 2 siblings, 1 reply; 9+ messages in thread From: Ariel Rios @ 2000-11-12 11:07 UTC (permalink / raw) To: Rob Browning; +Cc: Marius Vollmer, Ariel Rios, guile-gtk, Miroslav silovic 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-12 11:07 ` Ariel Rios @ 2000-11-12 12:09 ` Rob Browning 2000-11-12 12:14 ` Ariel Rios 0 siblings, 1 reply; 9+ messages in thread From: Rob Browning @ 2000-11-12 12:09 UTC (permalink / raw) To: Ariel Rios; +Cc: Marius Vollmer, Ariel Rios, guile-gtk, Miroslav silovic 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-12 12:09 ` Rob Browning @ 2000-11-12 12:14 ` Ariel Rios 2000-11-12 13:54 ` Rob Browning 0 siblings, 1 reply; 9+ messages in thread From: Ariel Rios @ 2000-11-12 12:14 UTC (permalink / raw) To: Rob Browning; +Cc: Marius Vollmer, Ariel Rios, guile-gtk, Miroslav silovic 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-12 12:14 ` Ariel Rios @ 2000-11-12 13:54 ` Rob Browning 0 siblings, 0 replies; 9+ messages in thread From: Rob Browning @ 2000-11-12 13:54 UTC (permalink / raw) To: Ariel Rios Cc: Marius Vollmer, Ariel Rios, guile-gtk, Miroslav silovic, gnucash-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: g-wrap and guile-gnome/gtk 2000-11-12 9:02 ` Rob Browning 2000-11-12 9:42 ` Michael Livshin 2000-11-12 11:07 ` Ariel Rios @ 2000-11-15 6:42 ` Marius Vollmer 2 siblings, 0 replies; 9+ messages in thread From: Marius Vollmer @ 2000-11-15 6:42 UTC (permalink / raw) To: Rob Browning; +Cc: guile-gtk 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-11-15 6:42 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-11 9:30 Fwd: [g-wrap and guile-gnome/gtk] Ariel Rios 2000-11-11 12:11 ` g-wrap and guile-gnome/gtk Marius Vollmer 2000-11-12 9:02 ` Rob Browning 2000-11-12 9:42 ` Michael Livshin 2000-11-12 11:07 ` Ariel Rios 2000-11-12 12:09 ` Rob Browning 2000-11-12 12:14 ` Ariel Rios 2000-11-12 13:54 ` Rob Browning 2000-11-15 6:42 ` Marius Vollmer
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).