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 <a...@hootons.org> 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...@hackerspace.lu> > > 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...@hackerspace.lu > > xmpp:kwis...@jabber.hackerspaces.org > > 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 > > Semediawiki-devel@lists.sourceforge.net > > > 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 > Semediawiki-devel@lists.sourceforge.net > 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 Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
