[01:55:00] <James_F>	 twkozlowski: *grumble* https://meta.wikimedia.org/w/index.php?title=Tech/News/2014/23&diff=8719743&oldid=8719650 – pieces of functionality going away and highly visible toolbar changes are removed, whereas a trivial bug that might have irritated a few sysops and rollbackers gets expanded? I think the priorities might be wrong…
[02:00:15] <^d>	 James_F: Functionality going away?
[02:01:20] <James_F>	 ^d: We removed the button to insert a new <gallery> from VE because (a) it confused the hell out of users testing it and (b) it's just a really horrible wikitext editor tool.
[02:01:52] <James_F>	 ^d: You can still edit galleries that exist on the page, and copy/paste existing galleries from other pages if you really want one, but for a few months you won't be easily able to make one in VE.
[02:01:56] <^d>	 Oh ok, nevermind. I glanced at that page and got confused...I thought you were talking about the search prefs moving away.
[02:02:07] <James_F>	 ^d: Ha, no, your code changes are awesome. :-)
[02:04:47] <^d>	 Hmm, who's about who knows git well?
[02:04:53] <^d>	 Like...really freaking well.
[02:06:38] <^d>	 All my usual victims are |away or somesuch.
[04:11:54] <jackmcbarn>	 when i go to http://en.wikipedia.beta-hhvm.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures i get Internal error: [777fdb78] /wiki/Special:Preferences Exception from line 832 of /srv/common-local/php-master/includes/jobqueue/JobQueueRedis.php: Redis server error: Could not insert 1 updateBetaFeaturesUserCounts job(s).
[04:21:34] <legoktm>	 hmm
[04:23:12] <jackmcbarn>	 of particular note is that if i remove the -hhvm it works fine
[07:32:27] <Nemo_bis>	 Gotta move some pages... now let's see who bites me first, $wgRateLimits or Krinkle|detached's hideous dropdown
[07:37:07] <Nemo_bis>	 Other than the usual "Read bits.wikimedia.org..." perennial status
[09:34:38] <twkozlowski>	 https://meta.wikimedia.org/w/index.php?title=Tech/News/2014/23/en&action=history
[09:34:55] <twkozlowski>	 7 edits in 7 seconds
[18:58:54] <MatmaRex>	 twkozlowski: tech news material: https://gerrit.wikimedia.org/r/#/c/112236/
[19:00:31] <twkozlowski>	 Thanks MatmaRex, will add it
[19:37:39] <twkozlowski>	 MatmaRex: Could you upload the screenshot to Commons so I don't have to link to imgur?
[19:38:09] <twkozlowski>	 Both, preferably, or you can combine them in one screenshot, I have no preference
[19:57:22] <Nemo_bis>	 twkozlowski: just upload them to the bug
[20:02:48] <twkozlowski>	 Good idea Nemo_bis
[20:41:27] <twkozlowski>	 Tech News #23 has now been published: https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2014/23
[20:52:09] <T13|sleeps>	 Why is {{#time:F Y}} returning "May 2014" & {{#time:F Y|+1 month}} returning "July 2014"?  Parser forget about June?
[20:58:46] <Nemo_bis>	 T13|sleeps: how many days is +1 month?
[20:59:18] <T13|sleeps>	 1 months worth.
[20:59:22] <Nemo_bis>	 31 May + 31 days = 1st July
[20:59:29] <Nemo_bis>	 That's not an answer to my question
[20:59:44] <Nemo_bis>	 Unless they forgot to tell you in primary school that not all months have the same number of days,
[20:59:49] <Reedy>	 poor Nemo_bis
[20:59:53] <Nemo_bis>	 at least in our current calendar
[21:00:24] <Nemo_bis>	 If the French had been more convincing in the 18th century it might have been different
[21:00:49] <T13|sleeps>	 The parser shouldn't be calculating +1 month as days.  It should say this is month 5 +1 is month 6 which is June.
[21:01:56] <Reedy>	 Do we just delegate to php?
[21:02:18] <Reedy>	 This does feel de ja vu
[21:02:36] <Krenair>	 Yeah...
[21:02:54] <{{Technical_13}}>	 Sorry, lost connection for a minute.
[21:02:57] <Krenair>	 (yes it feels like de ja vu, don't know if we just send it straight to some php function)
[21:02:58] <{{Technical_13}}>	 The parser shouldn't be calculating +1 month as days.  It should say this is month 5 +1 is month 6 which is June.
[21:03:09] <Krenair>	 {{Technical_13}}, yep, we got that bit. next message was your joining so you missed nothing
[21:03:18] <{{Technical_13}}>	 Cool
[21:04:15] <{{Technical_13}}>	 In my use case I can make a hack to work around the issue, but it will be ugly and not ideal.
[21:05:30] <Nemo_bis>	 +1 month is used in combination with all time formats
[21:06:04] <Nemo_bis>	 Though it's probably silly to ask what time will it be in current time + 1 month
[21:06:22] <Reedy>	 php > var_dump( gmdate("Y-m-d\Z", strtotime( "now + 1 month" ) ) );
[21:06:22] <Reedy>	 string(11) "2014-07-01Z"
[21:06:25] <Reedy>	 It's not mediawiki
[21:06:54] <Nemo_bis>	 Now should we be happy or sad with this :)
[21:07:24] <Reedy>	 php > var_dump( gmdate("m", strtotime( "this month" ) ) );
[21:07:24] <Reedy>	 string(2) "05"
[21:07:24] <Reedy>	 php > var_dump( gmdate("m", strtotime( "next month" ) ) );
[21:07:24] <Reedy>	 string(2) "07"
[21:07:27] <Reedy>	 that is amusing though
[21:07:48] <Nemo_bis>	 seems to be widely discussed
[21:07:48] <Krenair>	 Bugs?
[21:07:51] <Krenair>	 In PHP's time handling functions?
[21:08:08] <Reedy>	 God Bless PHP.
[21:08:29] <Nemo_bis>	 https://bugs.php.net/bug.php?id=44073 ?
[21:08:30] <{{Technical_13}}>	 I can do something like: {{#time:F Y|{{#expr:{{#time:n}}+1}},15 {{#time:Y}}}}
[21:08:56] <Reedy>	 ""first day of +1 month" or "first day of next month" or even "last day of next month" - those are always safe to use with just a "m" or another month date format specifier."
[21:09:13] <Nemo_bis>	 "Status: 	Not a bug" "An existing bug report already describes this very problem"
[21:09:22] <Nemo_bis>	 Helpful
[21:09:25] <Reedy>	 RESOLVED WORKSFORME
[21:10:06] <Nemo_bis>	 https://bugs.php.net/bug.php?id=22486&edit=2
[21:10:16] <Nemo_bis>	 Is this really the ultimate answer?
[21:11:12] <Krenair>	 Our side of this is ExtParserFunctions which creates a DateTime object
[21:11:16] <Nemo_bis>	 I mean, it's not that hard +n months ~ + sum of days of n months after the currentone
[21:12:02] <Nemo_bis>	 Ugly but not impossible (hopefully forbidden by some standard?)
[21:12:36] <Krenair>	 ExtParserFunctions::time* even
[21:16:46] <Nemo_bis>	 Reedy: can you help me with https://meta.wikimedia.org/wiki/Research:The_sudden_decline_of_Italian_Wikipedia ?
[21:17:02] <Nemo_bis>	 I'd like to know if itwiki is more frequent of other top10 Wikipedias in slowparse.log
[21:17:32] <Nemo_bis>	 Hopefully it's as easy as a zgrep -c itwiki $WHATEVER ?
[21:19:18] <Reedy>	 reedy@fluorine:/a/mw-log$ grep -c "itwiki" slow-parse.log
[21:19:18] <Reedy>	 13279
[21:19:18] <Reedy>	 reedy@fluorine:/a/mw-log$ grep -c "dewiki" slow-parse.log
[21:19:18] <Reedy>	 6962
[21:19:18] <Reedy>	 reedy@fluorine:/a/mw-log$ grep -c "enwiki" slow-parse.log
[21:19:19] <Reedy>	 157638
[21:19:22] <Reedy>	 reedy@fluorine:/a/mw-log$ grep -c "frwiki" slow-parse.log
[21:19:24] <Reedy>	 41041
[21:19:26] <Reedy>	 reedy@fluorine:/a/mw-log$ grep -c "ruwiki" slow-parse.log
[21:19:28] <Reedy>	 14459
[21:19:33] <Reedy>	 The germans are not slow apparently
[21:22:05] <Nemo_bis>	 And the French are. Presumably all the processors and templates are constantly on strike.
[21:22:22] <Reedy>	 https://meta.wikimedia.org/wiki/Research_talk:The_sudden_decline_of_Italian_Wikipedia#slow-parse.log
[21:22:28] <Nemo_bis>	 Thanks!
[21:22:35] <Nemo_bis>	 Will need to think a bit about it
[21:22:54] <Reedy>	 It's not as slow as enwiki
[21:22:57] <Reedy>	 RESOLVED INVALID
[21:23:03] <Nemo_bis>	 Ugh variance from day to day is huge
[21:23:11] <Nemo_bis>	 So comparing one day is totally meaningless
[21:26:00] <Reedy>	 Nemo_bis: Do you want a pretty graph making in Excel?
[21:26:01] <Reedy>	 :p
[21:30:29] <Nemo_bis>	 :D
[21:31:47] <Nemo_bis>	 Number of reparses is probably dominated by number of edits, just need to calculate slow parses / edits ratio and the standard deviation
[21:33:30] <Reedy>	 blah blah stats blah blah
[21:34:23] <Nemo_bis>	 Yeah, that should be the result