From matt-icalendar at mosuki.com  Mon Nov  6 07:27:06 2006
From: matt-icalendar at mosuki.com (Matt Chisholm)
Date: Sun, 5 Nov 2006 22:27:06 -0800
Subject: [icalendar-dev] feature suggestion & patch
Message-ID: <20061106062706.GB23456@theory.org>

Hi all.  I'm using the icalendar package to convert iCalendar files
into an internal database that's not too different than iCalendar.

Any program that wants to calculate recurring event dates basically
has to perform the parsing done in vWeekday.__init__() in prop.py on
'BYDAY' fields of 'RRULE' properties.  This method uses the regular
expression WEEKDAY_RULE to turn strings like '1SU' or '-2FR' into
structured representations that mean repetitions like "first sunday"
or "second to last friday".

Rather than duplicate this work internally in our program, it seems to
make more sense to modify the vWeekday object to store the results of
this parsing.  The value has to be parsed to make sure it's valid
iCalendar format anyway, but vWeekday.__init__() throws away the
results of the parse.

So, here's a patch that modifies vWeekday.__init__() to store the
results of parsing the string values of BYDAY fields on the vWeekday
object.

-matt

-------------- next part --------------
Index: src/icalendar/prop.py
===================================================================
--- src/icalendar/prop.py	(revision 34254)
+++ src/icalendar/prop.py	(working copy)
@@ -754,7 +754,12 @@
         relative = match['relative']
         if not weekday in vWeekday.week_days or sign not in '+-':
             raise ValueError, 'Expected weekday abbrevation, got: %s' % self
+        self.weekday_number = vWeekday.week_days[weekday]
         self.relative = relative and int(relative) or None
+        if self.relative:
+            self.offset_number = int(relative)
+            if sign == '-':
+                self.offset_number *= -1
         self.params = Parameters()
 
     def ical(self):

From regebro at gmail.com  Wed Nov 22 18:07:02 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 22 Nov 2006 18:07:02 +0100
Subject: [icalendar-dev] A minor bug
In-Reply-To: <1161772968.5648.1.camel@localhost.localdomain>
References: <1161772968.5648.1.camel@localhost.localdomain>
Message-ID: <319e029f0611220907l6b3d8544v60f25531a3939e2c@mail.gmail.com>

On 10/25/06, Michael Smith <msmith at fluendo.com> wrote:
> We're trying to use your icalendar module here - which is working
> nicely, thanks. We automatically run pychecker over our codebase on
> every commit, though, and it's picking a bug up in caselessdict.py.
>
> Here's a simple patch.

I included that in trunk.

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/

From regebro at gmail.com  Wed Nov 22 19:44:55 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 22 Nov 2006 19:44:55 +0100
Subject: [icalendar-dev] Possible bug: Linebreaks mess up unicode?
In-Reply-To: <80127d8a0610190349o4a25dd62p2ad948f1cdc95041@mail.gmail.com>
References: <80127d8a0610190349o4a25dd62p2ad948f1cdc95041@mail.gmail.com>
Message-ID: <319e029f0611221044h41be62c9k177d75d03f26128d@mail.gmail.com>

On 10/19/06, Brad <ykardia at gmail.com> wrote:
> Hi,
>
> just tried loading a python-icalendar-generated ics file in the new
> Sunbird, and it complained that it wasn't utf-8. I investigated, and
> found that it looks as if the unicode is possibly messed up by the
> linebreaking. The same file shows up fine in Apple iCal and in Novell
> Evolution, so it is possible that Sunbird is just being too strict.

Well, it probably tries to UTF-8 decode it before it unfolds. I seem
to remember some versions of Sunbird not unfolding lines at all, so
that may be the issue.

However, folding in the middle of a UTF-8 character is bad, and
discussion on the ietf-calsify list has clarified the spec to say that
you are not allowed to do this (although you are allowed to split in
the middle of a UTF-8 character sequence).
The reason for that is that the file should still be viewable in UTF-8
aware editors and viewers.

This means that if you write ? with the unicode composing sequence
u+", it may break in the middle of these characters. The reason for
that is that composing sequences (at least in theory) can be longer
than 75 octets.

