Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Tue, 2014-05-20 at 11:07 +0200, Patrick Ohly wrote: Aren't you going to run into the same problem with a GObject-based proxies for these libical objects? The proxies are reference-counted, the libical objects are not, so they may go away before their proxies do. This would leave the proxy with a dangling pointer or (if it somehow tracks the lifetime of the owner of the object) in a state where it is unusable. I imagine the GObject proxies would need to hold their own copies of libical objects and have some explicit set API to apply changes back to a parent object. It's more expensive, but that's the trade-off for thread-safety. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Tue, 2014-05-20 at 11:07 +0200, Patrick Ohly wrote: Aren't you going to run into the same problem with a GObject-based proxies for these libical objects? The proxies are reference-counted, the libical objects are not, so they may go away before their proxies do. This would leave the proxy with a dangling pointer or (if it somehow tracks the lifetime of the owner of the object) in a state where it is unusable. Hi, my idea was that an ICalComponent will hold its own icalcomponent and any getter of an internal libical structure will reference also the ICalComponent, which will make sure that the parent object will not die before all the subobjects will be freed. These refs would be done across whole new API. Once also evolution will use these ICalComponent-s all what works will keep working. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Fri, 2014-05-16 at 08:56 +0100, Philip Withnall wrote: So Fabiano asked about this in #gnome-hackers yesterday, and I think the conclusion was to do something similar to what's done in Cairo: add the G_DEFINE_BOXED_TYPE and glib-mkenums boilerplate somewhere (either directly in libical, or in a small libical-glib library which otherwise does *not* wrap the libical API). I think gobject-introspection will need fixing to support non-standard names for APIs and types. Hi, that was my idea too, the project seemed extensive, but not too complicated. Nonetheless, Will found an issue with libical memory management quite quickly and I recalled it when I was talking to him yesterday. The main problem is that the API returns pointers which are part of the structure that you ask the value of it - like when you ask for a subcomponent of an icalcomponent. If it exists, you get a child of the parent component. This makes a disaster due to the unpredictable memory management in python or javascript (introspection-using languages in general?). The libecal uses this libical behaviour too. As an example, if you ask for an alarm of an ECalComponent, then you receive a new structure which holds a libical structure, which is part of the ECalComponent (icalcomponent of it). Any changes done through this structure are immediately propagated into the parent's ECalComponent, aka there is no save involved. If you free ECalComponent before the alarm structure, then the free of the alarm structure causes a crash. As you cannot influence the memory-free time in python... and even if it would be possible, then we cannot expect from the introspection interface users (developers) to tweak their code in a way they are not used to (like making some memory/variable management on their own). That's basically the reason why we'll need a real GObject-s, which will hide this behaviour and will make it simpler in the introspection languages to play with ICalComponent objects (proposal for the name). As a side-effect we also get a nice gtk-doc developer reference, which might be a real plus. The more I think of this, the more I'm convinced that there will be some pattern which will Will be able to use and generate all the introspectable API with some smart scripts from public libical headers, which will also make sure that any future API changes in libical will be easily noticed. Something similar to gdbus-codegen, with an input file for function's documentation. It still needs more thinking and testing and so on, I only offer the idea to Will sooner, thus he'll have time to think of it. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: Hello, maybe you noticed that we have a GSoC project for this year, to enable introspection for calendar part of evolution-data-server (libecal), which will make it usable for other languages as well. As said already, doing this as add-on of libical and then later taking advantage of it in EDS seems like the right approach. Will is a student which will do the main work. The current problem is libical, its icalcomponent, enums and all other structures. I thought that we will be able to introspect this with simple boxed types, but it doesn't seem to be possible, thus the only option I can see is to massively change API of the calendar and define proxies for libical structures and enums. These proxies would be fully GObject-based, which might be a plus, I hope. I would, for example, define a GObject ICalComponent, which would have its i_cal_component_* API functions, mimic all the icalcomponent API, hiding the icalcomponent structure in the background. Would it be possible to keep the current EDS API around and just add the new introspectable API? Such change will be huge, but more importantly it'll be an earthquake for anything using libecal (the ECalComponent would not use icalcomponent anymore, it would start using ICalComponent instead). ECalComponent would use a proxy of the original icalcomponent, right? If the introspection layer in libical has a way to convert to and from the original icalcomponent and the introspectable proxy, then ECalComponent could convert back and forth as needed, depending on which API the EDS client uses. Because of this earthquake, I would like to hear from others their opinion. Maybe we overlooked some option in introspection (there is preferred to create introspection based on code annotations, not to define them by hand), but I'm afraid the most of the projects like SyncEvolution, whether it'll be able to handle such change gracefully. I've made my peace with ABI and API changes in EDS ;-} I'm not happy about them, but I can handle them with a combination of ifdefs and compilation of backend shared objects on different Linux distros. Just give me enough and explicit warning beforehand. If an API change can't be avoided, then don't let SyncEvolution hold you back. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
Hey, If you have some output showing the errors gobject-introspection gives you when you run it on libical, I might be able to help you fix them. Philip On Wed, 2014-05-14 at 20:13 -0400, Miao Yu wrote: Hi, If I am not wrong, it is because the gobject-introspection has a hard time in introspecting a third-party types, as those in libical. For now, the only solution I can come up with is, as Milan said, to create a proxy type for every type of libical which is used in EDS. After that, I have to replace the libical types with the newly-created introspectable proxy type in the API, which causes the disaster. And this solution is, in nature, to write a introspectable wrapper for the libical library. So that's why Milan want to put this under GObject so that other applications can also use it instead of the libical. And your solution is a nice way to fix that. Actually the focus can also be put on the gobject-introspection. And gobject-introspection can work with libical. Due to lack of experience, I cannot say which one is better for now. But they can work to the same end. But if we focus on the gobject-introspection, the introspection is not more focusing solely on the gobjects since libical is a third-party library. Thank you. William Yu -Original Message- From: Philip Withnall phi...@tecnocode.co.uk To: Milan Crha mc...@redhat.com Cc: evolution-hackers evolution-hackers@gnome.org; will.yu will...@aol.com Sent: Wed, May 14, 2014 1:16 pm Subject: Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed? On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: The current problem is libical, its icalcomponent, enums and all other structures. I thought that we will be able to introspect this with simple boxed types, but it doesn't seem to be possible, thus the only option I can see is to massively change API of the calendar and define proxies for libical structures and enums. These proxies would be fully GObject-based, which might be a plus, I hope. What exactly is the problem with introspecting libical? If it's a fixable problem with gobject-introspection, I suspect it would be less work (and a better overall outcome) if time were put into fixing gobject-introspection so that libical *can* be introspected; rather than putting more work into a wrapper library which will increase memory overheads and require maintenance. Philip signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Thu, 2014-05-15 at 11:13 +0100, Philip Withnall wrote: If you have some output showing the errors gobject-introspection gives you when you run it on libical, I might be able to help you fix them. Hi, we tried to introspect libical inside libecal, basically by boxing libical types. The mos common error (warning) is about Unresolved type-s. These involve icaltimezone and icalcomponent. Both types are really defined as incomplete [1], but also out of the eds source. This marks related functions as unintrospectable. Another issue is with enums. Also the naming is not what gobject-introspection likes, there is no camel-case naming used in libical. I suppose half of the problem would be to solved by generating gir files directly in libical, but I'm afraid it'll not be enough, due to those incomplete types (the enums might be fixed by this, I guess). I've also quite limited knowledge of introspection, thus any help/guidance is more than welcome. Bye, Milan [1] typedef struct icalcomponent_impl icalcomponent; typedef struct _icaltimezoneicaltimezone; ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Introspection enablement for libecal - huge changes needed?
Hello, maybe you noticed that we have a GSoC project for this year, to enable introspection for calendar part of evolution-data-server (libecal), which will make it usable for other languages as well. Will is a student which will do the main work. The current problem is libical, its icalcomponent, enums and all other structures. I thought that we will be able to introspect this with simple boxed types, but it doesn't seem to be possible, thus the only option I can see is to massively change API of the calendar and define proxies for libical structures and enums. These proxies would be fully GObject-based, which might be a plus, I hope. I would, for example, define a GObject ICalComponent, which would have its i_cal_component_* API functions, mimic all the icalcomponent API, hiding the icalcomponent structure in the background. Such change will be huge, but more importantly it'll be an earthquake for anything using libecal (the ECalComponent would not use icalcomponent anymore, it would start using ICalComponent instead). Because of this earthquake, I would like to hear from others their opinion. Maybe we overlooked some option in introspection (there is preferred to create introspection based on code annotations, not to define them by hand), but I'm afraid the most of the projects like SyncEvolution, whether it'll be able to handle such change gracefully. I'd appreciate any opinion on the subject. Will, if you want to clarify anything from what I said, please do. I think we'll change the GSoC definition a bit, the task will be to create GObject-based API for libical library, and the followup work will be an integration into evolution of this new API. The followup means not for the GSoC. Let's talk about this off-list. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Wed, 2014-05-14 at 10:23 -0400, Matthew Barnes wrote: ... I suggest doing this as a stand-alone library -- libical-glib perhaps -- ... Hi, right, my idea was (I should be more specific initially, I'm sorry) to develop the standalone library with Will, like you proposed libical-glib, as part of the GSoC project and then offer it to libical developers for inclusion in libical itself, which could be compiled conditionally in libical itself. I believe it's the natural place for the libical-glib, together with tests for it. There will not be much difference for Will in the GSoC work, it'll be only a slightly smaller scope, by avoiding evolution-data-server bits, but otherwise the same expertise field. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
