Re: [Evolution-hackers] [PATCH][RFC] Deal with negative intervals

2011-02-22 Thread Carlos Martín Nieto 
On Wed, 2011-02-23 at 10:22 +1300, Andrew McMillan wrote:
 [...]
 My only quibble is that any program should report on a client that
 creates bogus data, so I should like to see some kind of warning message
 written in the logs at this point.

 Good point. The patch I've just pushed uses g_warning() to say what
rule caused the error (as I don't think we can get any other
information).

   cmn
-- 
Carlos Martín Nietohttp://www.cmartin.tk

¿Cómo voy a decir bobadas si soy mudo? -- CACHAI


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 ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] [PATCH][RFC] Deal with negative intervals

2011-02-21 Thread Carlos Martín Nieto 
Hi,

 Dealing with the error I posted about on another thread, I found that
Google is giving me some recurring events with an interval of -1, which
causes evo to search for all years from 2011 to -1, when it errors out
because it's no longer a valid time_t (which I guess also explains why
it sometimes seems to stop responding for a bit).

 I'm not sure how I managed to create them, but the Google calendar web
interface manages to display them correctly. As a fix for this
behaviour, I've changed the library to use the absolute value (which
also has the added advantage that these entries are now displayed).

 I can push the change in myself if people are in favour, but I wanted
to ask, as this could be considered quite wrong.

   cmn

---
 calendar/libecal/e-cal-recur.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/calendar/libecal/e-cal-recur.c
b/calendar/libecal/e-cal-recur.c
index 3c30618..87e430c 100644
--- a/calendar/libecal/e-cal-recur.c
+++ b/calendar/libecal/e-cal-recur.c
@@ -996,7 +996,8 @@ e_cal_recur_from_icalproperty (icalproperty *prop,
gboolean exception,
ir = icalproperty_get_rrule (prop);
 
r-freq = ir.freq;
-   r-interval = ir.interval;
+   /* Invervals of -1 have been spotted in the wild (Google) */
+   r-interval = abs(ir.interval);
 
   r-enddate = e_cal_recur_obtain_enddate (ir, prop, zone,
convert_end_date);

-- 
Carlos Martín Nietohttp://www.cmartin.tk

¿Cómo voy a decir bobadas si soy mudo? -- CACHAI


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 ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535

2011-02-21 Thread Carlos Martín Nieto 
On Tue, 2011-02-22 at 11:30 +1300, Andrew McMillan wrote:
 [...]
 Hi Carlos,
 
 From RFC5545:
 
   The INTERVAL rule part contains a positive integer representing at
   which intervals the recurrence rule repeats.  The default value is
   1, meaning every second for a SECONDLY rule, every minute for a
   MINUTELY rule, every hour for an HOURLY rule, every day for a
   DAILY rule, every week for a WEEKLY rule, every month for a
   MONTHLY rule, and every year for a YEARLY rule.  For example,
   within a DAILY rule, a value of 8 means every eight days.
 
 So yes: 0 is also invalid, as you would expect :-)

 A very reasonable thing for the RFC to say :) This should probably be
done in libical, but within e-d-s it the following patch probably makes
more sense than the one I posted on the other thread (Deal with
negative intervals)

[PATCH] ECalRecur: Convert negative intervals into the default (1)

Negative intervals have been spotted in the wild. An interval lower
than 1 doesn't make any sense, so if we see one, we replace it by the
default iCal interval of 1.
---
 calendar/libecal/e-cal-recur.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/calendar/libecal/e-cal-recur.c b/calendar/libecal/e-cal-recur.c
