You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(4) |
May
(4) |
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(54) |
Oct
(57) |
Nov
(23) |
Dec
(24) |
2009 |
Jan
(23) |
Feb
(14) |
Mar
(3) |
Apr
|
May
(7) |
Jun
(24) |
Jul
(26) |
Aug
(24) |
Sep
(16) |
Oct
(4) |
Nov
(10) |
Dec
(22) |
2010 |
Jan
(12) |
Feb
(34) |
Mar
(32) |
Apr
(2) |
May
(6) |
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
(1) |
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(38) |
Sep
(1) |
Oct
(20) |
Nov
(2) |
Dec
(12) |
2012 |
Jan
(2) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(10) |
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Art C. <aj...@ci...> - 2008-04-10 23:35:16
|
>With rrule FREQ=WEEKLY;INTERVAL=1;BYDAY=MO,WE,FR;WKST=SU, but the start of >the event pattern is on Sunday. The behavior I've noticed is that the call >to "icalrecur_iterator_next" generates an event on Wednesday, with Monday >being skipped. > >The attached and inline patch fixes this behavior. Thanks for the patch. This will get tested, and hopefully applied, within the next couple of days. |
From: Josh S. <jsk...@gm...> - 2008-04-07 23:18:25
|
Index: libical/src/libical/icalrecur.c =================================================================== RCS file: /cvsroot/freeassociation/libical/src/libical/icalrecur.c,v retrieving revision 1.71 diff -u -8 -p -r1.71 icalrecur.c --- libical/src/libical/icalrecur.c 3 Feb 2008 16:10:46 -0000 1.71 +++ libical/src/libical/icalrecur.c 7 Apr 2008 23:02:12 -0000 @@ -944,19 +944,24 @@ icalrecur_iterator* icalrecur_iterator_n days ahead ) will skip over some occurrences in the second week. */ /* This depends on impl->by_ptrs[BY_DAY] being correctly sorted by * day. This should probably be abstracted to make such assumption * more explicit. */ short dow = (short)(impl->by_ptrs[BY_DAY][0]-icaltime_day_of_week(impl->last)); - if (dow > impl->rule.week_start-1) dow -= 7; - impl->last.day += dow; - impl->last = icaltime_normalize(impl->last); + + if((icaltime_day_of_week(impl->last) < impl->by_ptrs[BY_DAY][0] && dow >= 0) || dow < 0) + { + /* initial time is after first day of BY_DAY data */ + + impl->last.day += dow; + impl->last = icaltime_normalize(impl->last); + } } } /* For YEARLY rule, begin by setting up the year days array . The YEARLY rules work by expanding one year at a time. */ |
From: Allen W. <wi...@kd...> - 2008-04-02 13:36:25
|
Hmm.. libical v0.31 doesn't build for me icalssyacc.c: In function 'ssparse': icalssyacc.c:518: error: too few arguments to function 'sslex' icalssyacc.c:711: error: too few arguments to function 'sslex' But trunk builds ok. Are there plans for version 0.32 release? |
From: Allen W. <wi...@kd...> - 2008-04-02 13:25:20
|
Howdy all libical developers, Just wanted to introduce myself... I'm Allen Winter, the KDE PIM module coordinator and the current KOrganizer maintainer. My main goal is to remove the KDE PIM version of libical and depend on the external version for the upcoming KDE 4.1 release. So, here's to success! Cheers. -Allen |
From: w.goesgens <w.g...@ou...> - 2008-01-29 22:19:08
|
<html><body> <p>Hy Terry, </p><p>thanks for having a look. I think we'll let that=20= WTF inside for at least one more release, as we first need to join them,=20= before we can punish them ;-) </p><p>To be onest both versions of code in= icalmimetype.c look suspect to me... that was the reason why= i didn't know which one to prefer. I didn't have the time to inv= estigate how i can trigger that code yet.<br /> </p><blockquote>Tue Jan 2= 9 2008 21:01:20 CET from Terry Wilson to fre...@li...ur= ceforge.net <br />Subject: [Freeassociation-devel] [patch] TODOs in icalp= roperty.c and icalmime.c<br /><br />The TODO: WTF? in icalproperty.c see= ms to be just a deprecation<br />warning from when the name of the functi= on icalproperty_get_name was<br />renamed to icalproperty_get_property_na= me--I'm assuming to be more in<br />line with the other function name= s. This seems to have been<br />deprecated since 2002. I did a search o= n krugle.org and it looks like<br />maybe a couple of instances in KDE mi= ght still use the old function<br />name, but of course it is a quick fix= for them--I would say if<br />something has been deprecated for 6 years,= you can safely remove it in<br />a new release. :-) Not that it hurts=20= to keep it around, but why<br />deprecate something if you never intend t= o take it out, right? I'd<br />just say make them aware that it is r= eally going away finally and<br />update the line or two of code that the= y use it for.<br /><br />The icalmimetype.c TODO is a little more confusi= ng. It looks like the<br />evolution version might be the way to go as &= #39;part' is dynamically<br />allocated by new_part and never freed a= nywhere if we use the KDE<br />version. I don't have time right now=20= to try to whip something up and<br />test with valgrind, but it looks lik= e the currently uncommented<br />version is the way to go to me. Looks l= ike they were both trying to<br />solve the same issue, but went about it= different ways (referencing<br />impl after freeing it).<br /><br />Atta= ching patches just for fun removing long-deprecated function and<br />rem= oving commented out KDE version of icalmime_text_end_part().<br /><br /><= br /></blockquote> </body></html> |
From: Terry W. <te...@lo...> - 2008-01-29 20:02:34
|
The TODO: WTF? in icalproperty.c seems to be just a deprecation warning from when the name of the function icalproperty_get_name was renamed to icalproperty_get_property_name--I'm assuming to be more in line with the other function names. This seems to have been deprecated since 2002. I did a search on krugle.org and it looks like maybe a couple of instances in KDE might still use the old function name, but of course it is a quick fix for them--I would say if something has been deprecated for 6 years, you can safely remove it in a new release. :-) Not that it hurts to keep it around, but why deprecate something if you never intend to take it out, right? I'd just say make them aware that it is really going away finally and update the line or two of code that they use it for. The icalmimetype.c TODO is a little more confusing. It looks like the evolution version might be the way to go as 'part' is dynamically allocated by new_part and never freed anywhere if we use the KDE version. I don't have time right now to try to whip something up and test with valgrind, but it looks like the currently uncommented version is the way to go to me. Looks like they were both trying to solve the same issue, but went about it different ways (referencing impl after freeing it). Attaching patches just for fun removing long-deprecated function and removing commented out KDE version of icalmime_text_end_part(). |
From: w.goesgens <w.g...@ou...> - 2008-01-29 18:37:34
|
<html><body> <p>Thanks, Terry. </p><p>your Patch is applied. there are two more of tho= se TODO's in the source which remained from the merger of Evolution a= nd Kcal fork backpatching action. If you've got a sugestion for these= too, be welcome ;-)</p><p>The mailinglist which caries the anouncements=20= and so on is at li...@so...; this one mostly just ca= ries the commit comments.</p><p>We're hoping to release the 0.30 with= in the next two weeks. Outstanding points are the two TODO's mentione= d above, and getting a working cmake implementation, so libkcal can use t= he upstream libical again. </p><blockquote>Tue Jan 29 2008 03:36:06=20= CET from Terry Wilson to fre...@li... <br=20= />Subject: [Freeassociation-devel] [patch] Problem using icalcomponent_fo= reach_recurrence() with time filters<br /><br />Ok, I've spent a whil= e tracking this down and think I have a suitable<br />fix for it.<br /><b= r />Situation:<br /><br />I need to parse a calendar for whether or not s= omeone is busy over a<br />particular timeframe. As an example:<br />...= <br /> calendar =3D icalparser_parse_string(calendar_text);<br /><br=20= /> utc_zone =3D icaltimezone_get_utc_timezone();<br /> start =3D=20= icaltime_current_time_with_zone(utc_zone);<br /> end =3D icaltime_cur= rent_time_with_zone(utc_zone);<br /> end.hour +=3D 1;<br /> icalt= ime_normalize(end);<br /><br /> for(iter =3D icalcomponent_get_first_= component(calendar,<br />ICAL_VEVENT_COMPONENT); iter; iter =3D<br />ical= component_get_next_component(calendar, ICAL_VEVENT_COMPONENT)) {<br /> =20= icalcomponent_foreach_recurrence(iter, start, end, callback,<br />N= ULL);<br /> }<br /><br />There are two problems. The first is that t= he VEVENT does not have<br />VTIMEZONEs locally, but they are in the pare= nt so matching the TZID<br />with a VTIMEZONE fails. There are two copie= s of<br />icalcomponent_get_datetime in the source. One is commented out= with a<br />TODO trying to figure out which one to use. The one that i= s<br />currently uncommented checks for the VTIMEZONE in the component.<b= r />Since this is being called from the _get_dtstart function, it will<br= />almost always fail to find the VTIMEZONE, so dtstart will be returned<= br />without a timezone. The one that is commented out, searches parents= <br />until it finds the VTIMEZONE to compare against. This seems to be=20= the<br />correct way to go about things.<br /><br />The second problem is= that the dtstart is not being converted to UTC<br />in this situation be= cause icalcomponent_foreach_recurrence() calls<br />icaltime_span_new(dts= tart, dtend, 1) which in turn calls<br />icaltime_as_timet_with_zone(dtst= art,<br />icaltimezone_get_utc_timezone()). Now, dtstart in my case is G= MT -6.<br />If you look in icaltimezone_convert_time, you will see that i= t returns<br />early because this means that we would be trying to conver= t from UTC<br />to UTC--completely ignoring the actual timezone of the dt= start.<br /><br />Attatched is a patch that changes which icalcomponent_g= et_datetime to<br />use, as well as fixes icaltime_span_new to call<br />= icaltime_as_timet_with_zone with the correct zone of the start/end of<br=20= />the span if it exists. I also have sample data and sample code<br />ex= ploiting the bug if it is helpful.<br /><br />Terry Wilson<br /><br /></b= lockquote> </body></html> |
From: Terry W. <te...@lo...> - 2008-01-29 02:36:34
|
Ok, I've spent a while tracking this down and think I have a suitable fix for it. Situation: I need to parse a calendar for whether or not someone is busy over a particular timeframe. As an example: ... calendar = icalparser_parse_string(calendar_text); utc_zone = icaltimezone_get_utc_timezone(); start = icaltime_current_time_with_zone(utc_zone); end = icaltime_current_time_with_zone(utc_zone); end.hour += 1; icaltime_normalize(end); for(iter = icalcomponent_get_first_component(calendar, ICAL_VEVENT_COMPONENT); iter; iter = icalcomponent_get_next_component(calendar, ICAL_VEVENT_COMPONENT)) { icalcomponent_foreach_recurrence(iter, start, end, callback, NULL); } There are two problems. The first is that the VEVENT does not have VTIMEZONEs locally, but they are in the parent so matching the TZID with a VTIMEZONE fails. There are two copies of icalcomponent_get_datetime in the source. One is commented out with a TODO trying to figure out which one to use. The one that is currently uncommented checks for the VTIMEZONE in the component. Since this is being called from the _get_dtstart function, it will almost always fail to find the VTIMEZONE, so dtstart will be returned without a timezone. The one that is commented out, searches parents until it finds the VTIMEZONE to compare against. This seems to be the correct way to go about things. The second problem is that the dtstart is not being converted to UTC in this situation because icalcomponent_foreach_recurrence() calls icaltime_span_new(dtstart, dtend, 1) which in turn calls icaltime_as_timet_with_zone(dtstart, icaltimezone_get_utc_timezone()). Now, dtstart in my case is GMT -6. If you look in icaltimezone_convert_time, you will see that it returns early because this means that we would be trying to convert from UTC to UTC--completely ignoring the actual timezone of the dtstart. Attatched is a patch that changes which icalcomponent_get_datetime to use, as well as fixes icaltime_span_new to call icaltime_as_timet_with_zone with the correct zone of the start/end of the span if it exists. I also have sample data and sample code exploiting the bug if it is helpful. Terry Wilson |
From: Harrie H. <ha...@in...> - 2004-08-06 07:58:24
|
HI, Attached a patch that would add C++ classes for the libicalcap part to wrap a session and channel. Harrie |
From: Harrie H. <ha...@in...> - 2004-08-05 11:43:08
|
HI, Attached patch adds extra methods to have also 'pointer passing'. Harrie |
From: Harrie H. <ha...@in...> - 2004-08-05 10:55:10
|
HI, ATtached patch adds a clone method to the VComponent class that is 'equivalent' as the one of icalcomponent. Harrie |
From: Harrie H. <ha...@in...> - 2004-08-05 09:27:37
|
HI, The attached patch (new-classes.patch) adds classes for ICalTime and ICalDuration. The changes related to the move of code from src/libical/icaltimezone.h into src/libical/icaltimezoneimpl.h are needed to hide the implementation details from the outer layer (interface). The second patch adds methods to existing classes that can then utilize the new classes. (This patch can only work with the first one) Hope these patches can be added. Harrie |
From: Harrie H. <ha...@in...> - 2004-08-05 09:17:41
|
HI, I have been working with the C++ version of this library and will post some patches which hopefully can be applied. This first one is a compilation fix due to a type change. Harrie |
From: Mark B. <ma...@ea...> - 2004-04-17 16:30:16
|
On Saturday 17 April 2004 2:13 am, Behdad Esfahbod wrote: > Hi, > > Can someone please guide me about where is the libical > development taking place these days? Check the kde-pim archives (http://lists.kde.org) and look for a 2004-04-14 post by Shaheed with the subject "Cleaning up libical." He is planning on putting some time into libical. Regards, Mark |
From: Behdad E. <be...@cs...> - 2004-04-17 06:13:39
|
Hi, Can someone please guide me about where is the libical development taking place these days? Thanks --behdad behdad.org |
From: Mark B. <ma...@hu...> - 2003-11-15 20:23:11
|
I'm trying to get the Python bindings for libical working on Windows. I can import LibicalWrap in the Python interpreter, but when I run the test.py program, I get access violation errors. Below are the steps I followed to get as far as I did. If anyone has any suggestions for possible next steps, please let me know. 1. Install Cygwin (with Perl, sed, bash) 2. Check out libical CVS (latest tarball does not have VC++ project files) 3. Open libical.dsp 4. Build -> Build libical.lib (stops--VC++ doesn't know about sh) 5. From cygwin prompt, run a bash script that contains the three calls to mkderivedvalues.pl and the call to mkinclude.sh (cut and paste from the dsp file). 6. Back in VC++, run Build -> Build libical.lib. If it doesn't work, repeat step 5 and retry. 7. Open libicalss.dsp 8. Build all 9. Install swig. 10. Copy libical.lib, libicalss.lib, ical.h, icalss.h and contents of ..\libical\src\python directory to a temp directory. 11. run "swig -python LibicalWrap.i 12. Copy the swig dsp file from ...\Examples\python\simple 13. Change output name to _libicalwrap.dll 14. In Project Settings, C/C++ tab, General Category, change the Project Option list to include /MD instead of /MT. (Or maybe the other way around--all three dsp files must have the same setting--the defaults are the swig is one way and the two libical projects are the other way.) 15. Enter Python interpreter >>>import LibicalWrap >>>dir(LibicalWrap) >>> ... long list ... 16. At dos prompt, type python test.py Unhandled exception in python.exe (_LIBICALWRAP.DLL): 0xC00000005: Access Violation. I tried commenting out each test and rerunning, and the first six or seven tests give the same error. Regards, Mark |
From: Jonagustine L. <jon...@ya...> - 2003-07-07 21:31:52
|
Hello! I was wondering if the libical project is still alive. I'm currently working on a group calendar project for Zope (python based) and would like to implement RFC2445 compliant implementation on my project. I'd be interested in getting some synergy going between both projects if you guys are still interested. Looking forward to hearing from you. Jon http://www.plone.org/Members/jonlim/calendar_project/ __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Gary F. <gar...@js...> - 2002-07-12 14:35:51
|
Just you and me... fyi I am spending a bit of time with libical. I just updated my simple program that takes an ics file and spits out xml. I'll post what I have on the libical list. Gary Andrea Campi wrote: > On Fri, Jul 12, 2002 at 08:12:21AM -0500, Gary Frederick wrote: > >>I don't think so :-) >> > > > Yeah, I'd figured out ;-) > > >>Gary >> >>Andrea Campi wrote: >> >>>Is this forwarded to the real list? >>> >> >> > |
From: Andrea C. <a....@in...> - 2002-07-12 13:55:32
|
On Fri, Jul 12, 2002 at 08:12:21AM -0500, Gary Frederick wrote: > I don't think so :-) > Yeah, I'd figured out ;-) > Gary > > Andrea Campi wrote: > >Is this forwarded to the real list? > > > > -- Andrea Campi mailto:a....@in... I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy |
From: Gary F. <gar...@js...> - 2002-07-12 13:14:47
|
I don't think so :-) Gary Andrea Campi wrote: > Is this forwarded to the real list? > |
From: Andrea C. <a....@in...> - 2002-07-12 08:45:24
|
Is this forwarded to the real list? -- Andrea Campi mailto:a....@in... I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy |