{"push_id":1327475011,"size":1,"distinct_size":1,"ref":"refs/heads/debian","head":"98b662bb4d6bc4d175b6c573fdfb9a6d5b6983b9","before":"f8fc0991a811e69beaecf87b4660c88c06b5fd5d","commits":[{"sha":"98b662bb4d6bc4d175b6c573fdfb9a6d5b6983b9","author":{"name":"Mukunda Modell","email":"249f5f36c715d8748ec89165eace149e61a0f2c8@wikimedia.org"},"message":"Updated git submodules\n\nProject: phabricator/libphutil wmf/stable 3d3959607b6a44696331e6fe661bc1796f24740d\n\nMerge branch 'upstream/stable' into wmf/stable\n\n\n(stable) Promote 2016 Week 40\n\n\nImplement RRULE FREQ=WEEKLY tests and BYSETPOS with WEEKLY\n\nSummary: Ref T10747. This implements the remaining behaivors for WEEKLY, hopefully.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16637\n\n\nImplement RFC5545 WEEKLY RRULE tests\n\nSummary: Ref T10747. This needs some cleanup and I think probably still has some bugs but the tests pass, at least.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16634\n\n\nAdd most RFC5545 tests for RRULEs\n\nSummary: Ref T10747. This adds most of the test cases from RFC5545, except WEEKLY because those don't work yet.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16633\n\n\nAdd SECONDLY tests to RRULE code\n\nSummary: Ref T10747. These pretty much worked. BYSETPOS does not make sense with SECONDLY, as far as I can tell.\n\nTest Plan: Unit tests pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16631\n\n\nSupport BYSETPOS for RRULE events with FREQ=MINUTELY\n\nSummary: Ref T10747. (Most of the MINUTELY tests in the source I'm cribbing from aren't too interesting so I omitted a chunk of them.)\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16630\n\n\nSupport BYSETPOS for RRULE events with FREQ=HOURLY\n\nSummary: Ref T10747. Most of these tests already passed; implement BYSETPOS logic for FREQ=HOURLY.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16629\n\n\nFix a TERRIBLE RRULE issue with INTERVAL interacting with ALL OTHER RULES and also MANY INTERESTING SPELLINGS OF THE WORD DYNAMIC\n\nSummary:\nRef T10747. When an RRULE is something like \"every 233rd hour on thursdays that are the 7th of the month in odd months\", we must iterate.\n\nSpecifically, the hours that aren't included in the rest of the set still count: this rule does not mean \"every 223rd hour on (...)\", it means \"every 223rd hour, if that hour also satisifies all the rest of the conditions\".\n\nThis is exceptionally rare/bizarre/useless, but make the tests pass.\n\nNormally, (with INTERVAL=1) we know we'll hit every value and can just skip this.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16628\n\n\nRemove a flaky test which can fail under load\n\nSummary:\nThis test can fail incorrectly when the host is under load (e.g., several builds running simultaneously).\n\nEssentially everything it tests is tested more reliably by adjacent tests.\n\nTest Plan: Laughed robustly.\n\nReviewers: chad\n\nReviewed By: chad\n\nDifferential Revision: https://secure.phabricator.com/D16624\n\n\nAdd RRULE support for SETPOS with FREQ=DAILY\n\nSummary:\nRef T10747. Most of these tests passed already.\n\nFix SETPOS with FREQ=DAILY and make that test pass too.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16622\n\n\nFix an RRULE bug with day cursors and skipped months\n\nSummary:\nRef T10747. This rule wasn't quite correct, and got some things like BYMONTH=1,3;INTERVAL=9 wrong.\n\nInstead of resetting the day cursor to 1, we need to move it forward through time in INTERVAL jumps until we get to the next candidate month.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16619\n\n\nImplement BYSETPOS for YEARLY and MONTHLY RRULES\n\nSummary:\nRef T10747. I may come back and try to clean this up, but at least make all the tests pass.\n\nThis stuff is really messy because if you have a YEARLY rule like \"the 3rd of every month\", and BYSETPOS on it, and the first instance is in June, too bad: we have to build every event for the whole year to apply BYSETPOS.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16617\n\n\nAdd many working RRULE test cases\n\nSummary: Ref T10747. Except for the BYSETPOS stuff, these all already work.\n\nTest Plan: Unit tests pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16616\n\n\nFix an RRULE bug with MONTHLY INTERVALs larger than 12\n\nSummary: Ref T10747. This was a simple typo of \"-\" where \"-=\" should be used.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16615\n\n\nImplement RRULE support for BYDAY with relative offsets (\"FREQ=YEARLY;BYDAY=-19TU\")\n\nSummary: Ref T10747. Finally, we can schedule an event on the -19th Thursday of the year.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16614\n\n\nAdd some working RRULE unit tests\n\nSummary:\nRef T10747. These tests already work and didn't uncover any bugs.\n\n(The next one deals with BYSETPOS and I think my approach isn't correct and needs significant work to correct, unfortuantely.)\n\nTest Plan: Unit tests pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16613\n\n\nFix an RRULE issue with all-day events expanded by BYHOUR or high-frequency RRULES\n\nSummary:\nRef T10747. If you have an all-day event, we normally return all-day events.\n\nIf the frequency is HOURLY or higher though, or the set has been expanded by a rule like BYHOUR, we need to iterate hours/minutes/seconds and return date-time results.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16612\n\n\nFix RRULE bugs with week numbers for leading and trailing partial weeks\n\nSummary:\nRef T10747. I only got this partially right:\n\n  - When the last week of the year has less than 4 days, it's counted as the first week of the next year.\n  - When the first week of the year has less than 4 days, it's counted as the last week of the prior year.\n\nThese rules are sort of crazy, but they work now.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16611\n\n\nFix some RRULE bugs with BYWEEKNO\n\nSummary: Ref T10747. A few typos, plus we need to expand months, plus the initial week calculation was slightly wrong.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16610\n\n\nFix two RRULE bugs with YEARDAY\n\nSummary: Ref T10747. One bug was a simple typo. Other bug is that we need to expand months if YEARDAY is present.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16609\n\n\nFix a RRULE issue with BYDAY and similar constraints in noninitial months\n\nSummary: Ref T10747. This latest test failed beacuse the start date (the 2nd) carried over to the first month we could actually examine.\n\nTest Plan: Unit test now passes.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16608\n\n\nFix a remaining `cursorYear` instead of `stateYear`\n\nSummary: Ref T10747. Last test failed because we were looking at weekdays in the wrong year. Root issue is bad `cursorYear`, other changes are just cleanup/debugging.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16607\n\n\nFix an RRULE issue where BYMONTHDAY did not properly expand the month set\n\nSummary: Ref T10747. When you have BYMONTHDAY, we need to expand the set of months by default, per the comment.\n\nTest Plan: Unit test now passes.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16606\n\n\nFix an RRULE issue with month days at the end of the month\n\nSummary:\nRef T10747. I'm porting unit tests from other implementations until I hit one that fails.\n\nThe \"yearly event on Feb 29th\" test failed because we assumed every month had a 29th. Instead, test if the current month has a 29th.\n\nWe were also using `cursorX` instead of `stateX` in a couple places. They often have the same value, but `stateX` is the correct value when they differ.\n\nTest Plan: Unit tests now pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16605\n\n\nValidate various RRULE components and simplify logic slightly\n\nSummary:\nRef T10747.\n\n  - Validate that all the values are in the proper ranges (this does not yet implement some rules which take more than one value into account, e.g. BYDAY may not be in the form \"+1TU\" unless FREQUENCY is MONTHLY or YEARLY).\n  - Use constants instead of magic strings.\n  - Do `array_fuse()` mangling earlier.\n  - Fix a couple of the TODOs around weekday stuff.\n  - Implement (probably) more of the BY* rules.\n  - Other minor simplification/cleanup.\n\nTest Plan: Unit tests still pass.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16603\n\n\nRough cut of implementing some of RRULE behaviors\n\nSummary:\nRef T10747. This isn't done and literally took me all day, but the basics are kind of working and I think I mostly just have to fill in a few more things and then heap piles and piles of tests on it.\n\nHere's an RRULE that is difficult to evaluate quickly:\n\n```\n    $rrule = id(new PhutilCalendarRecurrenceRule())\n      ->setStartDateTime($start)\n      ->setFrequency('SECONDLY')\n      ->setByMonth(array(1))\n      ->setByMonthDay(array(1))\n      ->setByHour(array(12))\n      ->setByMinute(array(0))\n      ->setBySecond(array(0));\n```\n\nHere's how long it takes to evaluate on various RRULE libraries:\n\n| PhutilCalendarRecurrenceRule | Instantaneous |\n| php-rrule | 11 seconds |\n| rrule.js | Completely Freezes |\n| python-dateutil | 7 seconds |\n| recurr (PHP) | Didn't actually test it, but looks like the same code |\n\nApparently someone wrote `python-dateutil`, and then people have just been porting that to other languages ever since. `python-dateutil` is not very fast at evaluating these kinds of rules, and all of the ports seem worse.\n\nIn the case of `recurr`, it looks like someone ported `python-dateutil` to JS (`rrule.js`), then ported the JS to PHP.\n\nThe structure of //all// these libraries appears essentially the same, and they pretty much brute force their way through evaluating rules like this.\n\nIt isn't really important to be able to evaluate this rule quickly, and I haven't finished this implementation so may approach may actually be garbage that I have to throw out, but being dramatically better in one contrived edge case makes me feel like I accomplished something more than gaining a deeper personal understanding of RRULEs by implementing this.\n\nTest Plan: Unit tests.\n\nReviewers: chad\n\nReviewed By: chad\n\nManiphest Tasks: T10747\n\nDifferential Revision: https://secure.phabricator.com/D16599","distinct":true,"url":"https://api.github.com/repos/wikimedia/phabricator-deployment/commits/98b662bb4d6bc4d175b6c573fdfb9a6d5b6983b9"}]}
{"actor":{"display_login":"wmfgerrit"}}