From: David F. <da...@d2...> - 2005-05-11 17:43:33
|
I've gone quiet over the past few days because the overlapping functions has been kicking my ass. Every time I successfully fixed one problem, another one popped out of the woodwork. So, I'm going to take a step back and redo the code (since all the problems are in checkOverlap). This is a semi-crappy solution, as I could very well introduce new problems, but I guarantee we'll at least get full coverage (and I'll be better equipped to fix bugs as people report them, instead of my struggles to keeps shoehorning fixes into the existing structure). If you'd like to see the calendars i'm wrestling with, check out SF Bug #1017270. Overlapping info gets messed up depending on the weird overlappings setup, and this calendar (check out the week of 20040829, esp the end of the week, and when combined w/ Home.ics) has all kinds of weird overlapping going on. :) Still waiting to hear on all my other patches. dave |
From: Chad L. <ch...@ch...> - 2005-05-11 21:38:43
Attachments:
smime.p7s
|
Sorry Ive been preoccupied with another project. It might be a good time to note that when fixing bugs, to check that the calendar itself is properly written against IETF-2445. Most times iCal/Mozilla/ Sunbird files are ok... and generally we dont accept hand written ical files. It might also be good that we have a regression suite of test calendars for when we test any major code changes. The checkOverlap function was written by David Reindl who may be able to help you fix anything, although that function has been very stable over the past few years to my knowledge. -C On May 11, 2005, at 10:43 AM, David Fallon wrote: > I've gone quiet over the past few days because the overlapping > functions has been kicking my ass. Every time I successfully fixed > one problem, another one popped out of the woodwork. So, I'm going > to take a step back and redo the code (since all the problems are > in checkOverlap). This is a semi-crappy solution, as I could very > well introduce new problems, but I guarantee we'll at least get > full coverage (and I'll be better equipped to fix bugs as people > report them, instead of my struggles to keeps shoehorning fixes > into the existing structure). If you'd like to see the calendars > i'm wrestling with, check out SF Bug #1017270. Overlapping info > gets messed up depending on the weird overlappings setup, and this > calendar (check out the week of 20040829, esp the end of the week, > and when combined w/ Home.ics) has all kinds of weird overlapping > going on. :) Still waiting to hear on all my other patches. > > dave > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > |
From: <da...@d2...> - 2005-05-14 07:05:38
|
> Sorry Ive been preoccupied with another project. It might be a good > time to note that when fixing bugs, to check that the calendar itself > is properly written against IETF-2445. Most times iCal/Mozilla/ > Sunbird files are ok... and generally we dont accept hand written > ical files. Yup - the calendar files w/ that bug are correct, and render fine once the overlap code is working properly. So, a quick status report on that - I finished the rewrite yesterday, and spent most of the day testing. While this is a bogus situation - rewriting a piece like this from scratch when we're trying to stabilize - please believe me that I spent 2 days trying to shoehorn the "right" way into the existing code, and kept running into fundamental flaws in how it worked. I then gave up, spend the next 2 days rewriting everything from scratch, and then spent today testing. If it's worth it, I'd be happy to go into more technical detail why there were things that just wouldn't work properly using the existing logic, and how my rewrite should be more foolproof. I've also tried to make the code as low-impact as possible - I've only reworked the overlap code, and it seems to work fine in all the trivial cases, so worst case, we'll find some bugs in the already-messed-up edge cases (which I will promptly fix, now understanding the code). As an added benefit, the code is cleaned up, semi-faster (it's probably about the same or even slower, actually, because it's much more rigorous in generating correct overlap_arrays, but the base-cases should be faster), and more modular. And now should work regardless of the craziness of your overlap setup. So, here's my proposal - I'd like to commit this, my openevent cleanup patch, and then finish going through the remaining bugs (I think there's only one or two more relevant ones). Once that's done, we should release a 2.0b2, wait a week or 2, and release 2.0. :) Hopefully w/ website at the same time. So, barring any complaints, I'll commit my code next week (with suitable announcements, etc.) - all you loyal readers, please try CVS at that point and let me know if you run into anything! I will fix it if I know about it. > It might also be good that we have a regression suite of test > calendars for when we test any major code changes. The checkOverlap > function was written by David Reindl who may be able to help you fix > anything, although that function has been very stable over the past > few years to my knowledge. Yeah, a regression test suite would be interesting - we could hack something up that wget'd specific calendar+date+page combos, then compared that to the "known good" render. Would help with the testing a lot, esp. with some of the overlap issues (you get fun problems depending on the order you load the calendars, as the various events create new overlap blocks and/or merge the blocks). I'll take a look at setting something up next week, as well. dave |