From: David R. <da...@ha...> - 2010-03-04 02:52:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, I hope this is not going to turn out to be another Pebkac for me ;) Have you foreseen the possibility of tweaking the recurring events parser to not parse monthly recurring events by date (i.e. each 6th of a month) but by days of the week (i.e. every first Saturday of a month)? Actually, there are two possibilities to do this (or let's rather say, two that I thought of, not being familiar with the SMWDataValueFactory). The first and, IMHO simplest, being: Index: SMW_ParserExtensions.php =================================================================== - --- SMW_ParserExtensions.php (revision 63234) +++ SMW_ParserExtensions.php (working copy) @@ -416,6 +416,14 @@ $date_str = "$cur_year-$cur_month-$cur_day $cur_time"; $cur_date = SMWDataValueFactory::newTypeIDValue('_dat', $date_str); $cur_date_jd = $cur_date->getNumericValue(); + } elseif($unit == 'xofmonth') { + $check_month = $cur_date->getMonth(); + $cur_date_jd += 28 * $period; + $cur_date = SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); + if ($cur_date->getMonth() != (($check_month + $period) % 12 )){ + $cur_date_jd += 7; // add another week + $cur_date = SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); + } } else { // $unit == 'day' or 'week' // assume 'day' if it's none of the above $cur_date_jd += ($unit === 'week') ? 7 * $period : $period; Either there is no way to not have to calculate $cur_date twice, or I'm just too tired to find it. Here's the actual data: Setting [0] and Browsing [1] The other possibility would be to look up what day of the week [date(N)] and in what quarter of the month the $cur_day is [$cur_day ceil($cur_day / 7)] is and then ask php for every "xth $dayOfWeek" in the subsequent "$cur_month += $period". But that seems more complicated than method one. cheers, D. [0] https://www.hackerspace.lu/w/index.php?title=Sandbox&action=edit§ion=1 [1] https://www.hackerspace.lu/wiki/Special:Browse?title=Special%3ABrowse&article=Sandbox - -- HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg July 22nd till July 25th 2010, in Dudelange, Luxembourg Register Now: http://events.hackerspace.lu/camp/2010/ - ---- mailto:da...@ha... xmpp:kw...@ja... mobile: +43 650 73 63 834 | +352 691 44 23 24 ++++++++++++++++++++++++++++++++++++++++++++ Wear your geek: http://syn2cat.spreadshirt.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuPIEMACgkQYTtdUdP5zDeBEwCgtwu69suVdVTqtsS4AqtNhiTZ c/oAn1ZSNypHIHZVJh9xk2hETiL6SOHE =/C/s -----END PGP SIGNATURE----- |
From: Yaron K. <ya...@gm...> - 2010-03-04 03:27:50
|
Hi, No, this one's an actual problem. :) The 'xofmonth' concept sounds interesting (though there might be a nicer name than that) - but what would a call to #set_recurring_event look like, using 'xofmonth'? -Yaron On Wed, Mar 3, 2010 at 9:51 PM, David Raison <da...@ha...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi again, > > I hope this is not going to turn out to be another Pebkac for me ;) > > Have you foreseen the possibility of tweaking the recurring events parser > to not parse monthly > recurring events by date (i.e. each 6th of a month) but by days of the week > (i.e. every first > Saturday of a month)? > > Actually, there are two possibilities to do this (or let's rather say, two > that I thought of, not > being familiar with the SMWDataValueFactory). The first and, IMHO simplest, > being: > > Index: SMW_ParserExtensions.php > =================================================================== > - --- SMW_ParserExtensions.php (revision 63234) > +++ SMW_ParserExtensions.php (working copy) > @@ -416,6 +416,14 @@ > $date_str = "$cur_year-$cur_month-$cur_day > $cur_time"; > $cur_date = > SMWDataValueFactory::newTypeIDValue('_dat', $date_str); > $cur_date_jd = $cur_date->getNumericValue(); > + } elseif($unit == 'xofmonth') { > + $check_month = $cur_date->getMonth(); > + $cur_date_jd += 28 * $period; > + $cur_date = > SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); > + if ($cur_date->getMonth() != (($check_month > + $period) % 12 )){ > + $cur_date_jd += 7; // add > another week > + $cur_date = > SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); > + } > } else { // $unit == 'day' or 'week' > // assume 'day' if it's none of the above > $cur_date_jd += ($unit === 'week') ? 7 * > $period : $period; > > > Either there is no way to not have to calculate $cur_date twice, or I'm > just too tired to find it. > Here's the actual data: Setting [0] and Browsing [1] > > The other possibility would be to look up what day of the week [date(N)] > and in what quarter of the > month the $cur_day is [$cur_day ceil($cur_day / 7)] is and then ask php for > every "xth $dayOfWeek" > in the subsequent "$cur_month += $period". > > But that seems more complicated than method one. > > cheers, > D. > > [0] > https://www.hackerspace.lu/w/index.php?title=Sandbox&action=edit§ion=1 > [1] > https://www.hackerspace.lu/wiki/Special:Browse?title=Special%3ABrowse&article=Sandbox > > - -- > HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg > July 22nd till July 25th 2010, in Dudelange, Luxembourg > Register Now: http://events.hackerspace.lu/camp/2010/ > - ---- > mailto:da...@ha... > xmpp:kw...@ja...<xmpp%3Ak...@ja...> > mobile: +43 650 73 63 834 | +352 691 44 23 24 > ++++++++++++++++++++++++++++++++++++++++++++ > Wear your geek: http://syn2cat.spreadshirt.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkuPIEMACgkQYTtdUdP5zDeBEwCgtwu69suVdVTqtsS4AqtNhiTZ > c/oAn1ZSNypHIHZVJh9xk2hETiL6SOHE > =/C/s > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Al H. <al...@ho...> - 2010-03-04 05:41:25
|
Back in January I constructed a complete proposal for how to expose this kind of functional extension to #set_recurring_events. I got no response. Subsequently I DM'd Markus to see if he had any thoughts, and also got no response. Here is my original proposal: http://sourceforge.net/mailarchive/forum.php?thread_name=1263579979.8239.34.camel%40ramp&forum_name=semediawiki-devel Please pardon this typo in the original email: "decated" -> "deprecated". It's good to see I'm not the only person who thinks this is important. I was within a few weeks of coding this up just for myself, since nobody else seemed interested. I'm still open to any/all thoughts about my proposed way of exposing the functionality. -Al On Wed, 2010-03-03 at 22:27 -0500, Yaron Koren wrote: > Hi, > > > No, this one's an actual problem. :) The 'xofmonth' concept sounds > interesting (though there might be a nicer name than that) - but what > would a call to #set_recurring_event look like, using 'xofmonth'? > > > -Yaron > > On Wed, Mar 3, 2010 at 9:51 PM, David Raison <da...@ha...> > wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi again, > > I hope this is not going to turn out to be another Pebkac for > me ;) > > Have you foreseen the possibility of tweaking the recurring > events parser to not parse monthly > recurring events by date (i.e. each 6th of a month) but by > days of the week (i.e. every first > Saturday of a month)? > > Actually, there are two possibilities to do this (or let's > rather say, two that I thought of, not > being familiar with the SMWDataValueFactory). The first and, > IMHO simplest, being: > > Index: SMW_ParserExtensions.php > =================================================================== > - --- SMW_ParserExtensions.php (revision 63234) > +++ SMW_ParserExtensions.php (working copy) > @@ -416,6 +416,14 @@ > $date_str = > "$cur_year-$cur_month-$cur_day $cur_time"; > $cur_date = > SMWDataValueFactory::newTypeIDValue('_dat', $date_str); > $cur_date_jd = > $cur_date->getNumericValue(); > + } elseif($unit == 'xofmonth') { > + $check_month = > $cur_date->getMonth(); > + $cur_date_jd += 28 * $period; > + $cur_date = > SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); > + if ($cur_date->getMonth() != > (($check_month + $period) % 12 )){ > + $cur_date_jd += 7; > // add another week > + $cur_date = > SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); > + } > } else { // $unit == 'day' or 'week' > // assume 'day' if it's none of > the above > $cur_date_jd += ($unit === > 'week') ? 7 * $period : $period; > > > Either there is no way to not have to calculate $cur_date > twice, or I'm just too tired to find it. > Here's the actual data: Setting [0] and Browsing [1] > > The other possibility would be to look up what day of the week > [date(N)] and in what quarter of the > month the $cur_day is [$cur_day ceil($cur_day / 7)] is and > then ask php for every "xth $dayOfWeek" > in the subsequent "$cur_month += $period". > > But that seems more complicated than method one. > > cheers, > D. > > [0] > https://www.hackerspace.lu/w/index.php?title=Sandbox&action=edit&section=1 > [1] > https://www.hackerspace.lu/wiki/Special:Browse?title=Special% > 3ABrowse&article=Sandbox > > - -- > HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg > July 22nd till July 25th 2010, in Dudelange, Luxembourg > Register Now: http://events.hackerspace.lu/camp/2010/ > - ---- > mailto:da...@ha... > xmpp:kw...@ja... > mobile: +43 650 73 63 834 | +352 691 44 23 24 > ++++++++++++++++++++++++++++++++++++++++++++ > Wear your geek: http://syn2cat.spreadshirt.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkuPIEMACgkQYTtdUdP5zDeBEwCgtwu69suVdVTqtsS4AqtNhiTZ > c/oAn1ZSNypHIHZVJh9xk2hETiL6SOHE > =/C/s > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find > bugs > proactively, and fine-tune applications for parallel > performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ Semediawiki-devel mailing list Sem...@li... https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Yaron K. <ya...@gm...> - 2010-03-04 04:55:30
|
Al - yes, I remember that email of yours (I was going to mention it in my previous response). The problem was that I thought the proposal was just a little too complex - I couldn't understand it (though I probably should have tried harder). I didn't understand, for instance, why "month" was being changed to "monthdate". (Though I should have asked about that at the time...) Here's a more general question, and this might apply to both proposals: I can see the need for "2nd Wednesday of every month", but not for "2nd Wednesday of every 3rd month" - I just haven't heard of something being scheduled that way. Are there such things? Of course, there are events that happen every *12th* month, i.e. once a year, like Thanksgiving, which is on the 4th Thursday of every November (I had to look that one up). But I don't know if it's worth creating that functionality just to support a few national holidays - and this being a semantic technology, surely there's a way to get holiday information from an outside data source, if it's needed? -Yaron On Wed, Mar 3, 2010 at 10:48 PM, Al Hooton <al...@ho...> wrote: > Back in January I constructed a complete proposal for how to expose this > kind of functional extension to #set_recurring_events. I got no > response. Subsequently I DM'd Markus to see if he had any thoughts, and > also got no response. Here is my original proposal: > > > http://sourceforge.net/mailarchive/forum.php?thread_name=1263579979.8239.34.camel%40ramp&forum_name=semediawiki-devel > > Please pardon this typo in the original email: "decated" -> > "deprecated". > > It's good to see I'm not the only person who thinks this is important. > I was within a few weeks of coding this up just for myself, since nobody > else seemed interested. > > I'm still open to any/all thoughts about my proposed way of exposing the > functionality. > > -Al > > > On Wed, 2010-03-03 at 22:27 -0500, Yaron Koren wrote: > > Hi, > > > > > > No, this one's an actual problem. :) The 'xofmonth' concept sounds > > interesting (though there might be a nicer name than that) - but what > > would a call to #set_recurring_event look like, using 'xofmonth'? > > > > > > -Yaron > > > > On Wed, Mar 3, 2010 at 9:51 PM, David Raison <da...@ha...> > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi again, > > > > I hope this is not going to turn out to be another Pebkac for > > me ;) > > > > Have you foreseen the possibility of tweaking the recurring > > events parser to not parse monthly > > recurring events by date (i.e. each 6th of a month) but by > > days of the week (i.e. every first > > Saturday of a month)? > > > > Actually, there are two possibilities to do this (or let's > > rather say, two that I thought of, not > > being familiar with the SMWDataValueFactory). The first and, > > IMHO simplest, being: > > > > Index: SMW_ParserExtensions.php > > > =================================================================== > > - --- SMW_ParserExtensions.php (revision 63234) > > +++ SMW_ParserExtensions.php (working copy) > > @@ -416,6 +416,14 @@ > > $date_str = > > "$cur_year-$cur_month-$cur_day $cur_time"; > > $cur_date = > > SMWDataValueFactory::newTypeIDValue('_dat', $date_str); > > $cur_date_jd = > > $cur_date->getNumericValue(); > > + } elseif($unit == 'xofmonth') { > > + $check_month = > > $cur_date->getMonth(); > > + $cur_date_jd += 28 * $period; > > + $cur_date = > > SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); > > + if ($cur_date->getMonth() != > > (($check_month + $period) % 12 )){ > > + $cur_date_jd += 7; > > // add another week > > + $cur_date = > > SMWDataValueFactory::newTypeIDValue('_dat', $cur_date_jd); > > + } > > } else { // $unit == 'day' or 'week' > > // assume 'day' if it's none of > > the above > > $cur_date_jd += ($unit === > > 'week') ? 7 * $period : $period; > > > > > > Either there is no way to not have to calculate $cur_date > > twice, or I'm just too tired to find it. > > Here's the actual data: Setting [0] and Browsing [1] > > > > The other possibility would be to look up what day of the week > > [date(N)] and in what quarter of the > > month the $cur_day is [$cur_day ceil($cur_day / 7)] is and > > then ask php for every "xth $dayOfWeek" > > in the subsequent "$cur_month += $period". > > > > But that seems more complicated than method one. > > > > cheers, > > D. > > > > [0] > > > https://www.hackerspace.lu/w/index.php?title=Sandbox&action=edit&section=1 > > [1] > > https://www.hackerspace.lu/wiki/Special:Browse?title=Special% > > 3ABrowse&article=Sandbox > > > > - -- > > HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg > > July 22nd till July 25th 2010, in Dudelange, Luxembourg > > Register Now: http://events.hackerspace.lu/camp/2010/ > > - ---- > > mailto:da...@ha... > > xmpp:kw...@ja...<xmpp%3Ak...@ja...> > > mobile: +43 650 73 63 834 | +352 691 44 23 24 > > ++++++++++++++++++++++++++++++++++++++++++++ > > Wear your geek: http://syn2cat.spreadshirt.net > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.14 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkuPIEMACgkQYTtdUdP5zDeBEwCgtwu69suVdVTqtsS4AqtNhiTZ > > c/oAn1ZSNypHIHZVJh9xk2hETiL6SOHE > > =/C/s > > -----END PGP SIGNATURE----- > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find > > bugs > > proactively, and fine-tune applications for parallel > > performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ Semediawiki-devel mailing > list Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Al H. <al...@ho...> - 2010-03-04 05:22:46
|
Yaron, David: Yaron: Thanks for the feedback. I put my original email out only as a starting point for a (hopefully) short conversation, so I appreciate you looking through it. The month->monthdate change was simply a way to make that option more clear in light of the other proposed changes, it's not really important either way in my mind. Regarding the complexity of supporting the "2nd Wednesday of every 3rd month" example: I agree it is likely to be a very rare occurrence. However, I like it because it allows the "period" value to used with the proposed new functionality in a way that is congruent with how it works with existing functionality (I like consistency in my programmatic interfaces). If it was difficult to do I would be the first to support ditching it, but in the algorithmic approach I was looking at it was going to be easy. So, I could support going either way on this one as well. I very much agree that supporting something like national holidays, or other publicly-available event data, makes no sense -- those sources should be queried in when required. David: I can certainly support your approach as well (especially since it appears you've already got it coded.... 8^) ). My real hope is the powers-that-be will accept whatever approach is chosen, so we can have this functionality in the core SMW code going forward, instead of having to maintain it as an extension. -Al On Wed, 2010-03-03 at 23:55 -0500, Yaron Koren wrote: > Al - yes, I remember that email of yours (I was going to mention it in > my previous response). The problem was that I thought the proposal was > just a little too complex - I couldn't understand it (though I > probably should have tried harder). I didn't understand, for instance, > why "month" was being changed to "monthdate". (Though I should have > asked about that at the time...) > > > Here's a more general question, and this might apply to both > proposals: I can see the need for "2nd Wednesday of every month", but > not for "2nd Wednesday of every 3rd month" - I just haven't heard of > something being scheduled that way. Are there such things? Of course, > there are events that happen every *12th* month, i.e. once a year, > like Thanksgiving, which is on the 4th Thursday of every November (I > had to look that one up). But I don't know if it's worth creating that > functionality just to support a few national holidays - and this being > a semantic technology, surely there's a way to get holiday information > from an outside data source, if it's needed? > > > -Yaron > > > On Wed, Mar 3, 2010 at 10:48 PM, Al Hooton <al...@ho...> wrote: > Back in January I constructed a complete proposal for how to > expose this > kind of functional extension to #set_recurring_events. I got > no > response. Subsequently I DM'd Markus to see if he had any > thoughts, and > also got no response. Here is my original proposal: > > http://sourceforge.net/mailarchive/forum.php?thread_name=1263579979.8239.34.camel%40ramp&forum_name=semediawiki-devel > > Please pardon this typo in the original email: "decated" -> > "deprecated". > > It's good to see I'm not the only person who thinks this is > important. > I was within a few weeks of coding this up just for myself, > since nobody > else seemed interested. > > I'm still open to any/all thoughts about my proposed way of > exposing the > functionality. > > -Al > > > > On Wed, 2010-03-03 at 22:27 -0500, Yaron Koren wrote: > > Hi, > > > > > > No, this one's an actual problem. :) The 'xofmonth' concept > sounds > > interesting (though there might be a nicer name than that) - > but what > > would a call to #set_recurring_event look like, using > 'xofmonth'? > > > > > > -Yaron > > > > On Wed, Mar 3, 2010 at 9:51 PM, David Raison > <da...@ha...> > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi again, > > > > I hope this is not going to turn out to be another > Pebkac for > > me ;) > > > > Have you foreseen the possibility of tweaking the > recurring > > events parser to not parse monthly > > recurring events by date (i.e. each 6th of a month) > but by > > days of the week (i.e. every first > > Saturday of a month)? > > > > Actually, there are two possibilities to do this (or > let's > > rather say, two that I thought of, not > > being familiar with the SMWDataValueFactory). The > first and, > > IMHO simplest, being: > > > > Index: SMW_ParserExtensions.php > > > =================================================================== > > - --- SMW_ParserExtensions.php (revision 63234) > > +++ SMW_ParserExtensions.php (working copy) > > @@ -416,6 +416,14 @@ > > $date_str = > > "$cur_year-$cur_month-$cur_day $cur_time"; > > $cur_date = > > SMWDataValueFactory::newTypeIDValue('_dat', > $date_str); > > $cur_date_jd = > > $cur_date->getNumericValue(); > > + } elseif($unit == > 'xofmonth') { > > + $check_month = > > $cur_date->getMonth(); > > + $cur_date_jd += 28 * > $period; > > + $cur_date = > > SMWDataValueFactory::newTypeIDValue('_dat', > $cur_date_jd); > > + if > ($cur_date->getMonth() != > > (($check_month + $period) % 12 )){ > > + $cur_date_jd > += 7; > > // add another week > > + $cur_date = > > SMWDataValueFactory::newTypeIDValue('_dat', > $cur_date_jd); > > + } > > } else { // $unit == 'day' or > 'week' > > // assume 'day' if > it's none of > > the above > > $cur_date_jd += > ($unit === > > 'week') ? 7 * $period : $period; > > > > > > Either there is no way to not have to calculate > $cur_date > > twice, or I'm just too tired to find it. > > Here's the actual data: Setting [0] and Browsing [1] > > > > The other possibility would be to look up what day > of the week > > [date(N)] and in what quarter of the > > month the $cur_day is [$cur_day ceil($cur_day / 7)] > is and > > then ask php for every "xth $dayOfWeek" > > in the subsequent "$cur_month += $period". > > > > But that seems more complicated than method one. > > > > cheers, > > D. > > > > [0] > > > > https://www.hackerspace.lu/w/index.php?title=Sandbox&amp;action=edit&amp;section=1 > > [1] > > > https://www.hackerspace.lu/wiki/Special:Browse?title=Special% > > > 3ABrowse&article=Sandbox > > > > > - -- > > HaxoGreen 2010 - the Hackers' Summercamp in > Luxembourg > > July 22nd till July 25th 2010, in Dudelange, > Luxembourg > > Register Now: > http://events.hackerspace.lu/camp/2010/ > > - ---- > > mailto:da...@ha... > > xmpp:kw...@ja... > > mobile: +43 650 73 63 834 | +352 691 44 23 24 > > ++++++++++++++++++++++++++++++++++++++++++++ > > Wear your geek: http://syn2cat.spreadshirt.net > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.14 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > > > > iEYEARECAAYFAkuPIEMACgkQYTtdUdP5zDeBEwCgtwu69suVdVTqtsS4AqtNhiTZ > > c/oAn1ZSNypHIHZVJh9xk2hETiL6SOHE > > =/C/s > > -----END PGP SIGNATURE----- > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed > compiling, find > > bugs > > proactively, and fine-tune applications for parallel > > performance. > > See why Intel Parallel Studio got high marks during > beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, > find bugs > > proactively, and fine-tune applications for parallel > performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |
From: David R. <da...@ha...> - 2010-03-04 05:55:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey, > Regarding the complexity of supporting the "2nd Wednesday of every 3rd > month" example: I agree it is likely to be a very rare occurrence. > However, I like it because it allows the "period" value to used with the > proposed new functionality in a way that is congruent with how it works > with existing functionality (I like consistency in my programmatic > interfaces). That is the point I was trying to make. I don't know about the 3rd Sunday every four months, but in our case, we actually have events that take place every first Saturday of a month, or every last Tuesday. (As can be seen by the real life example) If you have recurring events that the same people want to or shall attend, you can't have them attend them on different days of the Week every Month. That doesn't really work well with people's schedules. So all I ask for is really that X Day of every month, but as the period is already in there, why not let people have other periods. Of course, it might be more difficult/expensive to allow for events to recur on Easter every year (and I must admit I don't know exactly on what first/last day in what week that is) but Weekdays should come in pretty cheap and very handy for a considerable number of people. (We can't be that weird, having events recur on every first Saturday of a month, are we?) > David: I can certainly support your approach as well (especially since > it appears you've already got it coded.... 8^) ). Thanks ;) And it seems to me (knowing that there must be better algorithms) that this is pretty inexpensive. Even if you're off by a week on one round, the debt doesn't add up but is corrected in each loop. I first thought that this might not scale well with days in the first week of a month, but it actually does, doesn't it? D. - -- HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg July 22nd till July 25th 2010, in Dudelange, Luxembourg Register Now: http://events.hackerspace.lu/camp/2010/ - ---- mailto:da...@ha... xmpp:kw...@ja... mobile: +43 650 73 63 834 | +352 691 44 23 24 ++++++++++++++++++++++++++++++++++++++++++++ Wear your geek: http://syn2cat.spreadshirt.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuPSzYACgkQYTtdUdP5zDfltgCgkDnmKX1pBmXAmDSJbJFqeAg8 nOwAoIRkkZGibn+RRSWJhUfxcp5zETum =5W8a -----END PGP SIGNATURE----- |
From: Yaron K. <ya...@gm...> - 2010-03-04 18:15:16
|
Well, I think the basic 'xofmonth' functionality is the way to go - a single new value that takes care of everything. Assuming the new code works, I can add it in to SMW myself, since #set_recurring_event is basically my code. I'll probably wait until after SMW 1.5 is released, though... For the name of the new value, though, how about 'dayofweekinmonth' instead? It's quite long, but it's the only thing I can think of where there's even a remote chance that someone would understand it just by seeing the name. -Yaron On Thu, Mar 4, 2010 at 12:55 AM, David Raison <da...@ha...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey, > > > Regarding the complexity of supporting the "2nd Wednesday of every 3rd > > month" example: I agree it is likely to be a very rare occurrence. > > However, I like it because it allows the "period" value to used with the > > proposed new functionality in a way that is congruent with how it works > > with existing functionality (I like consistency in my programmatic > > interfaces). > > That is the point I was trying to make. > I don't know about the 3rd Sunday every four months, but in our case, we > actually have events that > take place every first Saturday of a month, or every last Tuesday. (As can > be seen by the real life > example) > > If you have recurring events that the same people want to or shall attend, > you can't have them > attend them on different days of the Week every Month. That doesn't really > work well with people's > schedules. > > So all I ask for is really that X Day of every month, but as the period is > already in there, why not > let people have other periods. > > Of course, it might be more difficult/expensive to allow for events to > recur on Easter every year > (and I must admit I don't know exactly on what first/last day in what week > that is) but Weekdays > should come in pretty cheap and very handy for a considerable number of > people. (We can't be that > weird, having events recur on every first Saturday of a month, are we?) > > > > David: I can certainly support your approach as well (especially since > > it appears you've already got it coded.... 8^) ). > > > Thanks ;) And it seems to me (knowing that there must be better algorithms) > that this is pretty > inexpensive. Even if you're off by a week on one round, the debt doesn't > add up but is corrected in > each loop. I first thought that this might not scale well with days in the > first week of a month, > but it actually does, doesn't it? > > D. > > - -- > HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg > July 22nd till July 25th 2010, in Dudelange, Luxembourg > Register Now: http://events.hackerspace.lu/camp/2010/ > - ---- > mailto:da...@ha... > xmpp:kw...@ja...<xmpp%3Ak...@ja...> > mobile: +43 650 73 63 834 | +352 691 44 23 24 > ++++++++++++++++++++++++++++++++++++++++++++ > Wear your geek: http://syn2cat.spreadshirt.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkuPSzYACgkQYTtdUdP5zDfltgCgkDnmKX1pBmXAmDSJbJFqeAg8 > nOwAoIRkkZGibn+RRSWJhUfxcp5zETum > =5W8a > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: David R. <da...@ha...> - 2010-03-04 18:38:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > For the name of the new value, though, how about 'dayofweekinmonth' > instead? It's quite long, but it's the only thing I can think of where > there's even a remote chance that someone would understand it just by > seeing the name. You're right.. this is probably the most complicated part of it ;) Isn't this what Al suggested in the beginning? If the original "month" were renamed "monthdate" and this one was called "monthday" or "monthdayofweek"? (which isn't really better than "dayofweekinmonth", granted) Does anyone else have a suggestion? :) cheers, D. - -- HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg July 22nd till July 25th 2010, in Dudelange, Luxembourg Register Now: http://events.hackerspace.lu/camp/2010/ - ---- mailto:da...@ha... xmpp:kw...@ja... mobile: +43 650 73 63 834 | +352 691 44 23 24 ++++++++++++++++++++++++++++++++++++++++++++ Wear your geek: http://syn2cat.spreadshirt.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuP/hoACgkQYTtdUdP5zDdwBACdEc1MePnJUlIdJ2lAYNcUTbt2 pwEAnj9FbLNPdHWnKlpiDmGphKyEB/Xz =xVwB -----END PGP SIGNATURE----- |
From: John M. <jmc...@hy...> - 2010-03-04 22:30:06
|
>Does anyone else have a suggestion? :) Normalization would show the day of a week is an attribute of a date. So: * An #ask should be able to say ?Date.Weekday * IOW, a "Date" is a first class object as much as, say, a "Place" is * IOW, I'd like to see SMW standardize "category:Dates" and its properties * And I'd like to see the ability to set those properties from a 'container' object's template * IMHO, {{#set: page-or-sio-name|propname=value}} would resolve alot of n-ary issues * I'm not sure yet how this plays with the (proposed?) Record datatype (e.g., is the Record datatype a reimplementation of SIO? Can Records be named?) Best regards, John McClure |
From: Yaron K. <ya...@gm...> - 2010-03-05 00:59:05
|
This is interesting, though it seems irrelevant to this discussion, which is about storing data, not querying it... unless I'm missing something. -Yaron On Thu, Mar 4, 2010 at 5:32 PM, John McClure <jmc...@hy...>wrote: > >Does anyone else have a suggestion? :) > > Normalization would show the day of a week is an attribute of a date. So: > * An #ask should be able to say ?Date.Weekday > * IOW, a "Date" is a first class object as much as, say, a "Place" is > * IOW, I'd like to see SMW standardize "category:Dates" and its properties > * And I'd like to see the ability to set those properties from a > 'container' > object's template > * IMHO, {{#set: page-or-sio-name|propname=value}} would resolve alot of > n-ary > issues > * I'm not sure yet how this plays with the (proposed?) Record datatype > (e.g., is the Record datatype a reimplementation of SIO? Can Records be > named?) > > Best regards, > John McClure > > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: John M. <jmc...@hy...> - 2010-03-05 15:42:20
|
See below for comments - thanks, John -----Original Message----- From: Yaron Koren [mailto:ya...@gm...] Sent: Thursday, March 04, 2010 4:59 PM To: John McClure Cc: David Raison; semediawiki-devel Subject: Re: [SMW-devel] Recurring Events: "Every first saturday of a month" This is interesting, though it seems irrelevant to this discussion, which is about storing data, not querying it... unless I'm missing something. -Yaron On Thu, Mar 4, 2010 at 5:32 PM, John McClure <jmc...@hy...> wrote: >Does anyone else have a suggestion? :) Normalization would show the day of a week is an attribute of a date. So: * An #ask should be able to say ?Date.Weekday * IOW, a "Date" is a first class object as much as, say, a "Place" is * IOW, I'd like to see SMW standardize "category:Dates" and its properties * And I'd like to see the ability to set those properties from a 'container' object's template but see below my idea for an #about function * IMHO, {{#set: page-or-sio-name|propname=value}} would resolve alot of n-ary issues but see below discussion for the #about function <snip> ---------------------------------------------------------------------------- I worked backwards to address the storage process & protocol, starting from the query that I'd rather see. The query is one that uses the 'dot' operator to traverse object nodes & then terminating at a text-node, rather than simply having an unnormalized 'camel case' text-node propery name (such as the proposed monstrosity) which is lame from the view that, because it is unnormalized, then by definition it is not reusable in other contexts. Obviously noone wants to require a page for every date. Rather, queriable built-in Date objects can be simulated &or retrieved by SMW either from SIOs or MV properties associated with the [[:category:Dates]] page OR from pages in the wiki so categorized. SIOs seem a better candidate because they are queriable, though MV properties suggest better performance. If SIO was used, then each 'date' object would be linked to the :Category:Dates page via a "Category" property for the date object. If MVPs are used, then each 'date' object would be referenced by say an "Instances" property that is attached to the :Category:Dates page either explicitly or implicitly. Personally I'd think the ideal would be to have MVPs that are queriable in the normal #ask methods, enhanced to reference a metaproperty for the 'Instances' property that lists the property names by which to retrieve values within each MVP arraymap. So I'm urging a new data model from the get-go, to arrive at simple reusuable syntax like "End Date.Weekday.Text" -- involving navigation from any page via an End Date property to a :category:Dates object, via a Weekday property to a :category:Weekdays object, then finally to a text property for the name of the day. Ideally, there'd be a built-in set of date objects that can be referenced by others, whose properties can be extended by a wiki (ie defining additional rdfs:domains for the class), and that can be created as pages wthin a wiki. ---------------------------------------------------------------------------- ---- My problem with SIOs or MVPs as an n-ary solution is this: Assume a template for a [[:category:Country]] page named "USA" has: {{#set_internal:Is president of |Has name=Ulysses S. Grant |Has vice president#list=Schuyler Colfax, Henry Wilson }} What I want is to do simple housekeeping, like recording [[Ulysses S. Grant]] page's property:President Of = [[USA]], and to set each of the Vice President pages' properties to reflect their relationship to [[Ulysses S. Grant]]. Defining complementary properties gets very messy very fast, so it HAS to be able to be done in the template that creates the SIO. This can make queries of [[Ulysses S. Grant]] much easier. I'm thinking an #about function can implicitly update arbitrary pages when in the context of another page, such as setting [[Colfax]] page properties when processing a template embedded in [[USA]]. Provenance fields identifying the data source etc could be collected by the #about function. So to set a complementary property ("Presidency") to the ("Is President Of") property, there'd be something like {{#set_internal: Is president of :: {{FULLPAGENAME}}#{{prez_name}}} |Has name={{{prez_name}}} |Has vice president#list={{{prez_vps|}}} }} {{#about::{{{prez_name}}} |Presidency={{FULLPAGENAME}}#{{prez_name}}} }} or to set multiple properties on the target object {{#about::{{{prez_name}}} |Is president of={{FULLPAGENAME}} |Has vice president#list={{{prez_vps|}}} }} If a Weekday name is being set for a certain date, then: {{#about: Category:Dates#2010-03-04 |Weekday=Category:Weekdays#Thursday }} |
From: Yaron K. <ya...@gm...> - 2010-03-05 16:28:56
|
Hi John, I read through this email a few times now, and I still can't really understand it. - what's the "camel case monstrosity" you're talking about? - what's "Category:Dates"? What would go into such a category? - what's the weakness you see in Semantic Internal Objects? - would your proposed #about function update the data for a page other than the one it's on? If so, that seems like a non-starter, but maybe I just misunderstood it. I should note, though, that I still don't think is relevant to the recurring-events issue. It's already possible, in theory, to define a recurring event as just a start date, an end date, and a set of rules. The problem is that that would be extremely slow - to find all the pages that have a certain date value, you'd have to go through all the pages where dates were defined, apply all the rules, and see if there's a match in any of them. I don't think it would take a lot of data to make that unworkable. -Yaron On Fri, Mar 5, 2010 at 10:44 AM, John McClure <jmc...@hy...>wrote: > * > > See below for comments - thanks, John > > -----Original Message----- > From: Yaron Koren [mailto:ya...@gm...] > Sent: Thursday, March 04, 2010 4:59 PM > To: John McClure > Cc: David Raison; semediawiki-devel > Subject: Re: [SMW-devel] Recurring Events: "Every first saturday of a > month" > > This is interesting, though it seems irrelevant to this discussion, which > is about storing data, not querying it... unless I'm missing something. > > -Yaron > > On Thu, Mar 4, 2010 at 5:32 PM, John McClure <jmc...@hy...>wrote: > >> >Does anyone else have a suggestion? :) >> >> Normalization would show the day of a week is an attribute of a date. So: >> * An #ask should be able to say ?Date.Weekday >> * IOW, a "Date" is a first class object as much as, say, a "Place" is >> * IOW, I'd like to see SMW standardize "category:Dates" and its properties >> * And I'd like to see the ability to set those properties from a >> 'container' >> object's template but see below my idea for an #about function >> * IMHO, {{#set: page-or-sio-name|propname=value}} would resolve alot of >> n-ary >> issues but see below discussion for the #about function >> <snip> >> > ** > ------------------------------ > * > I worked backwards to address the storage process & protocol, starting > from the query that I'd rather see. The query is one that uses the 'dot' > operator to traverse object nodes & then terminating at a text-node, rather > than simply having an unnormalized 'camel case' text-node propery name (such > as the proposed monstrosity) which is lame from the view that, because it is > unnormalized, then by definition it is not reusable in other contexts. > ** > Obviously noone wants to require a page for every date. Rather, > queriable built-in Date objects can be simulated &or retrieved by SMW either > from SIOs or MV properties associated with the [[:category:Dates]] page OR > from pages in the wiki so categorized. > > SIOs seem a better candidate because they are queriable, though MV > properties suggest better performance. If SIO was used, then each 'date' > object would be linked to the :Category:Dates page via a "Category" > property for the date object. If MVPs are used, then each 'date' object > would be referenced by say an "Instances" property that is attached to the > :Category:Dates page either explicitly or implicitly. Personally I'd think > the ideal would be to have MVPs that are queriable in the normal #ask > methods, enhanced to reference a metaproperty for the 'Instances' property > that lists the property names by which to retrieve values within each MVP arraymap. > > > So I'm urging a new data model from the get-go, to arrive at simple > reusuable syntax like "End Date.Weekday.Text" -- involving navigation from > any page via an End Date property to a :category:Dates object, via a Weekday > property to a :category:Weekdays object, then finally to a text property for > the name of the day. Ideally, there'd be a built-in set of date objects > that can be referenced by others, whose properties can be extended by a wiki > (ie defining additional rdfs:domains for the class), and that can be created > as pages wthin a wiki. > ------------------------------ > My problem with SIOs or MVPs as an n-ary solution is this: > > Assume a template for a [[:category:Country]] page named "USA" has: > {{#set_internal:Is president of > |Has name=Ulysses S. Grant > |Has vice president#list=Schuyler Colfax, Henry Wilson > }} > What I want is to do simple housekeeping, like recording [[Ulysses S. > Grant]] page's property:President Of = [[USA]], and to set each of the Vice > President pages' properties to reflect their relationship to [[Ulysses S. > Grant]]. Defining complementary properties gets very messy very fast, so it > HAS to be able to be done in the template that creates the SIO. This can > make queries of [[Ulysses S. Grant]] much easier. > > I'm thinking an #about function can implicitly update arbitrary pages when > in the context of another page, such as setting [[Colfax]] page properties > when processing a template embedded in [[USA]]. Provenance fields > identifying the data source etc could be collected by the #about function. > So to set a complementary property ("Presidency") to the ("Is President Of") > property, there'd be something like > > {{#set_internal: Is president of :: {{FULLPAGENAME}}#{{prez_name}}} > |Has name={{{prez_name}}} > |Has vice president#list={{{prez_vps|}}} > }} > {{#about::{{{prez_name}}} > |Presidency={{FULLPAGENAME}}#{{prez_name}}} > }} > or to set multiple properties on the target object > {{#about::{{{prez_name}}} > |Is president of={{FULLPAGENAME}} > |Has vice president#list={{{prez_vps|}}} > }} > ** > If a Weekday name is being set for a certain date, then: > {{#about: Category:Dates#2010-03-04 > |Weekday=Category:Weekdays#Thursday > }} > > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Yaron K. <ya...@gm...> - 2010-03-18 19:56:08
|
Just checking - are there any objections to calling the new 'unit' value 'dayofweekinmonth'? As hack-ish as it sounds, I still think it's the best name of the ones suggested so far. Now that SMW 1.5 has been released, I think it's a good time to add this feature to the code... -Yaron On Thu, Mar 4, 2010 at 8:58 PM, Yaron Koren <ya...@gm...> wrote: > This is interesting, though it seems irrelevant to this discussion, which > is about storing data, not querying it... unless I'm missing something. > > -Yaron > > > On Thu, Mar 4, 2010 at 5:32 PM, John McClure <jmc...@hy...>wrote: > >> >Does anyone else have a suggestion? :) >> >> Normalization would show the day of a week is an attribute of a date. So: >> * An #ask should be able to say ?Date.Weekday >> * IOW, a "Date" is a first class object as much as, say, a "Place" is >> * IOW, I'd like to see SMW standardize "category:Dates" and its properties >> * And I'd like to see the ability to set those properties from a >> 'container' >> object's template >> * IMHO, {{#set: page-or-sio-name|propname=value}} would resolve alot of >> n-ary >> issues >> * I'm not sure yet how this plays with the (proposed?) Record datatype >> (e.g., is the Record datatype a reimplementation of SIO? Can Records be >> named?) >> >> Best regards, >> John McClure >> >> >> > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Al H. <al...@ho...> - 2010-03-18 20:19:12
|
Yaron, Thanks, this will be great. Coincidentally, I've recently started playing with David's code a little bit to see how the algorithm works. So far no problems, but I haven't really pushed it hard yet either. My vote on the name: Honestly, I don't care... you can call it whatever you want if the feature gets in. 8^) Thanks! -Al On Thu, 2010-03-18 at 15:56 -0400, Yaron Koren wrote: > Just checking - are there any objections to calling the new 'unit' > value 'dayofweekinmonth'? As hack-ish as it sounds, I still think it's > the best name of the ones suggested so far. > > > Now that SMW 1.5 has been released, I think it's a good time to add > this feature to the code... > > > -Yaron > > On Thu, Mar 4, 2010 at 8:58 PM, Yaron Koren <ya...@gm...> wrote: > This is interesting, though it seems irrelevant to this > discussion, which is about storing data, not querying it... > unless I'm missing something. > > > -Yaron > > > > On Thu, Mar 4, 2010 at 5:32 PM, John McClure > <jmc...@hy...> wrote: > >Does anyone else have a suggestion? :) > > > Normalization would show the day of a week is an > attribute of a date. So: > * An #ask should be able to say ?Date.Weekday > * IOW, a "Date" is a first class object as much as, > say, a "Place" is > * IOW, I'd like to see SMW standardize > "category:Dates" and its properties > * And I'd like to see the ability to set those > properties from a 'container' > object's template > * IMHO, {{#set: page-or-sio-name|propname=value}} > would resolve alot of n-ary > issues > * I'm not sure yet how this plays with the (proposed?) > Record datatype > (e.g., is the Record datatype a reimplementation of > SIO? Can Records be > named?) > > Best regards, > John McClure > > > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ Semediawiki-devel mailing list Sem...@li... https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Al H. <al...@ho...> - 2010-03-23 01:44:31
|
Well, it took getting back to actually coding up something that works for the new "dayofweekinmonth" functionality to remember one of the reasons for my original proposal... If we just add the one new value to the unit= argument ("dayofweekinmonth"), there is no way way to support the "last <weekday> of the month" scenario. This is a widely used approach to recurring dates. We can determine from the start= argument if the date in question is the first, second, third or fourth (or even fifth, when it exists) instance of <weekday> in a month, but there is no way to determine that the user actually meant "last". We can't just say we'll infer "last" from the fifth instance because the user may well want to start the recurrence in a month that doesn't have a fifth instance. There is no way for the user to tell us they want the last instance each month. I propose that we add a single additional argument to #set_recurring_event called "weekinmonth" that is only used (and is required) when unit=dayofweekinmonth. This argument can take the values 'first', 'second', 'third', 'fourth' and 'last'. This is much more simple than my original proposal and utilizes the idea in David and Yaron's approach of determining the weekday the user wants from the start= value instead of creating yet another new argument for that. It's also easy to handle in the code. Thoughts? -Al On Thu, 2010-03-04 at 13:15 -0500, Yaron Koren wrote: > Well, I think the basic 'xofmonth' functionality is the way to go - a > single new value that takes care of everything. Assuming the new code > works, I can add it in to SMW myself, since #set_recurring_event is > basically my code. I'll probably wait until after SMW 1.5 is released, > though... > > > For the name of the new value, though, how about 'dayofweekinmonth' > instead? It's quite long, but it's the only thing I can think of where > there's even a remote chance that someone would understand it just by > seeing the name. > > > -Yaron > > > On Thu, Mar 4, 2010 at 12:55 AM, David Raison <da...@ha...> > wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hey, > > > Regarding the complexity of supporting the "2nd Wednesday of > every 3rd > > month" example: I agree it is likely to be a very rare > occurrence. > > However, I like it because it allows the "period" value to > used with the > > proposed new functionality in a way that is congruent with > how it works > > with existing functionality (I like consistency in my > programmatic > > interfaces). > > > That is the point I was trying to make. > I don't know about the 3rd Sunday every four months, but in > our case, we actually have events that > take place every first Saturday of a month, or every last > Tuesday. (As can be seen by the real life > example) > > If you have recurring events that the same people want to or > shall attend, you can't have them > attend them on different days of the Week every Month. That > doesn't really work well with people's > schedules. > > So all I ask for is really that X Day of every month, but as > the period is already in there, why not > let people have other periods. > > Of course, it might be more difficult/expensive to allow for > events to recur on Easter every year > (and I must admit I don't know exactly on what first/last day > in what week that is) but Weekdays > should come in pretty cheap and very handy for a considerable > number of people. (We can't be that > weird, having events recur on every first Saturday of a month, > are we?) > > > > David: I can certainly support your approach as well > (especially since > > it appears you've already got it coded.... 8^) ). > > > > Thanks ;) And it seems to me (knowing that there must be > better algorithms) that this is pretty > inexpensive. Even if you're off by a week on one round, the > debt doesn't add up but is corrected in > each loop. I first thought that this might not scale well with > days in the first week of a month, > but it actually does, doesn't it? > > D. > > - -- > HaxoGreen 2010 - the Hackers' Summercamp in Luxembourg > July 22nd till July 25th 2010, in Dudelange, Luxembourg > Register Now: http://events.hackerspace.lu/camp/2010/ > - ---- > mailto:da...@ha... > xmpp:kw...@ja... > mobile: +43 650 73 63 834 | +352 691 44 23 24 > ++++++++++++++++++++++++++++++++++++++++++++ > Wear your geek: http://syn2cat.spreadshirt.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > iEYEARECAAYFAkuPSzYACgkQYTtdUdP5zDfltgCgkDnmKX1pBmXAmDSJbJFqeAg8 > nOwAoIRkkZGibn+RRSWJhUfxcp5zETum > =5W8a > > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find > bugs > proactively, and fine-tune applications for parallel > performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |