Thread: [java-gnome-hackers] Rewrite of Code generator using GIR
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
From: Serkan K. <se...@ge...> - 2010-05-10 07:48:14
|
Currently we're using defs file from pygobject which is generated by h2def, and manually adding new symbols along the way. We also generate or handcraft some defs files ourselves and add them into the tree. And the code generator parses them to generate user invisible class files and JNI code. This causes out-of-date symbol metadata since the work is done manually. For a bit of time GNOME project is prividing a package called Gobject introspection, which basically holds interface definitions of GObject based libraries. They're still generated from scanning source code, but done by the library providers themselves and kept up-to-date. GNOME also provides a central GIR metadata in "gir-repository" package for libraries that don't provide them (eventually libraries end up supporting GIR) I started rewrite of parser part of the code generator using .gir XML files (parsing them was easier otherwise we would need to write JNI code for GIRepository). The branch is at bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/introspection/ Please pull and investigate it because this branch is changing a core part of Java-Gnome Future considerations * How to handle manualy fixes we do for .defs files * How to provide unexisting GIR files (we may use the scanner to generate them and get them included in "gir-repository") Regards, Serkan KABA |
|
From: Serkan K. <se...@ge...> - 2010-05-24 17:07:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-05-2010 10:48, Serkan Kaba wrote: > Currently we're using defs file from pygobject which is generated by > h2def, and manually adding new symbols along the way. We also generate > or handcraft some defs files ourselves and add them into the tree. And > the code generator parses them to generate user invisible class files > and JNI code. This causes out-of-date symbol metadata since the work > is done manually. > > For a bit of time GNOME project is prividing a package called Gobject > introspection, which basically holds interface definitions of GObject > based libraries. They're still generated from scanning source code, > but done by the library providers themselves and kept up-to-date. > GNOME also provides a central GIR metadata in "gir-repository" package > for libraries that don't provide them (eventually libraries end up > supporting GIR) > > I started rewrite of parser part of the code generator using .gir XML > files (parsing them was easier otherwise we would need to write JNI > code for GIRepository). The branch is at > bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/introspection/ > Please pull and investigate it because this branch is changing a core > part of Java-Gnome > > Future considerations > * How to handle manualy fixes we do for .defs files > * How to provide unexisting GIR files (we may use the scanner to > generate them and get them included in "gir-repository") > > Regards, > Serkan KABA > > ------------------------------------------------------------------------------ > > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > I started the alternative implementation based on handwritten binding around GIR and pushed it to bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/gir/ the code is at tests/exploration/gir-java - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkv6sj0ACgkQRh6X64ivZaLuvwCXWzPGgJ251YcGOTVqJEx1yRBq /wCeNLYZ510ulW6mYF3iS5z/LAJ7ryA= =vhoB -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-06-01 02:25:38
Attachments:
java-gnome_20100530.txt
java-gnome_20100530.txt.sig
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We had a planned meeting with Andrew on 30th of May, and it was a fruitful meeting discussing the current state and the future direction of GIR work. I'm pasting the IRC logs of the meeting (all timestamps are UTC+3) - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwEb5QACgkQRh6X64ivZaLtbACfcGKefla4X+TYfMPkpJyVl9wk quIAn2z7dim0ER9I1thRpkgpAr+w/yGw =3Rul -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-09-19 21:54:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's my blog post on current status. http://skaba.wordpress.com/2010/09/20/status-of-gobject-introspection-for-java-gnome/ Regards, Serkan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyWhnYACgkQRh6X64ivZaKzzwCfWrr7W51kz92TmjXlsoeARYEd rI4An2WwYFelGjs7O42IWMANVlSAW5sm =Ekis -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-09-25 08:41:29
Attachments:
name-overriding.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While running the generator, I discovered that we didn't use some of the underlying type names in favor of more meaningful ones. I tried the following patch and it works? So do you think it's hacky or not acceptable? Or is it OK? - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkydta0ACgkQRh6X64ivZaJAbwCfd5F5Kit0Rqq/G507xv6egRWn U9gAnR7sNiEYeQE2ZTRXNSRQC2+JkPhZ =MYSF -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-10-02 03:08:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20-09-2010 00:53, Serkan Kaba wrote: I tried cleaning up defs files in Gdk, GdkPixbuf and Gtk namespaces (with the exception of ones where we need to keep as an override) and modified the parser to override DefsFile's created from gir in block level. Most of the problems I'm getting are caused by GdkBitmap (Bitmap) and GdkPixbufFormat (PixbufFormat), running boxedFor/fillBoxedArray with them and duplicate methods generated by accessors (when the boxed has both a field and an accessor method with the same name) Can anybody help me debug the first issue, I'm stuck :( - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkymog4ACgkQRh6X64ivZaIJnQCfR9GUm9xIOLWx+XPt54d1gDp4 91AAnj0e1JOCvTscgKvCNS0XTuxXwOG2 =of9X -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-10-02 03:09:59
Attachments:
defscleanup.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forgot attaching the patch, here it is. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkymol0ACgkQRh6X64ivZaIETQCfZN+aJV7V4cQVQ4bo3ZMUzA/2 kP4AoIEd5TT59q9u5z/Wawf/5AUyMpmX =YzSn -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2010-10-02 20:41:21
|
On Sat, 2010-10-02 at 06:09 +0300, Serkan Kaba wrote: > Forgot attaching the patch, here it is. This isn't a bundle, so we can't create a Bazaar branch from it. Do you have this uploaded somewhere? AfC Kingston |
|
From: Serkan K. <se...@ge...> - 2010-10-03 06:32:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02-10-2010 20:13, Andrew Cowie wrote: > On Sat, 2010-10-02 at 06:09 +0300, Serkan Kaba wrote: >> Forgot attaching the patch, here it is. > > This isn't a bundle, so we can't create a Bazaar branch from it. Do you > have this uploaded somewhere? Here's a bundle against mainline, which I didn't update lately due to being stuck at glib-2.22 - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyoI3kACgkQRh6X64ivZaLjpwCfaZIv0Q3V4c4vP7K4QTaDUM+i IMYAnR7TREWA+AOzD7zN5gHBI1s36k4l =VDGO -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-10-03 11:22:51
Attachments:
gir-defscleanup.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkyoZ0IACgkQRh6X64ivZaJw+gCVHvZNPu6VpEPMLtqcRkRlVp8j dQCfYr2o1+JmaYA3UON5iNHUFxyQZeY= =zGD2 -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2010-10-06 17:18:58
|
On Sun, 2010-10-03 at 09:32 +0300, Serkan Kaba wrote: > >> Forgot attaching the patch, here it is. > > > > This isn't a bundle, so we can't create a Bazaar branch from it. Do you > > have this uploaded somewhere? > Here's a bundle Hm. So something seems to have gone way off the rails here. Your bundle removes a ton of .defs files [which makes me nervous, because lots of those files contain a lot of improvements like which classes are deprecated and return types and occasional customizations that were necessary to make java-gnome work at all] but fine, and then, it introduces a huge number of public stubs. Ok, new types, great! Until I noticed you adding org.gnome.gtk.CList. What! That's been deprecated since GTK 1.2; java-gnome goes to a lot of trouble to not expose things like that. There are quite a number of other things there that are longs since discarded. As you know, we've spent a lot of effort over the past 4 years trying to make our public API clean and not present meaningless or obsolete classes. I'm not sure what you doing that required you to add stubs for all these types, but clearly we should not be generating code for them. I assume what happened is that you just ran the generator and produced code for everything ever in GTK. I'm not sure where to go from here. AfC Montreal |
|
From: Serkan K. <se...@ge...> - 2010-10-06 18:59:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06-10-2010 20:18, Andrew Cowie wrote: > So something seems to have gone way off the rails here. Your bundle > removes a ton of .defs files [which makes me nervous, because lots of > those files contain a lot of improvements like which classes are > deprecated and return types and occasional customizations that were > necessary to make java-gnome work at all] but fine, The ultimate purpose is to determine what custimizations we did, and resurrect needed blocks, that's why I didn't commit this in the gir branch. > > and then, it introduces a huge number of public stubs. Ok, new types, > great! Until I noticed you adding org.gnome.gtk.CList. What! > > That's been deprecated since GTK 1.2; java-gnome goes to a lot of > trouble to not expose things like that. There are quite a number of > other things there that are longs since discarded. > I currently expose isDeprecated in GIR API but I'm not using it in parsing, I may add this in this branch and see if it complicates things up (we may be exposing deprecated api in the public layer which will not be generated if marked as deprecated) - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkysxwMACgkQRh6X64ivZaJcQQCfWRC+zmrRsDe6DLZ1QMdZ8F/U mXcAn2tY7HRZXdko0CvNfTrJwhVG49az =8Kix -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-10-15 19:37:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I want to summarize the problems I have currently in the defscleanup branch and gir branch. * GdkBitmap (Bitmap) and GdkPixbufFormat (PixbufFormat) are interpreted as boxed's but in the public API they're not. * When a field and a getter/setter for that field exists, they collide since Accessor blocks and Method blocks generate duplicate Java methods. I don't know if sealing will address this in Gtk3. * A problem where I over came with defs, var-args methods are considered to be unsuitable for bindings and as a design decision not introspectable and we use some of them in the public API (especially some constructors where no non-var-arg constructors exist-See Gnome bug #141004[1]) * Generation of parameter and return types is hacky and makes assumptions (See GTypeInfo.c) I filed a bug[2] for inclusion of this in typelib (it's in GIR XML files but not compiled into typelibs) * Andrew is uncomfortable with some of the deprecated stub API I introduced to src/bindings Examining the Gtk-2.0.gir file (the one he sent) it seems that deprecated flag is not used in type level but function/signal level only. GIR API has isDeprecated() defined in GIBaseInfo which applies to all blocks. I don't know if this issue is just because they're not annotated as deprecated in source code. Maybe Gtk3 will resolve these as well. 1: https://bugzilla.gnome.org/show_bug.cgi?id=141004 2: https://bugzilla.gnome.org/show_bug.cgi?id=628812 - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky4rWcACgkQRh6X64ivZaJXtACfbhy17TmPqE2f8QWJC8fg8GvQ pA0An1Z4sbA4aNztjrvnCeLgppN+Y0qr =9VgE -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2010-10-02 03:02:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25-09-2010 11:41, Serkan Kaba wrote: > While running the generator, I discovered that we didn't use some of the > underlying type names in favor of more meaningful ones. I tried the > following patch and it works? So do you think it's hacky or not > acceptable? Or is it OK? > > I applied this logic but using properties file format which was cleaner to code. (Built in parser) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkymoJ4ACgkQRh6X64ivZaLRTgCeMn87wrGjyjaybNnlVauOGC+9 HmIAn1V0U3vF1teY9iUM5/1fnI8mLnnu =cOz6 -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2010-10-02 20:41:16
|
On Sat, 2010-10-02 at 06:01 +0300, Serkan Kaba wrote: > I applied this logic but using properties file format which was cleaner > to code. (Built in parser) That makes sense. The typeMapping.properties file we generate and include in the .jar is similar, and we likewise use Properties's load() to parse it. AfC Kingston |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X