[00:46:37] Krinkle: No concious reason I think. Probably I was thinking that since "global" is the default, it's more obvious when reading to have a key called "noglobal". I think you're probably right that 'global' => false is probably more consistent [01:31:21] Reedy: https://github.com/composer/composer/pull/6696 [01:46:07] James_F: do you want to merge https://gerrit.wikimedia.org/r/#/c/374422/ now since the branch cut already happened? [01:48:36] * TimStarling rants on wikitech-l [03:12:32] legoktm: I think so. [03:43:41] TimStarling, your accounting of the PHP dev community was pretty negative .. but i think you basically seem to be saying, there is really no choice here given that Hack is a non-starter ... and that the brokenness of the PHP dev community might actually be a bug-feature in terms of providing stability. [03:44:32] pretty much [03:49:53] hmm .. ok. on principle i tend to favour floss products, but ... unless Hack / hhvm migrates to an independent development organization, it is unclear what direction that will go ... i suppose this is somewhat of a mirror of the mediawiki foundation conundrum. [03:54:33] right, the scary thing about locking in facebook as a vendor is that we don't really know if they share our interests [03:54:55] if there was a separate org that actually depended on people like us using their product, it would be different [03:55:11] yup. [17:25:27] * anomie sees T176080, and is happy he will no longer have to manually ignore it when grep turns up uses of things being removed in that repo. [18:02:19] no_justification: what's the timeline on 1.30 branching? https://gerrit.wikimedia.org/r/#/c/378978/ [18:02:48] Um. We said a thing [18:03:03] Trying to remember what I agreed to [18:03:38] Maybe James_F can be the branch master this time ;-) [18:04:25] no_justification: Y'all said that 1.30.0-wmf.19 was the last alpha branch of MW 1.30. [18:04:40] I have a few EditPage deprecations (some written, some still in my head) I still want to get into 1.30 and need to figure out how much time I have left :) [18:05:02] no_justification: I'd be happy to run the script and direct all the problems at you, but… ;-) [18:05:11] RUN FOR IT LEGO! [18:05:52] Downside is we didn't "announce" it. [18:05:59] I mean yeah it was on wiki but I like to give people some lead time. [18:06:08] What if we made .20 the last one? I wouldn't mind losing 1 week [18:06:17] that would be appreciated :) [18:06:34] no_justification: So the current plan is that next week's branch will be 1.31.0-wmf.1 and REL1_30 will get cut based off c3a0f25c040e4f69daba5223393d99a03074b0a0 ? [18:06:42] no_justification: Gah. [18:06:47] Well legoktm asked nicely [18:06:56] no_justification: I spent about an hour changing everything in Phab last week. [18:07:08] Now you want me to spend the time again re-adjusting? :-( [18:07:36] Grrrrrrrrr [18:08:01] I don't care what the timing is, but it changing is unhelpful. [18:08:06] There's gonna be hella backports [18:08:08] But fine [18:08:13] There always are. [18:08:20] moar than usual [18:09:02] I also think we should uncouple wmf.X branches from core branch #s. [18:09:05] But that's another day [18:09:12] Yes. :-) [18:10:29] Date-based branch names would be kinda nice [18:10:31] backports aren't too bad for me, no one else is dumb enough to touch EditPage [18:10:46] wmf/20170913 [18:12:13] eurgh [18:12:31] sequential numbers are so much easier to keep in your head [18:17:34] dates are easier to automate, still sort nicely, and answer the eternal question of when a branch was created [18:18:14] Well, not much easier [18:18:15] But still [18:18:22] Anyway, I've had and lost this fight before [18:31:06] EditPage patches if someone wants to review: https://gerrit.wikimedia.org/r/#/c/374422/ https://gerrit.wikimedia.org/r/#/c/379170/ [19:22:31] Notice: Undefined property: stdClass::$ar_namespace in /srv/mediawiki/php-1.30.0-wmf.18/includes/diff/DifferenceEngine.php on line 190 [19:22:31] Notice: Undefined property: stdClass::$ar_title in /srv/mediawiki/php-1.30.0-wmf.18/includes/diff/DifferenceEngine.php on line 10 [19:30:45] no_justification: https://gerrit.wikimedia.org/r/379299 [20:33:29] James_F: I finished making REL1_30 branches...I think everywhere [20:33:38] Script is kinda wierd [20:33:40] *weird, even [20:34:02] no_justification: Yay. [20:37:19] no_justification: Also, `git log --no-merges --oneline REL1_30..origin/wmf/1.30.0-wmf.19 | grep -v "Update git submodules"` gives me 10 things to backport, of which two are a do/revert. [20:43:20] Oh yeah. [20:43:29] I need to add the submodules for the REL1_30 branch of core [20:43:33] Like I did in REL1_29 [20:43:36] That was helpful af [20:44:51] anomie: Thx, deployed [20:48:27] no_justification: I've made REL1_30 back-ports for most of them for the authors to consider: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:REL1_30 [20:49:05] +2'd the DiffEngine fix Brad just did for me in wmf.19 [20:49:37] * James_F nods. [20:50:53] Wanna send the e-mail to wikitech-l? [20:50:58] Share the credit for making me do it ;P [20:52:54] no_justification: I don't want people to complain to me. :-D [20:53:13] Though I seem to be tangentially involved in some of the fixes. [20:53:51] no_justification: Merge https://gerrit.wikimedia.org/r/#/c/378978/ and I'll send the wikitech-l e-mail after my next meeting? :-) [20:58:33] DanielK_WMDE: I did a double take when I got to the bit on https://phabricator.wikimedia.org/T173696 where you had to maintain PCRE compatibility because a user-run bot, KrBot, uses that format [20:59:30] you know we have code in scribunto that maps Lua patterns to PCRE regexes [20:59:42] you could write code that went the other way if you didn't mind the reduced feature set [21:00:47] RFC meeting starting now in #wikimedia-office: Introduce InterruptMutexManager [21:03:02] James_F: That and I should bump MW core's version to 1.30.0-rc.0 [21:04:06] TimStarling: it probably wouldn't be so hard to change the bot either... but intersting point. can you comment on the ticket? or i can just copy what you just said, if you like [21:05:45] Er, bump the branch's [21:06:24] no_justification: Yeah, good point. [21:07:10] {{done}} [21:35:59] no_justification: while on the topic, wanna do the needful on https://phabricator.wikimedia.org/T175324 ? [21:37:52] really interesting how only JS developers defended Hack :P [21:43:20] if php7 had existed before we did the hhvm migration I really don't think we would have every gone that direction. [21:43:29] *ever [21:44:05] hhvm was useful in getting php7 moving forward again after the php6 debacle [21:44:29] there was some talk about that new shiny phpng though:) [21:44:52] in retrospect, we should have just waited [21:46:03] maybe I should write up a "Let's port to Python because StackOverflow just named it the fastest growing major language" conference proposal :) [21:46:33] https://stackoverflow.blog/2017/09/06/incredible-growth-python/ [21:58:15] yeah, we will only need 10 times as many appservers [21:59:27] ... because python is slower than php? Never in any head to head benchmarks I've ever done [22:00:19] its just a ridiculous idea at all to consider a 1:1 functional rewrite [22:01:11] I remember someone claiming PHP was 5 times faster - in the times of slow PHP 5.0 :P [22:01:32] I'd love to see the test for that :) [22:01:46] on a side note, Reddit is ditching Python in favor of Node XD [22:01:52] possibly in bare interpreter startup [22:02:35] python does a lot of IO to bootstrap the interpreter, but that's a one-time cost; you aren't spinning up a new interpreter on every request [22:03:32] yeah, in practice MW startup takes a while on WMF [22:03:39] (source: when I was writing a proper python sandbox to work with scribunto... I should maybe pick that up again) [22:03:47] especially autoloader is silly [22:03:48] yeah I do remember doing head to head CGIs in php, python, and ruby circa 2006 and php being the startup time winner by a large margin [22:03:54] if php7 had existed before we did the hhvm migration I really don't think we would have every gone that direction. [22:03:56] no kidding [22:04:25] "let's migrate to a new runtime written by Facebook which is 10% slower than PHP and requires minutes of JIT compilation time" [22:04:34] TimStarling, you wrote like 20k lines for HHVM? [22:04:49] :) I loved that benchmark you posted [22:04:59] I don't know, it was 6 months of development time, could have been that much [22:06:04] * bd808 hears manybubbles shout "Javafication!" at Tim's imagined argument [22:06:17] probably not that much, but yes, it was a lot of work [22:08:02] Victoria is looking at the enormous wikitech-l conversation and wants there to be process [22:08:17] whereas after that benchmark, I am now inclined to just start changing things in phabricator [22:09:11] gah [22:10:48] no_justification: Still want me to send the branch e-mail to wikitech-l? [22:10:56] TimStarling: Yeah, JFDI. [22:11:24] has anyone made a task yet for the transition to PHP 7 in production? [22:11:39] not yet [22:12:03] the migration plan that seems reasonable is to roll the OS to stretch and then convert to the php7 that stretch provides [22:12:22] there is a task for the stretch upgrade somewhere [22:12:35] I'm going to make a task which says "Migrate to PHP 7 in WMF production" [22:12:43] stretch upgrade can be a dependency [22:13:05] funnily, I was thinking up arguments to revert to PHP7 for months, last time I thought about it last weekend :P [22:13:59] TimStarling: "Migrate from HHVM to PHP 7 in WMF production" maybe, to be explicit? [22:14:06] T174431 [22:14:08] T174431: Migration of mw* servers to stretch - https://phabricator.wikimedia.org/T174431 [22:14:42] can we ensure that we ceise the opportunity and migrate to the newest PHP 7.1 independently of what stretch has? [22:15:28] MaxSem: if you can come up with an argument that will make techops want to maintain our own PHP debs indefinately [22:15:46] hehe [22:16:02] I thought there are backports available? [22:17:21] mainline stretch is 7.0.19 -- https://packages.debian.org/stretch/php7.0 [22:17:26] James_F: I won't be getting to it [22:17:32] buster has 7.1.8 -- https://packages.debian.org/buster/php7.1 [22:19:02] MaxSem: so yeah.. an argument could be made I suppose [22:19:15] it will probably land in backports eventually [22:19:27] I'll declare the task to be an RFC, to make Victoria happy [22:19:39] no_justification: Do you have a rough ETA for RC0 so I can say something? [22:19:49] or you could take that argument to the debian backports list :) [22:19:50] waaat, more 'cracy? :P [22:20:29] LET'S JUST GIVE JESSIE 7.2 BECAUSE WHY NOT? [22:21:01] T176370 [22:21:01] T176370: Migrate to PHP 7 in WMF production - https://phabricator.wikimedia.org/T176370 [22:22:07] stab stab https://phabricator.wikimedia.org/T121913#3623032 [22:22:36] \o/ [22:23:29] now the staffing fight begins... [22:25:08] no_justification: Sent. [22:28:56] MaxSem, heh, as long as php7.1 is in stretch then we can migrate phabricator which will benefit the performance improvements :) [22:35:11] James_F: Nitpick: branched from 0cd28e19cb, which was c3a0f25c04^1 [22:35:17] we wouldn't pull the wmf branch commit in ;-) [22:35:40] Oh, whoops. Too late now. [22:36:48] Crap. [22:36:52] I did branch from what you said [22:36:52] Shit [22:36:57] I done goofed [22:37:04] It's got all these submodules we don't want [22:37:32] force push a new branch [22:38:51] Nah, breaks sha1s from people who've fetched [22:38:55] I'll just issue a revert. [22:39:27] * no_justification pushes with +2 attached [22:42:23] TimStarling: Speaking of RepoAuth, I suppose if we are comparing to HHVM/Hack, we should think about PHP 7 vs Hack+RepoAuth as opposed to "just" Hack. [22:42:47] We haven't really begun to see the RepoAuth benefits, or maybe we have tried that (at least to get a benchmark) [22:44:19] Maybe the difference is marginal, but in theory it seems like RepoAuth-kind of compilation cache could have significantly better performance, but I suppose on the other hand, if it's anything like V8 (a little bit) it shouldn't require such model in the first place and could just get better as the run-time runs longer (e.g. not having to choose between compile cheaply once or compile slowly well, but start with cheap and get better [22:44:19] over time). [22:44:26] Which I suppose is what PHP 7 is doing or planning to do? [22:46:18] Aye, my bad. RepoAuth is also (and mainly) about not checking file mtimes than about pre-compiling [22:46:25] RA makes a lot of assumptions about the code that non-FB code breaks all the time. [22:46:52] it has non-trivial implications on deployment tooling as well [22:47:31] ori wrote a pretty good bug report upstream about how clunky using RA is [22:48:05] Yeah, it's not short-term. But if we do move towards snapshot-based deployments at some point, it seems like it'd be more feasible. It kind of poses the same set of problems and restrictions. [22:48:21] https://github.com/facebook/hhvm/issues/6878 [22:48:57] its really all moot if most of us don't trust FB to keep HHVM active and open [22:49:00] and I don't [22:49:49] next they will put a crayon license on it to "protect their IP" [22:53:43] Hence what I said on the thread: promises to be better at open source mean nothing [22:54:19] James_F: https://gerrit.wikimedia.org/r/#/c/379434/ [22:55:00] no_justification: Is it the right list this time? (Too soon?) [22:55:16] I copied it straight from master of make-release [22:55:21] Which has no add/drop sections anymore [22:58:07] SMalyshev TimStarling does php7 use an AOT or a JIT? [22:58:34] I don't think there's any real JIT in released PHP [22:58:47] ok. so, it is a one-time compile. [22:59:04] there's an experimental php 7 jit [22:59:06] https://www.reddit.com/r/PHP/comments/2xe8t4/experimental_php7_jit_is_faster_than_c_in/ [22:59:25] yeah there are some experiments [22:59:25] php 8 will ship with JIT though https://react-etc.net/entry/php-8-to-ship-with-a-jit-compiler [22:59:40] i am looking at https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/Optimizer .. [23:01:56] SMalyshev: Is that the plan for v8? [23:02:50] Krinkle: at best RA might be able to match PHP 7, it wouldn't be twice as fast or anything like that [23:03:08] it's not about file mtimes, it's about statically binding things like object member offsets [23:03:10] I don't really know... I know Dmitry was working on it but hadn't talked to him for a while, so not sure about the status and release plans [23:03:17] SMalyshev, TimStarling do either of you know if there is info about what opts zend implements .. i already see sccp, dce, and escape analysis .. passes 1-5 look like peephole opts? [23:03:33] looks like it's still work and progress but not sure when it happens [23:03:52] I gather PHP 7 is the same old VM as PHP 5 [23:04:07] subbu: hmm I wrote some of that code but that was many years ago... I'm not sure there are any real docs except for the code :) [23:04:14] ok. [23:04:48] you know there was a project to port the PHP 5 VM to LLVM, I spent a whole lot of time getting it to compile after a 5 year lapse in maintenance, and I benchmarked it [23:04:51] there are flow optimizations, etc. but I'll need to look to remember which pass does what [23:05:10] it basically concatenated the opcode definitions from a file and then ran an optimisation pass on the resulting machine code [23:05:17] subbu: also, it has comments at the start of the file :) [23:05:19] it was slower than the original [23:06:08] primarily because of a minor detail in LLVM: it was using register-indirect long jumps, which rapidly exhausted the processor's branch prediction table size [23:06:56] but even if that was fixed, it wasn't going to have great performance, for that you need something cleverer than just concatenating opcode handlers [23:07:28] SMalyshev, yes, i am looking .. i am getting the compiler itch.. but, anyway, not sure if I'll really scratch it. but, i'll at least download the code and poke around. [23:07:36] I think just dumping opcodes would probably not work very well since there's a lot of call outs and high level functions... llvm won't have enough info about what's going on [23:08:27] subbu: yeah, the interesting parts are in ext/opcache/Optimizer, I probably can remember most of hat's going on so ping me if you can't make sense of it :) [23:08:28] so, code generation is native to this compiler, not through llvm? [23:08:43] subbu: it's not really a compiler, it's a VM [23:09:07] ah, ok. that is why i asked if it was aot or jit? [23:09:16] I mean it is a compiler, but not into machine codes but into VM codes, which are then executed by the engine [23:09:21] got it. [23:10:05] subbu: check this one out: https://nikic.github.io/2017/04/14/PHP-7-Virtual-machine.html is explains some of it [23:11:09] now jit would convert part of it into real machine code, which is much trickier... [23:12:29] TimStarling, ah, i missed that you said that it was php 5 -> llvm. [23:12:34] i thought php 7 [23:13:48] ty .. off now. [23:15:00] yeah, it was in July 2012, I found the source tree [23:15:31] https://pecl.php.net/package/llvm [23:16:24] http://svn.php.net/viewvc?view=revision&revision=326870 [23:17:02] so I did that enormous commit, and it was still slower, so I didn't bother to keep working on it [23:23:50] funny idea to use an assembler written in lua