Thread: [Bigloo-lib-devel] Cooperating on .defs API specifications
Status: Beta
Brought to you by:
wowa
Menu
▾
▴
bigloo-lib-devel
|
From: Andreas R. <a.r...@gm...> - 2004-03-30 17:50:35
|
Hi! [Gauche and Bigloo GTK+ folks CC'ed] I just finished my first pass through the GTK+ .defs, in preparation for making guile-gobject support GNOME 2.6. Due to the huge size of the API, this took me most of today afternoon. I think it would be definitly worth centralizing the maintainance of these files.=20 AFAIK, at least pygtk and guile-gobject use those files. James, how do you feel about maintaining these cooperativly? In the near future (with some luck in the next two weeks) the current guile-gobject "monolith" project will be split up into several pieces, managed in different Arch[0] packages. I think it would be a good idea to have a seperate "defs" package, containing only the .defs files for all (well, all that we already have .defs files for) GNOME APIs. There will be branches for each released GNOME version (starting with 2.6). This means everybody interested will be able to check the "defs" directory out, and plug it somewhere into their project tree, just issuing a "tla update" to stay on track. Also, every project may fork off (no write access or whatsoever required, thanks to Arch) and have their local changes and generic improvements, which can be easily merged back. What about the other Schemes (Bigloo, Gauche) and Common Lisp? How do you currently generate your bindings? Since the .defs files have (simple) Scheme/Lisp syntax, you are obvious candidates for basing your wrappers on them ;-). [0] http://www.gnu.org/software/gnu-arch Regards, Andy --=20 Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.= at http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B= 62 Latein ist das humanoide =C3=84quivalent zu Fortran. -- Alexander Bartolich in at.linux |
|
From: Xavier O. <xor...@wa...> - 2004-03-30 18:47:46
|
On Tue, 2004-03-30 at 19:50, Andreas Rottmann wrote: > Hi! Hi, > This means everybody interested will be able to check the "defs" > directory out, and plug it somewhere into their project tree, just > issuing a "tla update" to stay on track. Also, every project may fork > off (no write access or whatsoever required, thanks to Arch) and have > their local changes and generic improvements, which can be easily > merged back. How do you name your functions ? pygtk binds gtk_tree_view_new as gtk.tree_view_new which slightly changes the function name in our .defs files. How will we set up rules on the generatedn defs files ? I personaly do think having a common set of defs files is a good thing, esp since it'll help keeping up to date with less effort. Regards, Xavier Ordoquy. |
|
From: Owen T. <ot...@re...> - 2004-03-30 20:03:24
|
On Tue, 2004-03-30 at 14:52, Andreas Rottmann wrote: > Owen Taylor <ot...@re...> writes: >=20 > > I think we'd actually open to include .defs with the modules themselves= ; > > the downside being, of course, that you don't get updated defs until > > the module releases a new version. > > > > The other downside is that it is easy for the GTK+ version to get > > out of date if people aren't careful about putting back their changes > > to the canonical version ...=20 > > > I think would be not a good idea, for the reasons you already > mentioned. The thing is: the GTK+ people, (or other module authors), > don't actually use the .defs, only the wrapper people do. IMHO, it > makes much more sense to have them in their own package, maintained by > the people who need them. If the .defs files are supposed to describe the GTK+ (etc.) interfaces, it really seems strange for me to have them maintained independently of GTK+. > > I'm actually pretty interested in exploring the question including > > full method introspection in the binary libraries as discussed recently= ; > > if we could generate that from header file / magic comment parsing > > and not have .defs files at all, I think that would be great. > > > Why not have .defs files, and generate the binary info from them? The > .defs files are already there, and they contain more information than > the headers do (well, comment parsing might change that, but you could > create comments from the .defs files :)). Just an idea... Duplicated information is out-of-date information, in general :-) Regards, Owen |
|
From: Xavier O. <xor...@wa...> - 2004-03-30 20:32:30
|
On Tue, 2004-03-30 at 22:01, Owen Taylor wrote: > If the .defs files are supposed to describe the GTK+ (etc.) interfaces, > it really seems strange for me to have them maintained independently > of GTK+. That's probably because of historical reasons. However, there may also be some specific things among languages but those specific parts could be handled by the language code generator > Why not have .defs files, and generate the binary info from them? The > .defs files are already there, and they contain more information than > the headers do (well, comment parsing might change that, but you could > create comments from the .defs files :)). Just an idea... I would be interested to know what are the informations the .defs file have that the header don't. Maybe a more precise deprecated field, but out of that ? Regards, Xavier Ordoquy. |
|
From: Andreas R. <a.r...@gm...> - 2004-03-30 20:54:48
|
Xavier Ordoquy <xor...@wa...> writes: > On Tue, 2004-03-30 at 22:01, Owen Taylor wrote: >> If the .defs files are supposed to describe the GTK+ (etc.) interfaces, >> it really seems strange for me to have them maintained independently >> of GTK+. > > That's probably because of historical reasons. However, there may also > be some specific things among languages but those specific parts could > be handled by the language code generator > >> Why not have .defs files, and generate the binary info from them? The >> .defs files are already there, and they contain more information than >> the headers do (well, comment parsing might change that, but you could >> create comments from the .defs files :)). Just an idea... > > I would be interested to know what are the informations the .defs file > have that the header don't. Maybe a more precise deprecated field, but > out of that ? > Types of GLists, wether NULL is allowed for pointer values, default argument values, ownership of pointers, out of the top of my head. Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Say NO to Software Patents! -- http://petition.eurolinux.org/ |
|
From: muppet <sc...@as...> - 2004-03-30 21:01:17
|
(huge CC: list trimmed a bit...) Xavier Ordoquy said: > On Tue, 2004-03-30 at 22:01, Owen Taylor wrote: >> Why not have .defs files, and generate the binary info from them? The >> .defs files are already there, and they contain more information than >> the headers do (well, comment parsing might change that, but you could >> create comments from the .defs files :)). Just an idea... > > I would be interested to know what are the informations the .defs file > have that the header don't. Maybe a more precise deprecated field, but > out of that ? Whether NULL is allowed for a parameter, whether a parameter may default and if so what value should be used, whether a parameter is a return value, etc, all of these are described in pygtk's defs files, and i believe in gtkmm's as well. None of that form of info is in the headers; it usually comes from manually digging through source code and documentation. Not that many hours ago i sat here writing about how the API definition need to include *more* metadata of this sort.... see http://lists.gnome.org/archives/language-bindings/2004-March/msg00062.html That thread mentioned switching to a more detailed XML format for the defs. I think that's A Good Idea; binding code generation would simply be an exercise in XSLT. :-) -- muppet <scott at asofyet dot org> |
|
From: Andreas R. <a.r...@gm...> - 2004-03-30 21:41:10
|
"muppet" <sc...@as...> writes: > (huge CC: list trimmed a bit...) > > > Xavier Ordoquy said: >> On Tue, 2004-03-30 at 22:01, Owen Taylor wrote: >>> Why not have .defs files, and generate the binary info from them? The >>> .defs files are already there, and they contain more information than >>> the headers do (well, comment parsing might change that, but you could >>> create comments from the .defs files :)). Just an idea... >> >> I would be interested to know what are the informations the .defs file >> have that the header don't. Maybe a more precise deprecated field, but >> out of that ? > > Whether NULL is allowed for a parameter, whether a parameter may default and > if so what value should be used, whether a parameter is a return value, etc, > all of these are described in pygtk's defs files, and i believe in gtkmm's as > well. None of that form of info is in the headers; it usually comes from > manually digging through source code and documentation. > > Not that many hours ago i sat here writing about how the API definition need > to include *more* metadata of this sort.... see > http://lists.gnome.org/archives/language-bindings/2004-March/msg00062.html > > That thread mentioned switching to a more detailed XML format for > the defs. I think that's A Good Idea; binding code generation would > simply be an exercise in XSLT. :-) > You can express everything you can express as XML in S-Expressions. Especially for Scheme wrappers, those are more convinient than XML ;-) Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.r...@gm... http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Any technology not indistinguishable from magic is insufficiently advanced. -- Terry Pratchett |
|
From: Shiro K. <sh...@la...> - 2004-03-30 22:23:17
|
From: Andreas Rottmann <a.r...@gm...> Subject: Cooperating on .defs API specifications Date: Tue, 30 Mar 2004 19:50:00 +0200 > What about the other Schemes (Bigloo, Gauche) and Common Lisp? How do > you currently generate your bindings? Since the .defs files have > (simple) Scheme/Lisp syntax, you are obvious candidates for basing > your wrappers on them ;-). Gauche-gtk parses gtk header files. I did so just because I couldn't find up-to-date .defs file at the time I started. It'd be the best if .defs comes with each gnome package, i.e. the .defs becomes the autoritative API description. --shiro |
|
From: James H. <ja...@da...> - 2004-03-31 05:00:52
|
On 31/03/2004 3:52 AM, Andreas Rottmann wrote:
>Why not have .defs files, and generate the binary info from them? The
>.defs files are already there, and they contain more information than
>the headers do (well, comment parsing might change that, but you could
>create comments from the .defs files :)). Just an idea...
>
>
For simple cases, the defs files contain enough information. For the
more complex cases, they lack some information that would be needed for
full introspection. Some examples are:
* what types do (GList *) arguments and return values hold? How
should a binding release a (GList *) return value? (in various
parts of GTK and Gnome, the answer is "free all members then the
list", "free the list" and "do nothing")
* Some functions take an array and a length arguments. It would be
good to link these together (for most languages, we should be able
to omit the length arguments, since their list/array types know
their length).
* Is an (int *) argument an array of ints being passed in, an array
of ints that will be modified (inout), or a pointer to a single
int being used as an out argument?
James.
--
Email: ja...@da...
WWW: http://www.daa.com.au/~james/
|
|
From: Andreas R. <a.r...@gm...> - 2004-03-31 10:49:05
|
James Henstridge <ja...@da...> writes:
> On 31/03/2004 3:52 AM, Andreas Rottmann wrote:
>
>>Why not have .defs files, and generate the binary info from them? The
>>.defs files are already there, and they contain more information than
>>the headers do (well, comment parsing might change that, but you could
>>create comments from the .defs files :)). Just an idea...
>>
> For simple cases, the defs files contain enough information. For the
> more complex cases, they lack some information that would be needed
> for full introspection. Some examples are:
>
> * what types do (GList *) arguments and return values hold? How
> should a binding release a (GList *) return value? (in various
> parts of GTK and Gnome, the answer is "free all members then the
> list", "free the list" and "do nothing")
>
In guile-gobject, we use "Glist*-of-FOO" and caller-owns-return to
solve this (well the return value problem only partially). Examples:
(define-method set_popdown_strings
(of-object "GtkCombo")
(c-name "gtk_combo_set_popdown_strings")
(return-type "none")
(parameters
'("GList*-of-gchar*" "strings")
)
)
(define-method copy
(of-object "GtkIconSet")
(c-name "gtk_icon_set_copy")
(return-type "GtkIconSet*")
(caller-owns-return #t)
)
> * Some functions take an array and a length arguments. It would be
> good to link these together (for most languages, we should be able
> to omit the length arguments, since their list/array types know
> their length).
>
Indeed. We could "invent" a new parameter type to describe this.
> * Is an (int *) argument an array of ints being passed in, an array
> of ints that will be modified (inout), or a pointer to a single
> int being used as an out argument?
>
One could add specifiers to those value's type strings,
e.g. int*-in-out.
Andy
--=20
Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.=
at
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B=
62
Latein ist das humanoide =C3=84quivalent zu Fortran.
-- Alexander Bartolich in at.linux
|
Thanks for helping keep SourceForge clean.
X