[03:24:04] I'm getting 'Fatal error: Class 'Monolog\Formatter\LineFormatter' not found in /Users/ori/www/w/includes/debug/logger/monolog/LineFormatter.php on line 39' from the unit tests [03:24:10] I ran 'composer update' [03:25:46] looks like a case of https://github.com/laravel/framework/issues/1368 [03:27:37] it might be worth having code that triggers the auto-loading of that class in the unit test bootstrapping code [12:12:06] 10MediaWiki-Core-Team, 5Patch-For-Review: ObjectCacheSessionHandler should avoid pointless writes in write() - https://phabricator.wikimedia.org/T88635#1502769 (10Ciencia_Al_Poder) Changes reverted due to {T102199} [15:26:23] ori: looks like that bug may have been fixed in PHP 5.4.17 -- https://bugs.php.net/bug.php?id=65322 [15:26:41] I wonder if hhvm has the pre-fix problem still? [15:26:45] (seems likely) [15:27:05] this was on php 5.6 [15:27:14] :( [15:27:16] so maybe not the same issue after all [15:28:43] It definitely sounds like an autoloader failure [15:28:57] the question I guess is where it comes from [15:29:25] * bd808 is doing combat with lighttpd in tool labs and losing [15:35:51] w00t! I beat it into submission! -- https://tools.wmflabs.org/bash/search?q=ori [15:52:48] bd808: awesome! :) [15:52:54] yay 20% time, or something :P [15:53:14] that was mostly "ignore my wife on the weekend to hack time" [15:53:34] figured [15:54:08] I went camping and got stung by a wasp (yellow jacket). Arm is now swollen and red, still (since Sat night). So, I was anti-productive this weekend. [15:54:42] It was/is also a test of using classes I extracted from the scholarships and grants apps into a base library for making more slim+twig+monolog apps [15:55:03] nice, truly productive [15:55:19] yuck. I've never had a bad reaction to a sting thankfully [15:56:00] me neither until this weekend [15:56:18] (haven't been stung a lot, just as a stupid teenager poking bee hives) [15:56:58] I had one epic day of being stung when I was ~11 [15:57:43] stepped on a nest of ground bees while working; dropped my tools an ran; had to come back later to get them [15:58:59] wtf are ground bees [16:00:24] https://entomology.cals.cornell.edu/extension/wild-pollinators/native-bees-your-backyard [16:02:01] ground bees == bees that nest in a hole in the ground [16:04:17] yeah i am five wikipedia articles deep by now [16:04:26] trying to guess which species it was. this was idaho, yeah? [16:04:38] NW Oregon [16:04:56] could be https://en.wikipedia.org/wiki/Andrena_salicifloris [16:29:35] 10MediaWiki-Core-Team, 5Patch-For-Review: ObjectCacheSessionHandler should avoid pointless writes in write() - https://phabricator.wikimedia.org/T88635#1503406 (10Legoktm) 5Resolved>3Open [16:44:27] robla's bouncer is having a very bad morning [17:19:52] ori: https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation [17:38:55] Of the may great candidates, I think this is my favorite TimStarling quip -- https://tools.wmflabs.org/bash/quip/AU7VTvVV6snAnmqnK_pD [17:53:07] hahaha [17:59:32] A good one, indeed [18:00:50] "unfortunately my psychic debugging skills don't extend as far as actually telling you what line of code the issue is in" [18:01:13] https://tools.wmflabs.org/bash/quip/AU7VTUaU6snAnmqnK_n2 [18:02:09] Also, https://tools.wmflabs.org/bash/quip/AU7VTzhg6snAnmqnK_pc [18:02:15] My favorite ^ [18:16:12] bd808: is there no pagination on search? https://tools.wmflabs.org/bash/search?p=0&q=Tim doesn't find https://tools.wmflabs.org/bash/quip/AU7VTFOl6snAnmqnK_nB [18:16:50] https://tools.wmflabs.org/bash/search?p=0&q=TimStarling [18:16:57] No stemming [18:18:17] It uses this qs syntax -- https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html [18:19:36] there's pagination, but it only shows up if there is more than one page of results [18:57:05] AaronSchulz: "enqueue: 6867670 queued; 0 claimed (0 active, 0 abandoned); 0 delayed" on enwiki [19:08:18] I wonder some level of deduplication is missing [19:24:55] hoo: yeah the EnqueueJob itself is not de-duplicated, though when it runs, the push() it does will be [19:25:20] what's the size of the actual wikibase-addUsagesForPage queue? [19:25:22] ok... so it just needs more runners? [19:25:48] * AaronSchulz feels deja vu with the opportunistic links update jobs [19:29:30] hmm, the problem in that case was removeDuplicates missing from JobSpecification specs, but that's not the problem with wikidata here [19:29:48] mh [19:31:11] hoo: does wikidata check the DB before push(), like how triggerOpportunisticLinksUpdate() does? [19:31:28] (not sure if that is applicable in this context or not) [19:31:39] check as in check with slaves whether we need to update? [19:31:47] yes [19:32:03] Not really, no [19:32:22] I had some ideas for that, but it's not trivial to get that right [19:32:35] EnqueueJob itself should support de-duplication really [19:33:15] it does nothing but relay, so it could inherit the deduplication if all the jobs to be pushed had the flag set or something [19:33:23] especially in simple 1-job cases like this [19:35:29] yeah, that sounds doable [19:35:48] I made a task [19:35:50] I think we often have touched => wfTimestampNow() so we would need to handle that in a smarte way [19:36:03] otherwise all these will be unique (as the default just take all params into account) [19:53:11] hoo: hah, the jobs are for Main_Page ;) [19:56:50] meh, enqueue always does that [20:51:47] "Time to first render on mobile does not take more time than desktop (as measured by graphite)" -- https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q1_Goals#Reading [20:51:51] \o/ [21:05:16] bd808: http://graphite.wikimedia.org/render/?width=586&height=308&_salt=1438635891.112&target=frontend.navtiming.firstPaint.mobile.overall.median&target=frontend.navtiming.firstPaint.desktop.overall.median&from=-10days [21:05:25] I'm not sure they'll hit it [21:05:41] ouch [21:07:36] That doesn't necessarily mean it's not worth striving for :-) [21:07:48] of course not [21:07:56] i'm not sure we'll hit our target either [21:08:22] do they top-load everything? Or is it worse problems than that? [21:08:30] I think it would be goood if there was as system to cross multi quarter estimates and not be a failure [21:08:58] like 3 quarters "mobile and desktop render match" and then break some less flashy language into quarters [21:09:04] but maybe that's crazy talk [21:09:48] measurable KPIs for exploratory work are tricky in general [21:10:00] and for non-exploratory work they are usually lies [21:10:12] bd808: part of it is that mobile devices have substantially worse connection profiles than desktop computers, and the metric they chose to target is RUM [21:10:13] "get 50% more customers" [21:10:53] ah. yeah 2G vs a nice cable modem connection is going to be different for sure [21:10:55] however, mobile web is currently also slower than desktop in synthetic tests which control for bandwidth and latency [21:11:02] *nod* [21:11:12] that seems like a real target [21:11:26] http://i.imgur.com/XSx2XId.png [21:11:29] 22% [21:12:22] mobile does weird things that will make it slower. it basically tries to rewrite the html after it comes out of the parser to make it (in theory) fit smaller screens [21:12:44] bd808, it's currently done only on main page [21:13:05] MaxSem: oh? all the other transforms are done client side? [21:13:20] as for why, it's hard to say. The high-level story, I think, is that the mobile web team thought ResourceLoader was too complex and too bloated for their requirements, so they hacked around it [21:13:32] the rest is a bunch of display: none; these days ;} [21:13:47] as time went on, big surprise, what looked like overcomplicated cruft proved to be solutions to real problems [21:14:02] heh [21:14:05] well, MF is an evolutionary development of an old Ruby gateway [21:14:05] agile fail [21:14:18] Ruby hacked HTML a lot, thus MF did that too [21:14:33] over the time, we pushed for reduced HTML manupulations [21:14:36] so the mobile web codebase comprises several layer of misdirection on top of mediawiki [21:14:41] *layers [21:14:53] and these layers love to hide performance problems [21:15:15] main pages is something that still has to be done, because communities still serve main pages that are FUBAR on narrow screens [21:16:01] but if some wiki has mobile-friendly main page, there's a switch to disable transformations [21:16:49] *nod* tables and mobile are usually not friends [21:17:08] and there is a lot of "just put it in a table" layout in the wikiks [21:17:10] even divs have to be done smartly for mobile [21:18:11] also, mobile main pages are much more light beause of this, which MAKES THEM FASTER!!1ONEONEONE [21:24:08] special:blankpage would be even faster [21:24:24] HELL YEAH [21:38:31] ostriches: https://gerrit.wikimedia.org/r/#/c/228902/ [23:13:29] legoktm: https://gerrit.wikimedia.org/r/#/c/224656/ [23:14:38] AaronSchulz: is there a reason hasFlags is public? [23:15:41] convenience for callers that want to check flags properly. I've seen enough <> bugs. [23:17:22] ok [23:20:46] but yes, the main function would be all that's needed in common cases