index 3c30618..9eda66a 100644
--- a/calendar/libecal/e-cal-recur.c
+++ b/calendar/libecal/e-cal-recur.c
@@ -996,7 +996,8 @@ e_cal_recur_from_icalproperty (icalproperty *prop, gboolean 
exception,
ir = icalproperty_get_rrule (prop);
 
r-freq = ir.freq;
-   r-interval = ir.interval;
+   /* Interval  1 doesn't make sense, so use the default. */
+   r-interval = ir.interval  1 ? 1 : ir.interval;
 
   r-enddate = e_cal_recur_obtain_enddate (ir, prop, zone, convert_end_date);

-- 
Carlos Martín Nietohttp://www.cmartin.tk

¿Cómo voy a decir bobadas si soy mudo? -- CACHAI


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 ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535

2011-02-16 Thread Carlos Martín Nieto 
Hi all,

 I'm running evo master, and I've been getting weird messages, about the
year being below 1900 (the assert in libecal's time_days_in_month().
I've put a g_print() statement to print the year on each run. The
messages scroll too fast for me to see each one, but I could see the
years counting down from ~2000 to what I paste below.

 I've attached the backtrace for a year of 167 (I think) though I don't
think it gives much information. This happens even if I have my main
calendar off (which I think it's the only one with recurring events).

 Any hints as to what should be investigated next?

--8-8
(e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month:
assertion `year = 1900' failed
Year: 0

(e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month:
assertion `year = 1900' failed
Year: 0

(e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month:
assertion `year = 1900' failed
Year: 65535

(e-calendar-factory:22846): libecal-WARNING **: time_t out of range
Year: 2011
Year: 2011

   cmn
-- 
Carlos Martín Nietohttp://www.cmartin.tk

¿Cómo voy a decir bobadas si soy mudo? -- CACHAI
#0  0xf7700425 in __kernel_vsyscall ()
#1  0xf686801b in write () at ../sysdeps/unix/syscall-template.S:82
#2  0xf672cd66 in write_string (fd=2, 
string=0x930c7f0 \n(e-calendar-factory:22846): libecal-CRITICAL **: 
time_days_in_month: assertion `year = 1900' failed\n) at gmessages.c:140
#3  0xf672d10f in g_log_default_handler (log_domain=0xf76f6b14 libecal, 
log_level=value optimized out, 
message=0x930c7b8 time_days_in_month: assertion `year = 1900' failed, 
unused_data=0x0) at gmessages.c:998
#4  0xf672d515 in g_logv (log_domain=0xf76f6b14 libecal, 
log_level=G_LOG_LEVEL_CRITICAL, 
format=0xf679c0b8 %s: assertion `%s' failed, 
args1=0xffe1040c \220\237o\367Ҟo\367\020) at gmessages.c:527
#5  0xf672d992 in g_log (log_domain=0xf76f6b14 libecal, 
log_level=G_LOG_LEVEL_CRITICAL, 
format=0xf679c0b8 %s: assertion `%s' failed) at gmessages.c:577
#6  0xf672db8d in g_return_if_fail_warning (log_domain=0xf76f6b14 libecal, 
pretty_function=0xf76f9f90 time_days_in_month, 
expression=0xf76f9ed2 year = 1900) at gmessages.c:586
#7  0xf76e5587 in time_days_in_month (year=167, month=3)
at e-cal-time-util.c:450
#8  0xf76dfe89 in cal_obj_time_add_days (cotime=0xffe10920, 
days=value optimized out) at e-cal-recur.c:3424
#9  0xf76e08e3 in cal_obj_weekly_find_next_position (cotime=0xffe10920, 
event_end=0xffe10928, recur_data=0xffe10544, interval_end=0xffe10b04)
at e-cal-recur.c:2299
#10 0xf76e28e4 in cal_obj_expand_recurrence (
event_start=value optimized out, zone=value optimized out, 
recur=0x92e6858, interval_start=0xffe10b0c, interval_end=0xffe10b04, 
finished=0xffe10b4c) at e-cal-recur.c:1589
#11 0xf76e3aba in generate_instances_for_chunk (comp=value optimized out, 
prop=value optimized out, start=1297638000, end=129807, 
cb=0xf66b5b60 check_instance_time_range_cb, cb_data=0x92f6210, 
tz_cb=0xf66b61c0 resolve_tzid, tz_cb_data=0x92f6210, 
default_timezone=0xf546b0f0) at e-cal-recur.c:1186
#12 e_cal_recur_generate_instances_of_rule (comp=value optimized out, 
prop=value optimized out, start=1297638000, end=129807, 
cb=0xf66b5b60 check_instance_time_range_cb, cb_data=0x92f6210, 
tz_cb=0xf66b61c0 resolve_tzid, tz_cb_data=0x92f6210, 
default_timezone=0xf546b0f0) at e-cal-recur.c:865
#13 0xf66b6daf in func_occur_in_time_range (esexp=0x92fb6b0, argc=2, 
argv=0xffe10be0, data=0x92f6210) at e-cal-backend-sexp.c:390
#14 0xf668f6c3 in e_sexp_term_eval (f=0x92fb6b0, t=0x92fc2c0) at e-sexp.c:731
#15 0xf6690060 in term_eval_and (f=0x92fb6b0, argc=2, argv=0x92fc430, 
data=0xf669f080) at e-sexp.c:271
#16 0xf668f79b in e_sexp_term_eval (f=0x92fb6b0, t=0x92fc1d0) at e-sexp.c:721
#17 0xf668f83d in e_sexp_eval (f=0x92fb6b0) at e-sexp.c:1568
#18 0xf66b763e in e_cal_backend_sexp_match_comp (sexp=0xf546bd50, 
comp=0x9258130, backend=0x9227210) at e-cal-backend-sexp.c:1323
#19 0xf5ee644a in caldav_start_query (backend=0x9227210, query=0x9219218)
at e-cal-backend-caldav.c:4196
#20 0xf66b0f98 in e_cal_backend_start_query (backend=0x9227210, 
query=0x9219218) at e-cal-backend.c:818
#21 0xf66c5bd6 in impl_DataCalView_start (object=0x9215730, 
invocation=0x92cd3b0, query=0x9219218) at e-data-cal-view.c:314
#22 0xf76f6964 in _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT (
closure=0x92f9d98, return_value=0xffe10f64, n_param_values=2, 
param_values=0x922e800, invocation_hint=0xffe10f50, 
marshal_data=0xf66c5b50) at e-gdbus-marshallers.c:202
#23 0xf68e79f2 in g_closure_invoke (closure=0x92f9d98, 
return_value=0xffe10f64, n_param_values=2, param_values=0x922e800, 
invocation_hint=0xffe10f50) at gclosure.c:767
#24 0xf690118d in signal_emit_unlocked_R (node=value optimized out, 
detail=value optimized out, instance=0x9215730, 
emission_return=0xffe110bc