So, I have now implemented this in trunk (and it will be included in
the 1.1 release I plan to do Really Soon Now).

I think that makes trunk Bug Free (tm). :) Or does anybody know of any
other issues?

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/

From maxm at mxm.dk  Wed Nov 22 22:40:26 2006
From: maxm at mxm.dk (Max M)
Date: Wed, 22 Nov 2006 22:40:26 +0100
Subject: [icalendar-dev] Possible bug: Linebreaks mess up unicode?
In-Reply-To: <319e029f0611221044h41be62c9k177d75d03f26128d@mail.gmail.com>
References: <80127d8a0610190349o4a25dd62p2ad948f1cdc95041@mail.gmail.com>
	<319e029f0611221044h41be62c9k177d75d03f26128d@mail.gmail.com>
Message-ID: <4564C3CA.7070605@mxm.dk>

Lennart Regebro skrev:
> On 10/19/06, Brad <ykardia at gmail.com> wrote:

> I think that makes trunk Bug Free (tm). :) Or does anybody know of any
> other issues?

Oh .. sweet. One of those annoyning things on my todo, that I never gor 
around to has magically dissapeared.

I think you have fixed the only two reported bugs.

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

Phone:  +45 46 93 23 92
Mobile: +45 29 93 42 96


From regebro at gmail.com  Thu Nov 23 09:29:58 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Nov 2006 09:29:58 +0100
Subject: [icalendar-dev] Possible bug: Linebreaks mess up unicode?
In-Reply-To: <4564C3CA.7070605@mxm.dk>
References: <80127d8a0610190349o4a25dd62p2ad948f1cdc95041@mail.gmail.com>
	<319e029f0611221044h41be62c9k177d75d03f26128d@mail.gmail.com>
	<4564C3CA.7070605@mxm.dk>
Message-ID: <319e029f0611230029s357105b3r3fe2648c406c13e4@mail.gmail.com>

On 11/22/06, Max M <maxm at mxm.dk> wrote:
> Lennart Regebro skrev:
> > On 10/19/06, Brad <ykardia at gmail.com> wrote:
>
> > I think that makes trunk Bug Free (tm). :) Or does anybody know of any
> > other issues?
>
> Oh .. sweet. One of those annoyning things on my todo, that I never gor
> around to has magically dissapeared.
>
> I think you have fixed the only two reported bugs.

Super. I'll release a 1.1 today. I remember that I failed in updating
the website last time, I'll try again. :-)
-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/

From regebro at gmail.com  Thu Nov 23 14:42:56 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Nov 2006 14:42:56 +0100
Subject: [icalendar-dev] icalendar 1.1 released.
Message-ID: <319e029f0611230542r2afa7847i833d40d1d74c90eb@mail.gmail.com>

Since nobody could remember any more bugs to fix, I released icalendar 1.1.
It's released in tgz format, but also as an egg on Cheese Shop.

http://cheeseshop.python.org/pypi/icalendar

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/

From regebro at gmail.com  Thu Nov 23 17:23:21 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Nov 2006 17:23:21 +0100
Subject: [icalendar-dev] icalendar 1.1 released.
In-Reply-To: <319e029f0611230542r2afa7847i833d40d1d74c90eb@mail.gmail.com>
References: <319e029f0611230542r2afa7847i833d40d1d74c90eb@mail.gmail.com>
Message-ID: <319e029f0611230823k5f634c1cj39b7fc8f32da0bdf@mail.gmail.com>

On 11/23/06, Lennart Regebro <regebro at gmail.com> wrote:
> Since nobody could remember any more bugs to fix, I released icalendar 1.1.
> It's released in tgz format, but also as an egg on Cheese Shop.
>
> http://cheeseshop.python.org/pypi/icalendar

Although of course, my bugfix had another bug... I fixed that too, but
I'll wait a couple of days with a new release so people get a chance
to test it. ;)

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/

