[01:08:10] Fatal error: assert() is not supported: assert with strings argument in RepoAuthoritative mode in /srv/mw/core/includes/parser/Preprocessor_Hash.php on line 478 [02:16:10] TimStarling: according to https://github.com/facebook/hhvm/issues/6764 you may be able to get past that with assertions.active=0 [02:17:45] assert with strings is an eval() with a check so RepoAuthoritative won't allow it [02:22:13] thanks, but I'll probably just fix it [02:22:29] assertions should probably be active in production [02:42:05] in core and deployed extensions, it's only that assertion plus 3 in wikibase and 1 in SMW [17:17:14] ostriches, legoktm: Any idea what Jenkins's problem is with https://gerrit.wikimedia.org/r/304861 ? [17:20:51] I think ostriches said that the rel1_23 tests were all messed up the other day when he was doing backports [17:21:25] Different test and for unrelated reasons [17:21:28] So nope, no idea [17:27:22] anomie: wrote something about those tests in -releng but not sure that anyone other than hashar knows what that castor stuff is and how to fix [20:15:33] TimStarling: I think it came up before and the solution we settled on was to call assert() on expressions rather than their string representations [20:16:25] it makes the traceback slightly less useful (though not by much, since you still get the file / line), but it's faster and compatible with HHVM [22:02:42] legoktm: am I missing something obvious about extension registration loading order in T143055? [22:02:42] T143055: Echo notificationCategories usergroups parameter disappears - https://phabricator.wikimedia.org/T143055 [22:15:16] anomie: the tests are failing because the npm/rake stuff weren't set up for the REL1_23 branch. we don't really maintain the old branches for CA very well... [22:16:41] legoktm: s/for CA// [22:16:43] {{fixed}} [22:17:38] tgr: not off the top of my head... var_dump $wgHooks to make sure that the hook is being added properly? [22:38:26] anomie: should we also get rid of stuff like CssContent::preSaveTransform() which calls $wgParser->preSaveTransform()? [23:26:49] ori: I did it already, there are three changes in gerrit [23:27:09] anyone here who was involved in mustache/TemplateParser? [23:28:18] looks like legoktm just reviewed them [23:28:41] kaldari is in another channel [23:29:02] TimStarling: it was Krinkle and kaldari mostly I think [23:29:26] I don't think I really need kaldari specifically [23:29:57] basically, I am implementing RepoAuth support, I have changes in gerrit [23:30:19] initially this would just be for benchmarks and experimentation, but it still needs to all work in that mode to use it for that [23:30:31] oh, and templateparser uses eval? [23:30:35] yes [23:31:02] I wrote a maintenance script already which invokes the HHVM compiler [23:31:28] so it's not too hard to make it also write the generated PHP for templates to disk [23:31:31] what prompted you to work on that, out of curiosity? [23:32:14] well, I was working on microoptimisations for Balancer, and also wanted to know what style I should use for Remex (the other HTML parser I'm working on) [23:32:27] I was interested in object access times, and whether object access should generally be avoided [23:32:44] so I looked at the disassembly, and it was terribly inefficient [23:33:06] https://phabricator.wikimedia.org/T379#1032865 [23:33:17] (for compiling templates during deploy) [23:33:22] so I compiled a little object access script with RepoAuth, and it was something like 2x faster [23:33:43] so I wondered how much faster it is for balancer in general [23:33:52] I know the answer now, it is 25% for typical input [23:35:14] thanks legoktm [23:36:34] object access in non-RA mode works by calling a C++ helper function which actually looks up the string name in a hashtable in the class [23:37:06] even with a private member variable in a final class [23:37:22] there are integer slots but it doesn't even try to determine them at compile time in non-RA mode [23:37:55] the hashtable is name -> slot index [23:40:01] I wonder why it doesn't even try in non-RA mode, cases like private member variable in a final class are easy to reason about [23:40:21] probably because FB uses RA in production so they don't care that much [23:40:59] yeah, non-RA performance has to be adequate for local development and that's it [23:41:16] when I last looked at RepoAuth I concluded that it was unfeasible for us to use in production, because the changes to our deployment tooling and processes that it would require exceed our current capacity [23:41:25] so from that bug, it looks like there was no argument made against compilation, except for implementation difficulty [23:41:32] precompilation, I mean [23:41:43] I documented some of this in https://github.com/facebook/hhvm/issues/6878 [23:42:00] APC was chosen just because it was easy [23:44:55] HHVM relies pretty heavily on global/class-static state [23:45:47] I don't know if I agree with you on "How to make RepoAuth easier" [23:47:10] I think one way to do it would be to make multiversion into an HHVM instance manager and proxy [23:47:36] you say "they are quite rare" but these things don't write themselves [23:48:40] i.e. to basically follow FB as closely as possible [23:49:05] as I understand it, they start up new HHVM processes on each code deploy [23:50:49] yes, they use socket takeover [23:51:19] the old process passes its accept socket to the new process [23:51:51] is there an API for that in HHVM? [23:52:58] afaik, no [23:53:09] https://github.com/facebook/hhvm/blob/master/hphp/runtime/server/takeover-agent.cpp [23:53:59] anyway, that's not the hardest question IMHO [23:54:31] the thing that worries me is configuration, specifically being able to change the configuration of a running HHVM instance [23:55:13] we could put configuration in a database table and read from it at run time ;) [23:55:33] with version control? [23:55:42] could be in a wiki I guess ;) [23:55:56] also there is a lot of logic in our conf files [23:56:11] yes, we need to have the ability to set $wgSomeFeatureFlag = false and push it out quickly [23:56:14] JsonConfig? [23:56:21] * Reedy hides [23:56:29] but yeah, something like JsonConfig. [23:56:49] I think we're pretty close to config db though now with extension registration mostly settled down. I have an old WIP I need to revive [23:56:49] yeah, I had the same idea actually, and prototyped it in my LocalSettings.php [23:57:01] $settings = json_decode( $settingsJson, true ); [23:57:01] foreach ( $settings as $key => $value ) { [23:57:01] $GLOBALS[$key] = $value; [23:57:01] } [23:57:06] that sort of thing [23:58:00] better to integrate it with SiteConfiguration, for production at least [23:58:02] there is an obvious intermediate step and that is to stick to PHP $vars but to remove all logic [23:58:10] and that seems hopelessly out of reach [23:58:51] someone is going to guess my next idea soon [23:59:00] I'd better say it quick [23:59:24] ... [23:59:50] LuaConfig! a LuaSandbox with a library that allows all sorts of things to be done to the host PHP process, like setting globals