Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread Chenthill
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

Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread Chenthill
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

Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread Patrick Ohly
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:

Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread IGnatius T Foobar
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

Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-09-08 Thread IGnatius T Foobar
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