From regebro at gmail.com  Mon Nov 27 11:53:17 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Nov 2006 11:53:17 +0100
Subject: [icalendar-dev] icalendar 1.2 released.
Message-ID: <319e029f0611270253s56ab7829s2752acc7df16e69e@mail.gmail.com>

Includes the bugfix for the bugfix. :-)
Are there any lists, like python-announce or anything, that things
like these should be annouced to?

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/

From matt-icalendar at mosuki.com  Tue Nov 28 21:48:13 2006
From: matt-icalendar at mosuki.com (Matt Chisholm)
Date: Tue, 28 Nov 2006 12:48:13 -0800
Subject: [icalendar-dev] feature suggestion & patch
In-Reply-To: <20061106062706.GB23456@theory.org>
References: <20061106062706.GB23456@theory.org>
Message-ID: <20061128204813.GC9128@theory.org>

Congratulations on the 1.1 / 1.2 releases.  I sent in this patch a
while back, and I see that it hasn't been merged.  Did it get left out
accidentally or on purpose?

If you think it's not worth merging, that's fine with me.  It's not
really that important.  :) I just wanted to make sure it didn't get
left out accidentally.

-matt

On Nov  5 2006, 22:27, Matt Chisholm wrote:
>Hi all.  I'm using the icalendar package to convert iCalendar files
>into an internal database that's not too different than iCalendar.
>
>Any program that wants to calculate recurring event dates basically
>has to perform the parsing done in vWeekday.__init__() in prop.py on
>'BYDAY' fields of 'RRULE' properties.  This method uses the regular
>expression WEEKDAY_RULE to turn strings like '1SU' or '-2FR' into
>structured representations that mean repetitions like "first sunday"
>or "second to last friday".
>
>Rather than duplicate this work internally in our program, it seems to
>make more sense to modify the vWeekday object to store the results of
>this parsing.  The value has to be parsed to make sure it's valid
>iCalendar format anyway, but vWeekday.__init__() throws away the
>results of the parse.
>
>So, here's a patch that modifies vWeekday.__init__() to store the
>results of parsing the string values of BYDAY fields on the vWeekday
>object.
>
>-matt
>

>Index: src/icalendar/prop.py
>===================================================================
>--- src/icalendar/prop.py	(revision 34254)
>+++ src/icalendar/prop.py	(working copy)
>@@ -754,7 +754,12 @@
>         relative = match['relative']
>         if not weekday in vWeekday.week_days or sign not in '+-':
>             raise ValueError, 'Expected weekday abbrevation, got: %s' % self
>+        self.weekday_number = vWeekday.week_days[weekday]
>         self.relative = relative and int(relative) or None
>+        if self.relative:
>+            self.offset_number = int(relative)
>+            if sign == '-':
>+                self.offset_number *= -1
>         self.params = Parameters()
> 
>     def ical(self):

>_______________________________________________
>icalendar-dev mailing list
>icalendar-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/icalendar-dev


 LocalWords:  py

From regebro at gmail.com  Wed Nov 29 14:41:06 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 29 Nov 2006 14:41:06 +0100
Subject: [icalendar-dev] feature suggestion & patch
In-Reply-To: <20061128204813.GC9128@theory.org>
References: <20061106062706.GB23456@theory.org>
	<20061128204813.GC9128@theory.org>
Message-ID: <319e029f0611290541w730540b5kf54c9bb8fa9dda01@mail.gmail.com>

On 11/28/06, Matt Chisholm <matt-icalendar at mosuki.com> wrote:
> Congratulations on the 1.1 / 1.2 releases.  I sent in this patch a
> while back, and I see that it hasn't been merged.  Did it get left out
> accidentally or on purpose?

Probably both. :)

> If you think it's not worth merging, that's fine with me.  It's not
> really that important.  :) I just wanted to make sure it didn't get
> left out accidentally.

Well, it's a feature, and I have only cared about bugfixes so far.
There may be more parameters that could benefit from closer and more
detailed parsing, we could take a look for that for a 2.0 version.
Also there is a TODO left in the TODO file, that is also related to
more detailed parsing if I understand correctly (although I don't
exactly know what it is that should be done).

What does MaxM think?

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.nuxeo.org/