[00:00:00] do you think it's required for this commit? [00:00:18] Extensions using it? [00:00:37] Yeah, gotta keep it [00:00:43] Even WMF extensions call the stuff in it [00:01:06] CentralAuth, FlaggedRevs, LQT... etc [00:01:23] I meant the deprecation itself, wasn't proposing to drop it on sight:) [00:02:14] Too early for hard deprecation :P [00:28:32] call_user_func() works 4 times slower in HHVM than in PHP7 [00:28:41] gj Facebook [01:11:58] Amir1: That patch is good to merge, but as James_F said I'd like to wait until after the cut tomorrow. I have tomorrow off, but hopefully you can find someone (e.g. James_F) to merge it for you after the cut, and otherwise I can do it on Wednesday [02:32:42] MaxSem: RE: call_user_func, data/link? Sounds interesting :) [05:06:13] no_justification: for the tarball change to use mw/vendor, am I supposed to edit branch.py or makerelease.py? [15:05:05] <_joe_> I would need someone to sanity-check https://gerrit.wikimedia.org/r/437481 [15:05:22] <_joe_> but I'd really like to remove that check [15:13:51] https://github.com/wikimedia/puppet/blob/c2ab0140a149efcc32948b277fd5b8a9f906dbc2/modules/role/manifests/mediawiki/scaler.pp#L5 [15:13:59] Is that role not included anywhere now then? [15:15:15] videoscalers include it... [15:31:35] <_joe_> Reedy: yes, but videoscalers don't need to disable output compression [15:31:41] <_joe_> they return json :P [15:32:57] heh [15:33:11] <_joe_> (I got here from refactoring the puppet code, actually [15:34:13] LGTM to remove, it's basically if ( false ) {} at this point [15:42:01] <_joe_> but an if (false) that requires doing a syscall [15:42:17] <_joe_> this is actually a good question for my SRE interviews :) [15:42:44] <_joe_> (also, we have stat_cache = true in hhvm, so it shouldn't be too expensive) [15:42:59] <_joe_> unless that only works for the code files [15:43:24] I'm not saying it should stay around [15:43:41] I'm just saying, the fact that it is if (false) with a potential perf overhead... it's even more reason to get rid [16:34:03] legoktm: Both, but more immediately would be makerelease.py [16:34:17] branch.py would be "before we do the next branching" [16:34:45] In makerelease.py, we can just drop the composer logic (and the corresponding os.chdir() calls that have plagued me) [16:34:56] And the clone-with-recursion stuff should Just Work [17:37:57] Hm.. is a url like this supposed to actually parse and render on GET? `https://en.wikipedia.org/wiki/Special:ExpandTemplat es?wpContextTitle=Barack_Obama&wpInput={{:Barack_Obama}}` [17:38:04] I was expecting it to fill out fields only [17:38:12] (remove space in the middle to check) [18:04:54] it seems that the at ease dep in TemplateStyles breaks when you install it in mediawiki vendor (which is the default) [18:05:02] PHP Fatal error: Cannot redeclare MediaWiki\quietCall() (previously declared in /srv/mediawiki/w/vendor/mediawiki/at-ease/src/Functions.php:69) in /srv/mediawiki/w/extensions/TemplateStyles/vendor/wikimedia/at-ease/src/MediaWiki/Functions.php on line 45 [18:06:12] Something sounds out of date there [18:07:48] Yeah [18:07:55] paladox: src/Functions.php shouldn't still exist [18:07:56] See https://github.com/wikimedia/at-ease/commit/d58ac09356514fdc2c7a5f5e73e32a4e269b600f [18:08:15] oh [18:08:16] this is mw 1.30 [18:08:23] oh i see [18:08:44] https://github.com/wikimedia/mediawiki/blob/REL1_30/composer.json#L27 [18:09:07] i guess one of TemplateStyles deps is pulling a old at ease version [18:09:07] Oh [18:09:10] No, I see the problem [18:09:13] oh [18:09:15] You've got two vendor repos [18:09:29] Bringing in two different copies of at-ease [18:09:40] yep (the ext did that) :) [18:09:48] The ext didn't do it magically itself [18:09:55] Someone ran composer update/install in the extensions dir [18:09:59] i ran composer install [18:10:13] yeh me. [18:10:16] as it was needed [18:10:20] No it wasn't [18:10:20] because it was failing with: [18:10:27] Error from line 74 of /srv/mediawiki/w/extensions/TemplateStyles/TemplateStylesContent.php: Class 'Wikimedia\CSS\Parser\Parser' not found [18:10:28] before [18:10:48] https://www.mediawiki.org/wiki/Composer#Using_composer-merge-plugin [18:11:04] Oh! [18:11:27] thanks! [18:12:06] css-santizer can be used standalone, so I guess that tries to bring in at-ease too (IIRC)... [18:12:19] yeh [18:12:28] Reedy so that merge composer would fix this? [18:12:39] "fix" (it's a hack) [18:12:49] But it would mean you don't have conflicting copies of at-ease [18:12:53] ok [18:12:54] thanks [18:12:57] will try now! [18:12:58] or multiple vendor repos [18:16:30] Hm.. wgBackendTime and wgHostname are gone on mw.org [18:16:52] and on enwiki [18:17:24] but working fine on beta [18:20:13] echo wfReportTime(); is working fine from eval.php on the same server, so must be something going wrong later on [18:36:34] Krinkle: wat data? [18:36:53] The thing that looks like mw.config.set({"wgBackendResponseTime":999,"wgHostname":"20e70295f2ab"}) [18:37:02] It's missing in prod somehow [18:37:10] debugging on mwdebug1001 at the moment to figure out why [18:37:24] fine locally and in beta, also find in prod via eval.php when I call the thing that makes it directly. [18:37:28] So probably a hook or something [18:38:11] I mean "19:32 MaxSem: RE: call_user_func, data/link? Sounds interesting :)" [18:38:31] MaxSem: Ah you were saying call_user_func is slower on HHVM than PHP7. [18:38:37] or rather, faster on PHP7 [18:39:25] yep [18:40:23] funnily, on PHP 5.6 call_user_func() is way slower than just using the callback, but they've fixed it for 7 [18:42:01] MaxSem: Right, and for HHVM still somewhat slower? [18:42:26] if you call 4x "somewhat":P [18:42:53] https://3v4l.org/mU33f [18:43:46] Depends on the original [18:43:58] if it was 0.00000000001 vs 0.00000000004 [18:44:00] Who cares [18:44:09] but 4s vs 1s is care worthy [18:48:22] today, 3PM SF? [18:49:24] wrong tab [18:49:59] MaxSem: Wait, I don't see a 4x /relativel/ difference between syntax vs user_func. I do see a 4x absolute difference between the pHP7 and HHVM values but that's not necessarily representative. I mean, it shows the php plain syntax being slower in HHVM as well. [18:50:17] HHVM 3.22.0: call_user_func_array(): 0.48 / PHP syntax: 0.48 [18:50:45] HHVM 3.18: call_user_func_array(): 0.38 / PHP syntax: 0.42 (faster even than plain syntax ?!) [18:52:16] I meant HHVM is slower [18:53:54] Right, this server shows HHVM executing slower in absolute time, but I don't see it showing 'call_user_func_array' in particular being slow on HHVM compared to normal call syntax. [18:57:55] never said that [18:58:02] only php 5.6 [19:00:04] kk :) [19:00:42] Yeah, the PHP 5 results show call_user_func having significant overhead. But on HHVM and PHP7 they're mostly equal. [19:01:57] Reedy hmm i get this: [19:01:57] PHP Fatal error: Cannot redeclare MediaWiki\suppressWarnings() (previously declared in /srv/mediawiki/w/vendor/mediawiki/at-ease/src/Functions.php:28) in /srv/mediawiki/w/vendor/wikimedia/at-ease/src/MediaWiki/Functions.php on line 30 [19:02:05] after doing the composer merge thing [19:02:09] (freshly cloned) [19:03:12] Where is it getting src/Functions.php from? [19:03:29] from composer (i removed the vendor submodule) [19:03:36] so it's directly using composer.json now) [19:03:44] https://github.com/wikimedia/mediawiki/blob/REL1_30/composer.json [19:03:54] "mediawiki/at-ease": "1.1.0", [19:04:04] but i presume it's a dep of TS and using a old version [19:04:08] https://github.com/wikimedia/at-ease/tree/v1.1.0/src [19:04:36] https://github.com/wikimedia/mediawiki-extensions-TemplateStyles/blob/REL1_30/composer.json#L5 [19:05:01] https://github.com/wikimedia/css-sanitizer/blob/v1.0.2/composer.json#L28 [19:05:20] Using the correct branch of TemplateStyles? [19:05:36] https://github.com/wikimedia/css-sanitizer/blob/v1.0.3/composer.json#L26 [19:05:42] Reedy hmm /me checks [19:06:19] Reedy i am using REl1_30 of that ext [19:06:20] HEAD, origin/REL1_30 [19:06:25] according to git log [19:06:31] last commit september 2017 [19:06:50] Where are you referencing css-sanitizer 1.0.3 from then? [19:07:55] https://github.com/wikimedia/mediawiki-extensions-TemplateStyles/blob/REL1_30/composer.json#L5 [19:08:08] Oh [19:08:12] ~1.0.2 [19:08:20] So that'll do 1.0.3 [19:08:25] modifiers are silly [19:08:44] https://github.com/wikimedia/at-ease/tree/v1.1.0 [19:09:04] that is old. [19:09:16] Reedy https://github.com/wikimedia/at-ease/commit/d58ac09356514fdc2c7a5f5e73e32a4e269b600f was done in 1.2.0 [19:09:22] where as mw 1.30 uses 1.1.0 [19:11:21] I don't get how you're seemingly getting two versions of at-ease in one folder at least [19:12:50] oh it's using the new version [19:12:52] when i look [19:12:56] but have no idea how [19:13:13] check your composer.json/composer.lock? [19:14:01] * paladox looks [19:14:18] shows [19:14:18] "version": "v1.1.0", [19:14:36] and [19:14:37] "version": "v1.2.0", [19:15:03] oh [19:15:06] found it reedy [19:15:07] "name": "wikimedia/css-sanitizer", [19:15:12] is pulling in the new version [19:15:17] "version": "v1.0.6", [19:15:20] [20:08:01] ~1.0.2 [19:15:20] [20:08:09] So that'll do 1.0.3 [19:15:28] Let's fix that [19:15:52] ok [19:16:31] It doesn't explain how you've got two files from different versions in the same vendor folder though [19:16:42] yeh [19:16:52] i was using the merge composer plugin [19:16:55] so that could have done it? [19:17:20] No [19:17:24] It would install one version [19:17:32] It wouldn't munge two versions of a library into the place [19:17:43] https://github.com/miraheze/mediawiki [19:17:55] that's where i am installing from [19:20:38] https://gerrit.wikimedia.org/r/#/c/437532/ [19:20:54] Reedy thanks! [19:21:03] +1'ed [19:23:37] some how it's still pulling 1.2.0 in. [19:24:03] oh wikimedia/css-sanitizer is [19:24:40] hmm does ^1.0 == (1.2, 1.3)? [19:24:54] IIRC, yup [19:25:18] Reedy then wikimedia/php-session-serializer is also pulling in it [19:25:24] "mediawiki/at-ease": "^1.0", [19:27:05] Lets fix one problem at a time [19:27:12] Can't merge to RE1_30 yet\ [19:28:08] ok [19:29:43] Oh look [19:29:44] https://integration.wikimedia.org/ci/job/quibble-composer-mysql-php55-docker/20/console [19:29:53] 19:29:16 PHP Fatal error: Cannot redeclare MediaWiki\suppressWarnings() (previously declared in /workspace/src/vendor/mediawiki/at-ease/src/Functions.php:28) in /workspace/src/vendor/wikimedia/at-ease/src/MediaWiki/Functions.php on line 30 [19:30:23] heh [19:31:03] 19:28:50 [261.2MB/10.97s] Extracting archive[261.2MB/10.99s] - Installing mediawiki/at-ease (v1.1.0): [261.2MB/10.99s] Downloading[261.2MB/11.12s] (100%)[261.2MB/11.12s] [19:31:09] But that version of at-ease doesn't have those files [19:31:20] https://github.com/wikimedia/at-ease/tree/v1.1.0/src [19:31:33] hmm [19:33:32] reedy@ubuntu64-web-esxi:~/test-composer$ composer require mediawiki/at-ease:v1.1.0 [19:33:35] Does what is expected [19:34:01] 19:29:07 [437.7MB/28.10s] Installs: wikimedia/at-ease:v1.2.0, wikimedia/css-sanitizer:v1.0.6 [19:34:33] * Reedy forces [19:35:06] hmm [19:36:12] I guess we've messed up semver a bit somewhere along the lines [19:36:21] Might be worth checking REL1_31 too after [19:36:32] yep [19:36:42] will check after i get 1.30 working! [19:36:52] caused some of our sites to go down when using TemplateStyles [19:37:06] I force merged the removal of ~ in the composer.json in REL1_30 [19:37:27] oh [19:38:08] so feel free to git pull that in and see what happens [19:38:16] ok [19:38:17] I'm just merging the patch to unbreak the CI build [19:38:18] * paladox will [19:40:43] Tests break.. [19:41:12] cheh [19:44:04] anomie: About? Seen these test failures in TemplateStyles? [19:44:05] 19:39:52 1) TemplateStylesHooksTest::testTag with data set "Tag with valid but nonexistent title" (ParserOptions Object (...), '', '