Re: [Gegl-developer] Returning to python-gegl
So it looks like the right-thing-to-do now is to add introspection to Babl (otherwise we will need dirty workarounds in gegl). js -- On 12 February 2015 at 21:01, jcup...@gmail.com wrote: On 12 February 2015 at 16:30, Joao S. O. Bueno gwid...@mpc.com.br wrote: Otherwise, I think I will rewire the python bindings using another method to bridge to the C library, which is more predictive and better supported. I've made a Python binding for my largish C library using gobject-introspection and not had any serious problems. It was a bit wonky a year or so ago, but it honestly seems OK now. Performance is good too, and I don't see any memory leaks. I'm very grateful for it. I've been trying to make a Ruby binding in the same way and oh dear oh dear it's a lot harder :( John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On Fri, Feb 13, 2015 at 12:52 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: Ok, if people are committed to it, that means it is not left to die, and it is a matter of fixing it in GEGL (and GIMP soon). I've been looking around, one problem seems to be that since BABL has no introspection, any functions relying on BABL parameters (even just babl formats, which are ordinary C strings with a fancy typedef) are not exported. It might be worth looking into how cairo is bound with gobject introspection, since it also is a non-gtype based API that has a gobject introspection wrapper library. /pippin ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 12 February 2015 at 20:50, Jon Nordby jono...@gmail.com wrote: On 12 February 2015 at 06:30, Joao S. O. Bueno gwid...@mpc.com.br wrote: Hi - after several months I am taking back a look at my Python bindings for GEGL, which make use of gobject introspection. The situation with gobject introspection is none but frustrating - maybe one could use it, if he could live in #gobject on irc - but there seens to be no documentation resources wherever. Moreover, it does not work very well, whenever something is not available using the auto-generated bindings, there is no workaround, but to make/request changes on the upstream project and wait for a new release. That can be seen as a feature, it makes sure fixes go upstream, which makes it work for every language supported by GI - not just with one particular binding. No doubt about that - if it is being used. But for a moment looking at the state of lack of documentation, I thought it might have been given up. Add to that things that simply stop working (I just found out I can no longer instantiate a geglBuffer with the gobject introspection - and the solution in my package is a hack already to workaround the constructor failing in the past) Due to bug in GI, or changes in GEGL? Probably changes in GEGL - I will try to take a look this weekend - I was already using a non-standard constructor as I said (maybe it was Sabo's wrapper you mentioned in the other message. If so, that is broken now) Moreover, the latest GEGL stable release is still built with introspection off - so people can't make use of the Python bindings without rebuildoing GEGL themselves, as all distros ship the package without the gir files. If we have not changed the default go be --with-introspection, we should do that now. But yes, it will only work for GEGL 0.3+ But -- I may be wrong --- people may be firmly committed to gobject introspection, and it may be the future, and it is my fault not learning it right - And this is the main motivation for this message: Doo anyone believe/think/can explain/ if gobject introspection has a future at all? I think if we added testcases for consuming GEGL though Python/GI to upstream GEGL we would catch ( hopefully fix) breakages early. If we include the bindings library you have created in upstream GEGL to provide more Pythonic syntax, we could also add testcases for that. We should then ship it by default I think. I don't see the GNOME ecosystem switching away from GI anytime soon. And despite the pains (docs, bugs, annotations upstream), I do think the model is better than hand-writing bindings... There are tests in my module - possibly not many as there could be - I'd like to keep the its git separated due to the Python packaging ecosystem (and merging the histories would be a mess, I guess). Do you think it could work as a git submodule in GEGL? js -- -- Jon Nordby - www.jonnor.com ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 13 February 2015 at 20:12, Jon Nordby jono...@gmail.com wrote: On 13 February 2015 at 01:52, Joao S. O. Bueno I've been looking around, one problem seems to be that since BABL has no introspection, any functions relying on BABL parameters (even just babl formats, which are ordinary C strings with a fancy typedef) are not exported. Daniel Sabo fixed this a good while back, by writing simple wrappers with introspectable type signatures: https://github.com/GNOME/gegl/blob/master/gegl/gegl-introspection-support.h There are tests here that shows how it gets used https://github.com/GNOME/gegl/tree/master/tests/python Adding introspection to Babl proved impossible without changing the API, due to the strict conventions that GI requires. https://bugzilla.gnome.org/show_bug.cgi?id=673422 Thanks for the feedback on that. -- Jon Nordby - www.jonnor.com ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 13 February 2015 at 01:52, Joao S. O. Bueno I've been looking around, one problem seems to be that since BABL has no introspection, any functions relying on BABL parameters (even just babl formats, which are ordinary C strings with a fancy typedef) are not exported. Daniel Sabo fixed this a good while back, by writing simple wrappers with introspectable type signatures: https://github.com/GNOME/gegl/blob/master/gegl/gegl-introspection-support.h There are tests here that shows how it gets used https://github.com/GNOME/gegl/tree/master/tests/python Adding introspection to Babl proved impossible without changing the API, due to the strict conventions that GI requires. https://bugzilla.gnome.org/show_bug.cgi?id=673422 -- Jon Nordby - www.jonnor.com ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 12 February 2015 at 16:30, Joao S. O. Bueno gwid...@mpc.com.br wrote: Otherwise, I think I will rewire the python bindings using another method to bridge to the C library, which is more predictive and better supported. I've made a Python binding for my largish C library using gobject-introspection and not had any serious problems. It was a bit wonky a year or so ago, but it honestly seems OK now. Performance is good too, and I don't see any memory leaks. I'm very grateful for it. I've been trying to make a Ruby binding in the same way and oh dear oh dear it's a lot harder :( John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
