Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
No worries, we're not on a strict release schedule. We can do point releases at any time if you find that something needs to be updated. Thanks for your continued involvement. We're really looking forward to the final outcome. -- Art Chenthill wrote: I was not able to try the upstream libical yet. I am right now packed with some other work, so I will try to get this done as soon as possible. Suddenly the weekends have gone out of my hands as I have to move out of station to places that do not have internet connectivity. Either me or suman will make the changes and get the work done for 2.25.1 if the time is sufficient to get libical as a external dependency for GNOME 2.25.1. We would test the library and let you know before oct 17th. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
I was not able to try the upstream libical yet. I am right now packed with some other work, so I will try to get this done as soon as possible. Suddenly the weekends have gone out of my hands as I have to move out of station to places that do not have internet connectivity. Either me or suman will make the changes and get the work done for 2.25.1 if the time is sufficient to get libical as a external dependency for GNOME 2.25.1. We would test the library and let you know before oct 17th. thanks, Chenthill. On Fri, 2008-09-19 at 14:41 +0530, Chenthill wrote: > On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote: > > >> I have applied Chenthill's memory management patches (only to the > > >> 'libical' directory and to the examples -- still have to do the > > >> 'libicalcap' and 'libicalss' directories) using function names ending in > > >> "_r". > > > IMHO, HANDLE_LIBICAL_MEMORY can be removed. > > > > > > > Ok folks, it's done ... > > > > The remaining portions of libical (libicalcap and libicalss) have been > > converted to the "_r" API. (The test suite still uses the old API and > > will continue to do so for a while.) > > > > Now is the time for Evolution code to be updated to use the new calling > > syntax. > > > > Is there anything we can do to facilitate this, or should we just hang > > out and wait for you folks to kick the tires on the new library? Let me > > know... > I will make the changes and test it over this weekend. > > thanks, Chenthill. > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
I have applied Chenthill's memory management patches (only to the 'libical' directory and to the examples -- still have to do the 'libicalcap' and 'libicalss' directories) using function names ending in "_r". IMHO, HANDLE_LIBICAL_MEMORY can be removed. Ok folks, it's done ... The remaining portions of libical (libicalcap and libicalss) have been converted to the "_r" API. (The test suite still uses the old API and will continue to do so for a while.) Now is the time for Evolution code to be updated to use the new calling syntax. Is there anything we can do to facilitate this, or should we just hang out and wait for you folks to kick the tires on the new library? Let me know... -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote: > >> I have applied Chenthill's memory management patches (only to the > >> 'libical' directory and to the examples -- still have to do the > >> 'libicalcap' and 'libicalss' directories) using function names ending in > >> "_r". > > IMHO, HANDLE_LIBICAL_MEMORY can be removed. > > > > Ok folks, it's done ... > > The remaining portions of libical (libicalcap and libicalss) have been > converted to the "_r" API. (The test suite still uses the old API and > will continue to do so for a while.) > > Now is the time for Evolution code to be updated to use the new calling > syntax. > > Is there anything we can do to facilitate this, or should we just hang > out and wait for you folks to kick the tires on the new library? Let me > know... I will make the changes and test it over this weekend. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Since we do really want to remove the fork and pick up packages from upstream, I can change the apis in evolution related packages if a new set of apis with some suffix is provided from libical upstream. Many of you have probably already read this on the libical mailing list, but just in case: I have applied Chenthill's memory management patches (only to the 'libical' directory and to the examples -- still have to do the 'libicalcap' and 'libicalss' directories) using function names ending in "_r". For example, icalcomponent_as_ical_string() is now simply a wrapper around icalcomponent_as_ical_string_r() which places the new string buffer on the ring before returning it to the caller. The functions whose names end in "_r" have had Chenthill's memory management patches applied to them. Do we still need to add the HANDLE_LIBICAL_MEMORY hack to make the old function names act like the new ones? Chenthill's most recent message (quoted above) seems to imply that the Evolution team is willing to move to the new function names. Let me know. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Patrick Ohly wrote: Just to be clear, my proposal was to have them as normal functions under the old names (for backwards compatibility). They could be hidden by defines, but I don't like that because then someone reading code which calls libical cannot tell whether the code handles the memory correctly unless he also checks how it is compiled. Cut-and-paste could lead to memory handling errors. I think Patrick's proposed plan (all five steps) makes a lot of sense. That's the one we're going to go with. It maintains compatibility with both Evolution and other applications while allowing everyone to migrate to the new API at whatever pace makes sense for them. We will increment the library version, of course. Expect it to be at least 0.33, but this is a significant enough change that we might even go to 0.40. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Hello! A while ago in this thread I argued in favor of keeping the old functions around with their old semantic to preserve backwards compatibility. I still stand by that logic for *libical* users. But later it occurred to me that for *libecal* users this is an API change because code which was compiled against the latest libecal may free the memory and therefore crash when the libical implementation is no longer the one from libecal, but the upstream version. Therefore the revision will have to be bumped from LIBECAL_CURRENT=9 LIBECAL_REVISION=1 LIBECAL_AGE=2 to LIBECAL_CURRENT=10 LIBECAL_REVISION=0 LIBECAL_AGE=0 SyncEvolution would remain binary compatible *without* a revision change because it checks at runtime how memory handling is to be done. *With* the revision change I'll have to compile another version of it :-/ But there might be other users of the library which don't check at runtime (Evolution itself for example) and therefore it is safer to bump the revision. I'd be more than happy to hear that I'm too concerned here and that the revision change won't be necessary. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Tue, 2008-09-16 at 09:37 -0400, IGnatius T Foobar wrote: > > Since we do really want to remove the fork and pick up packages from > > upstream, I can change the apis in evolution related packages if a new > > set of apis with some suffix is provided from libical upstream. > > > Many of you have probably already read this on the libical mailing list, > but just in case: > > I have applied Chenthill's memory management patches (only to the > 'libical' directory and to the examples -- still have to do the > 'libicalcap' and 'libicalss' directories) using function names ending in > "_r". For example, icalcomponent_as_ical_string() is now simply a > wrapper around icalcomponent_as_ical_string_r() which places the new > string buffer on the ring before returning it to the caller. The > functions whose names end in "_r" have had Chenthill's memory management > patches applied to them. > > Do we still need to add the HANDLE_LIBICAL_MEMORY hack to make the old > function names act like the new ones? Chenthill's most recent message > (quoted above) seems to imply that the Evolution team is willing to move > to the new function names. Let me know. IMHO, HANDLE_LIBICAL_MEMORY can be removed. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
>Mi Sep 10 2008 11:26:31 EDT von Chenthill in 00.Sent Items> an >Patrick Ohly >Betreff: Re: [Evolution-hackers] Removing libical fork, moving to new >upstream? > > >>> >>> > How would you feel about a global flag which tells libical how to >>> > allocate memory? >>> >>> The problem with that is that it is not possible to mix code which uses >>> the old and the new semantic. For example, a program or library which >>> uses libical directly, using the old semantic, couldn't be combined with >>> the Evolution libraries. >> > >Yes right. Its not possible to have the old semantic with changed memory >allocation. > >>> >>> To let old and new code coexists I would suggest the following approach: >>> 1. The Evolution patch gets applied, making the core functions safe >>> to use. >>> 2. The function implementations whose semantic has changed get >>> renamed; I kind of like the _r suffix, but _alloc or _copy would >>> also work. >>> 3. Under the old names small wrappers are added which establish the >>> old behavior again by copying the string into the ring buffer >>> and freeing the dynamically allocated one: this incurs some >>> overhead, but usage of these versions of the calls is >>> discouraged anyway. By using function attributes it would be >>> possible to trigger deprecation warnings for code which still >>> uses them. >>> 4. In the header file both variants are declared. >>> 5. In addition, ical.h also redefines the old names to the new >>> names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code >>> already does that and therefore continues to work with such a >>> modified upstream libical without source code changes. >>> >>> I personally would prefer to avoid step 5 and rather do a search/replace >>> in Evolution, but Chenthill didn't like that. >> >Since we do really want to remove the fork and pick up packages from >upstream, I can change the apis in evolution related packages if a new >set of apis with some suffix is provided from libical upstream. > >The old patch is attached with bug 516408. You can find the patches at, > >http://svn.gnome.org/viewvc/libical?view=revision&revision=633 >and >http://svn.gnome.org/viewvc/libical?view=revision&revision=637 > > >thanks, Chenthill. > > > Since it doesn't make sense imho to mix old style and new style api calls in one application imho, and I hink we can deprecate the old style. It also should be exeptable to drop binary compatibility; raise the lib-version, and add one significant incompatible function here, which gets triggered, so distributors have to recompile applications. I think the oldstyle methods realy should just be wrappers in the headers, and I like the idea of hiding them via an define. We also have the new include schematic of having libical/ical.h than maybe this could be used to do it imlicit, so no define would be needed in the old case. Wilfried Goesgens___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Wed, 2008-09-10 at 08:18 -0400, dothebart wrote: > Since it doesn't make sense imho to mix old style and new style api > calls in one application imho, and I hink we can deprecate the old > style. We can deprecate it, but as you said yourself earlier, moving all developers over to the new API at once might not be possible, so the old one should stay around for a while. > > It also should be exeptable to drop binary compatibility; raise the > lib-version, and add one significant incompatible function here, which > gets triggered, so distributors have to recompile applications. Please try to avoid breaking backwards compatibility. I release SyncEvolution binaries and already have to compile three different versions just because of ABI changes; changing the libical ABI would add another version :-/ > I think the oldstyle methods realy should just be wrappers in the > headers, and I like the idea of hiding them via an define. Just to be clear, my proposal was to have them as normal functions under the old names (for backwards compatibility). They could be hidden by defines, but I don't like that because then someone reading code which calls libical cannot tell whether the code handles the memory correctly unless he also checks how it is compiled. Cut-and-paste could lead to memory handling errors. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Chenthill wrote: So it is better to inform all the stake holders about the change and let them depend on the library versions to decide whether to free the memory or not if they have a need to depend on the older versions of libical. I think no one deny to make the necessary changes knowing that the old API is not very stable. Atleast once I noticed the problem. I made this patch and made all the changes required in evolution, evolution-exchange and evolution-data-server. I would not really like to change them again with new APIS :) Although I agree that the new memory model is a vast improvement over the existing one, I think you may be underestimating the potential effects of telling dozens of downstream projects that they will have to rewrite their code *right* *now* in order to continue using libical. Many will respond by forking, or staying forked, which as I mentioned earlier is exactly the opposite of what we are trying to accomplish. How would you feel about a global flag which tells libical how to allocate memory? Surely you wouldn't mind adding one line of code during an initialization phase that tells libical "caller accepts the responsibility to free all returned strings" ?? (The ring buffer memory model, inferior as it may be, must still be the default in order to run existing code unmodified.) If this is acceptable, then would someone please point us to a patch which implements the memory management changes, and we'll apply an enhanced version of it with user-selectable memory allocation model added in. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Tue, 2008-09-09 at 18:00 +0200, Patrick Ohly wrote: > On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote: > > Chenthill wrote: > > > So it is better to inform all the stake holders about the change and let > > > them depend on the library versions to decide whether to free the memory > > > or not if they have a need to depend on the older versions of libical. I > > > think no one deny to make the necessary changes knowing that the old API > > > is not very stable. > > > > > > Atleast once I noticed the problem. I made this patch and made all the > > > changes required in evolution, evolution-exchange and > > > evolution-data-server. I would not really like to change them again with > > > new APIS :) > > Although I agree that the new memory model is a vast improvement over > > the existing one, I think you may be underestimating the potential > > effects of telling dozens of downstream projects that they will have to > > rewrite their code *right* *now* in order to continue using libical. > > Many will respond by forking, or staying forked, which as I mentioned > > earlier is exactly the opposite of what we are trying to accomplish. > > I agree. When I started writing the patch, since only the gnome packages which depend on libecal are going be affected. I thought of incorporating changes in all other modules myself since it was just to grep all the apis and free the returned memory. So I had a thinking that all the downstream projects would be ready to change their code during a release time since stability is an issue and change can be done fast. But if it was not the case and might result in forking again, the only solution which I too see is create a new set of API's which uses the new memory allocation. > > > How would you feel about a global flag which tells libical how to > > allocate memory? > > The problem with that is that it is not possible to mix code which uses > the old and the new semantic. For example, a program or library which > uses libical directly, using the old semantic, couldn't be combined with > the Evolution libraries. Yes right. Its not possible to have the old semantic with changed memory allocation. > > To let old and new code coexists I would suggest the following approach: > 1. The Evolution patch gets applied, making the core functions safe > to use. > 2. The function implementations whose semantic has changed get > renamed; I kind of like the _r suffix, but _alloc or _copy would > also work. > 3. Under the old names small wrappers are added which establish the > old behavior again by copying the string into the ring buffer > and freeing the dynamically allocated one: this incurs some > overhead, but usage of these versions of the calls is > discouraged anyway. By using function attributes it would be > possible to trigger deprecation warnings for code which still > uses them. > 4. In the header file both variants are declared. > 5. In addition, ical.h also redefines the old names to the new > names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code > already does that and therefore continues to work with such a > modified upstream libical without source code changes. > > I personally would prefer to avoid step 5 and rather do a search/replace > in Evolution, but Chenthill didn't like that. Since we do really want to remove the fork and pick up packages from upstream, I can change the apis in evolution related packages if a new set of apis with some suffix is provided from libical upstream. The old patch is attached with bug 516408. You can find the patches at, http://svn.gnome.org/viewvc/libical?view=revision&revision=633 and http://svn.gnome.org/viewvc/libical?view=revision&revision=637 thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote: > Chenthill wrote: > > So it is better to inform all the stake holders about the change and let > > them depend on the library versions to decide whether to free the memory > > or not if they have a need to depend on the older versions of libical. I > > think no one deny to make the necessary changes knowing that the old API > > is not very stable. > > > > Atleast once I noticed the problem. I made this patch and made all the > > changes required in evolution, evolution-exchange and > > evolution-data-server. I would not really like to change them again with > > new APIS :) > Although I agree that the new memory model is a vast improvement over > the existing one, I think you may be underestimating the potential > effects of telling dozens of downstream projects that they will have to > rewrite their code *right* *now* in order to continue using libical. > Many will respond by forking, or staying forked, which as I mentioned > earlier is exactly the opposite of what we are trying to accomplish. I agree. > How would you feel about a global flag which tells libical how to > allocate memory? The problem with that is that it is not possible to mix code which uses the old and the new semantic. For example, a program or library which uses libical directly, using the old semantic, couldn't be combined with the Evolution libraries. To let old and new code coexists I would suggest the following approach: 1. The Evolution patch gets applied, making the core functions safe to use. 2. The function implementations whose semantic has changed get renamed; I kind of like the _r suffix, but _alloc or _copy would also work. 3. Under the old names small wrappers are added which establish the old behavior again by copying the string into the ring buffer and freeing the dynamically allocated one: this incurs some overhead, but usage of these versions of the calls is discouraged anyway. By using function attributes it would be possible to trigger deprecation warnings for code which still uses them. 4. In the header file both variants are declared. 5. In addition, ical.h also redefines the old names to the new names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code already does that and therefore continues to work with such a modified upstream libical without source code changes. I personally would prefer to avoid step 5 and rather do a search/replace in Evolution, but Chenthill didn't like that. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 23:55 -0400, IGnatius T Foobar wrote: > Patrick Ohly wrote: > > In the upstream libical certain functions return char * pointers into > > memory stored in ring buffers. The caller must not free those pointers. > > The drawback is that the life time of those strings is not predictable. > > > > In the current Evolution libical, those same functions (not renamed!) > > return copies of the string which the caller has to free. Code which was > > written using the old semantic of the calls will leak memory. Code > > adapted to the new semantic (like Evolution) will crash when combined > > with the upstream libical without the same patch. > > > Ok, I definitely see the benefit there. This is similar to POSIX calls > which now offer alternative versions (usually with "_r" appended to the > name) that don't use a static buffer or a ring buffer, in order to be > reentrant? > > If all users of the upstream libical are willing to adapt their code, > > then the best solution would be to simply import the Evolution patch > > into upstream. > > > As much as I'd like to see that happen, I don't think it's realistic. > libical is used by dozens of downstream projects, and a sudden forced > API change is likely to encourage them to fork (or stay forked, if > they've already done so) -- exactly the opposite of the end we are > trying to achieve! > > If there is resistance against that, then we could provide two versions > > of each of these API calls: one with the old name and old behavior and > > one with the new behavior and a name suffix. > That seems more realistic. The alternative might be to offer a global > flag that tells libical to behave one way or the other? (I think > something like that was suggested at some point.) > > While I definitely think the new method of memory allocation makes far > more sense (we'll definitely use it in Citadel, as all of our code is > multithreaded) -- expecting the entire community to perform a "flag day" > API change in lockstep is likely to cause confusion and delay. If we > pursued either the alternate function names or the global flag, is there > likely to be any pushback from the Evolution team? I do not feel having alternate function names would be a better solution. Consider the following API which remains the same before and after the memory fixes, char * icalcomponent_as_ical_string (icalcomponent *icomp); The returned memory from this API was internally handled by libical before and now its given to the caller. Though the return type gives an indication that the memory is owned by caller, it was not the case. So having a new API for this and changing the behavior does not look to be a good solution since the underlying memory allocation had to be changed. Similarly even with other APIs which return const char* values, the memory can be overwritten at any time. While removing the ring buffer return type's of all the APIs had to be changed from const char * to char *. Is it really worth it to have the old unstable APIs which can crash the application randomly ? My answer would be NO. This is not just a problem with multi-threaded programs. The crash could happen once the ring buffer gets full and starts overwriting the used memory. Since we statically link to libical and expose it via libecal, we have updated the library versions of libecal. We have an additional flag check (hack) also for it now with a warning as in http://bugzilla.gnome.org/show_bug.cgi?id=528986 . So it is better to inform all the stake holders about the change and let them depend on the library versions to decide whether to free the memory or not if they have a need to depend on the older versions of libical. I think no one deny to make the necessary changes knowing that the old API is not very stable. Atleast once I noticed the problem. I made this patch and made all the changes required in evolution, evolution-exchange and evolution-data-server. I would not really like to change them again with new APIS :) thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Patrick Ohly wrote: In the upstream libical certain functions return char * pointers into memory stored in ring buffers. The caller must not free those pointers. The drawback is that the life time of those strings is not predictable. In the current Evolution libical, those same functions (not renamed!) return copies of the string which the caller has to free. Code which was written using the old semantic of the calls will leak memory. Code adapted to the new semantic (like Evolution) will crash when combined with the upstream libical without the same patch. Ok, I definitely see the benefit there. This is similar to POSIX calls which now offer alternative versions (usually with "_r" appended to the name) that don't use a static buffer or a ring buffer, in order to be reentrant? If all users of the upstream libical are willing to adapt their code, then the best solution would be to simply import the Evolution patch into upstream. As much as I'd like to see that happen, I don't think it's realistic. libical is used by dozens of downstream projects, and a sudden forced API change is likely to encourage them to fork (or stay forked, if they've already done so) -- exactly the opposite of the end we are trying to achieve! If there is resistance against that, then we could provide two versions of each of these API calls: one with the old name and old behavior and one with the new behavior and a name suffix. That seems more realistic. The alternative might be to offer a global flag that tells libical to behave one way or the other? (I think something like that was suggested at some point.) While I definitely think the new method of memory allocation makes far more sense (we'll definitely use it in Citadel, as all of our code is multithreaded) -- expecting the entire community to perform a "flag day" API change in lockstep is likely to cause confusion and delay. If we pursued either the alternate function names or the global flag, is there likely to be any pushback from the Evolution team? -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Chenthill wrote: On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: Hello! http://sourceforge.net/projects/freeassociation/ has released 0.32 of libical on 2008-09-01. The KDE-PIM team has switched to that code for KDE 4.2. On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: I discovered last week that there is an attempt to resurrect libical from non-maintainership, merge all of the patches from various forks, and start making sane releases again[1]. Are the evolution team as whole interested in merging their changes to libical upstream and depending on it to be installed when a release is made with all of the relevant changes? libical isn't exactly a small library, and statically linking it is a waste of memory for everyone. I vaguely recall the biggest diff being timezone handling. Not sure about that. They have merged the "system timezone database conversion" code, if that's what you mean. Unfortunately they missed the recent bug fixes required for that code to handle the upcoming summer->winter time transition. We really should have been more active with keeping them informed about Evolution-libical changes. I have alerted them and the KDE-PIM team of the problem. However, they haven't included the modified memory handling. Considering that this breaks the user space API merging it might be a hard sell. I'll happily start working on extracting the changes to EDS and pushing them into the new libical repository, if the Evolution team as a whole agrees that the fork of libical will be dropped. +1 +1 from my side too. We were discussing about this at http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes to be merged upstream. We wanted to get this done for 2.26. thanks, Chenthill In what way does it break the userspace API? Is it possible that the API could be extended in such a way that memory handling depends upon how it's called? We would *really* like to get everyone merged and re-unify this library once and for all. Everyone would benefit. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote: > In what way does it break the userspace API? Is it possible that the > API could be extended in such a way that memory handling depends upon > how it's called? Chenthill already provided the relevant links: http://bugzilla.gnome.org/show_bug.cgi?id=516408 http://bugzilla.gnome.org/show_bug.cgi?id=528986 For the sake of discussion let me summarize how the API has changed, then suggest ways how that could be dealt with. In the upstream libical certain functions return char * pointers into memory stored in ring buffers. The caller must not free those pointers. The drawback is that the life time of those strings is not predictable. In the current Evolution libical, those same functions (not renamed!) return copies of the string which the caller has to free. Code which was written using the old semantic of the calls will leak memory. Code adapted to the new semantic (like Evolution) will crash when combined with the upstream libical without the same patch. There are defines in the Evolution libical header which can be used to detect what the memory handling is, so code can be written so that it works with both the old and the new semantic. SyncEvolution goes one step further and also does a runtime check, so the same binary works with both an old and a new Evolution release. If all users of the upstream libical are willing to adapt their code, then the best solution would be to simply import the Evolution patch into upstream. If there is resistance against that, then we could provide two versions of each of these API calls: one with the old name and old behavior and one with the new behavior and a name suffix. Evolution then has to be patched to use the new calls, which can be done either with a global search/replace or via defines (ugly!). SyncEvolution would work fine without code changes, it'll simply fall back to not freeing the strings. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote: > Chenthill wrote: > > On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: > > > > > Hello! > > > > > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of > > > libical on 2008-09-01. The KDE-PIM team has switched to that code for > > > KDE 4.2. > > > > > > On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > > > > > > > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > > > > > > > > I discovered last week that there is an attempt to resurrect libical > > > > > from non-maintainership, merge all of the patches from various forks, > > > > > and start making sane releases again[1]. Are the evolution team as > > > > > whole interested in merging their changes to libical upstream and > > > > > depending on it to be installed when a release is made with all of the > > > > > relevant changes? libical isn't exactly a small library, and > > > > > statically > > > > > linking it is a waste of memory for everyone. > > > > > > > > > I vaguely recall the biggest diff being timezone handling. > > > > > > > Not sure about that. They have merged the "system timezone database > > > conversion" code, if that's what you mean. Unfortunately they missed the > > > recent bug fixes required for that code to handle the upcoming > > > summer->winter time transition. We really should have been more active > > > with keeping them informed about Evolution-libical changes. I have > > > alerted them and the KDE-PIM team of the problem. > > > > > > However, they haven't included the modified memory handling. Considering > > > that this breaks the user space API merging it might be a hard sell. > > > > > > > > > > > I'll happily start working on extracting the changes to EDS and > > > > > pushing > > > > > them into the new libical repository, if the Evolution team as a whole > > > > > agrees that the fork of libical will be dropped. > > > > > > > > +1 > > > > > +1 from my side too. We were discussing about this at > > http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes > > to be merged upstream. We wanted to get this done for 2.26. > > > > thanks, Chenthill > In what way does it break the userspace API? Is it possible that the > API could be extended in such a way that memory handling depends upon > how it's called? All the information/discussion about this is available at, http://bugzilla.gnome.org/show_bug.cgi?id=516408 and http://bugzilla.gnome.org/show_bug.cgi?id=528986 > > We would *really* like to get everyone merged and re-unify this > library once and for all. Everyone would benefit. We provide our support too to get this done!! thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: > Hello! > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of > libical on 2008-09-01. The KDE-PIM team has switched to that code for > KDE 4.2. > > On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > > I discovered last week that there is an attempt to resurrect libical > > > from non-maintainership, merge all of the patches from various forks, > > > and start making sane releases again[1]. Are the evolution team as > > > whole interested in merging their changes to libical upstream and > > > depending on it to be installed when a release is made with all of the > > > relevant changes? libical isn't exactly a small library, and statically > > > linking it is a waste of memory for everyone. > > > > I vaguely recall the biggest diff being timezone handling. > > Not sure about that. They have merged the "system timezone database > conversion" code, if that's what you mean. Unfortunately they missed the > recent bug fixes required for that code to handle the upcoming > summer->winter time transition. We really should have been more active > with keeping them informed about Evolution-libical changes. I have > alerted them and the KDE-PIM team of the problem. > > However, they haven't included the modified memory handling. Considering > that this breaks the user space API merging it might be a hard sell. > > > > I'll happily start working on extracting the changes to EDS and pushing > > > them into the new libical repository, if the Evolution team as a whole > > > agrees that the fork of libical will be dropped. > > +1 +1 from my side too. We were discussing about this at http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes to be merged upstream. We wanted to get this done for 2.26. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Hello! http://sourceforge.net/projects/freeassociation/ has released 0.32 of libical on 2008-09-01. The KDE-PIM team has switched to that code for KDE 4.2. On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > I discovered last week that there is an attempt to resurrect libical > > from non-maintainership, merge all of the patches from various forks, > > and start making sane releases again[1]. Are the evolution team as > > whole interested in merging their changes to libical upstream and > > depending on it to be installed when a release is made with all of the > > relevant changes? libical isn't exactly a small library, and statically > > linking it is a waste of memory for everyone. > > I vaguely recall the biggest diff being timezone handling. Not sure about that. They have merged the "system timezone database conversion" code, if that's what you mean. Unfortunately they missed the recent bug fixes required for that code to handle the upcoming summer->winter time transition. We really should have been more active with keeping them informed about Evolution-libical changes. I have alerted them and the KDE-PIM team of the problem. However, they haven't included the modified memory handling. Considering that this breaks the user space API merging it might be a hard sell. > > I'll happily start working on extracting the changes to EDS and pushing > > them into the new libical repository, if the Evolution team as a whole > > agrees that the fork of libical will be dropped. +1 -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > Hi, > > > > I discovered last week that there is an attempt to resurrect libical > > from non-maintainership, merge all of the patches from various forks, > > and start making sane releases again[1]. Are the evolution team as > > whole interested in merging their changes to libical upstream and > > depending on it to be installed when a release is made with all of the > > relevant changes? libical isn't exactly a small library, and statically > > linking it is a waste of memory for everyone. > > I vaguely recall the biggest diff being timezone handling. > > > I'll happily start working on extracting the changes to EDS and pushing > > them into the new libical repository, if the Evolution team as a whole > > agrees that the fork of libical will be dropped. > > I'd suggested waiting to see a pattern of stable releases before moving > externally, but getting the patches upstream would be good. Sounds very reasonable to me. -Srini. > > -JP ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > Hi, > > I discovered last week that there is an attempt to resurrect libical > from non-maintainership, merge all of the patches from various forks, > and start making sane releases again[1]. Are the evolution team as > whole interested in merging their changes to libical upstream and > depending on it to be installed when a release is made with all of the > relevant changes? libical isn't exactly a small library, and statically > linking it is a waste of memory for everyone. I vaguely recall the biggest diff being timezone handling. > I'll happily start working on extracting the changes to EDS and pushing > them into the new libical repository, if the Evolution team as a whole > agrees that the fork of libical will be dropped. I'd suggested waiting to see a pattern of stable releases before moving externally, but getting the patches upstream would be good. -JP -- JP Rosevear <[EMAIL PROTECTED]> Novell, Inc. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > I'll happily start working on extracting the changes to EDS and pushing > them into the new libical repository, if the Evolution team as a whole > agrees that the fork of libical will be dropped. +1 Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Removing libical fork, moving to new upstream?
Hi, I discovered last week that there is an attempt to resurrect libical from non-maintainership, merge all of the patches from various forks, and start making sane releases again[1]. Are the evolution team as whole interested in merging their changes to libical upstream and depending on it to be installed when a release is made with all of the relevant changes? libical isn't exactly a small library, and statically linking it is a waste of memory for everyone. I'll happily start working on extracting the changes to EDS and pushing them into the new libical repository, if the Evolution team as a whole agrees that the fork of libical will be dropped. Ross [1] http://sourceforge.net/projects/freeassociation/ -- last commit two weeks ago! -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
