[15:03:09] tgr: Looks like the propagate error issue has been live in Beta for long enough that I can't see the drop off in type:hhvm anymore. Did you confirm at the time that it had the desired effect? [15:03:42] Krinkle: no, unfortunetely [15:03:52] at a meeting, can try afterwards [15:03:56] k. [15:04:07] I suppose we could try on mwdebug, or maybe briefly revert/redo on beta [16:13:28] Krinkle: hey! i'd really like to get the MCR RFC on last call. do you think you can have a look before the meeting tomorrow? [17:20:15] anomie: If I can't construct a legitimate API call that hits the $mUser case in ApiUserrights, we should just remove the cache, shouldn't we? [17:20:23] (I mean, the $mUser member) [17:21:03] The question is, will a given ApiUserrights object ever have both getWebUITokenSalt() and execute() called on it, or one of them called more than once? [17:22:01] AryehGregor: Supply a token created using getWebUITokenSalt() instead of the standard salt, that's how. [17:22:37] Ah, hmm. [17:23:56] Then indeed that's how I should test it, by writing a test that the web UI token works. [17:24:42] anomie: How should I test something like QuerySiteinfo? Should I really test every single field returned? [17:27:04] AryehGregor: Ha! There's probably no need for that. [17:27:19] Then what should I test? Some random selection of fields? [17:27:49] Every field that comes up in a separate execution path so we can artificially get 100% coverage even though we don't actually test most of the lines? [17:28:10] Mark the whole file @codeCoverageIgnore? [17:29:19] We should at least check that each execution path gets run when the right options are passed. If you want to check that every setting in the path gets returned correctly feel free. [17:35:26] anomie https://gerrit-review.googlesource.com/c/gerrit/+/169050 is now merged :) [17:35:48] anomie: If we modify an immutable user, does that persist beyond the end of the test run? [17:36:42] AryehGregor: Until something resets the test DB anyway. [17:37:00] anomie: What resets the test DB? [17:38:14] AryehGregor: Something putting 'user' or related tables into $this->tablesUsed. [17:38:22] See MediaWikiTestCase [17:38:47] anomie: In other words, the changes won't survive the test run, so why does it matter? At worst, it will cause spurious later failures. [17:38:54] (same goes for the block) [17:39:12] "spurious later failures" are still annoying. [17:39:51] Okay, understood. [17:40:33] Getting 1000 tests failed due to just one of them is discouraging and makes it hard to know where to start fixing. [17:41:18] I guess I'm just used to it from Mozilla tests, where I learned to just look at the first failure before paying attention to later ones. [17:41:31] It's certainly neater if it doesn't cause later failures. [17:45:50] "must be an instance of LinkTarget, Title given" [17:45:53] * Krinkle scratches head [17:47:42] anomie: For ApiBase, I wasn't planning on doing the lots more work right now, just noting that test coverage shouldn't be considered good enough yet even though it's reported as a high percentage. [17:48:08] (I think I wrote that one before I started making sure that I actually tested the code properly instead of just aiming for high coverage.) [18:19:01] Krinkle: re $wgPropagateErrors, is there something specific you'd want to test? [18:19:19] if it's just the dropoff, i'd say just deploy it in production and check [18:19:30] tgr: Well, just the basic that a particular source of errors goes into both 'beforre' and goes into one only 'after'. [18:20:01] Krinkle: that error could be caused by a missing "use" clause. [18:20:19] DanielK_WMDE_: https://gerrit.wikimedia.org/r/#/c/425323/ - global scope. [18:20:27] maybe deploy it to mediawikiwiki first? [18:20:38] I can actually reproduce it from eval.php [18:20:48] that new TitleValue() !== instanceof LinkTarget [18:20:53] Title::newFromText* [18:20:54] I mean [18:21:02] Still no clue why [18:21:12] because it's MediaWiki\Linker\LinkTarget [18:23:43] What value do namespaces really add again in practice? :/ [18:23:55] Especially if PHP doesn't helpfully suggest the right namespace. [18:24:00] (as, e.g., clang does for C++) [18:24:25] If anything, I'd think it might make sense to have all MediaWiki stuff in one big namespace and declare that we're using that namespace at the top of every file. [18:24:30] AryehGregor: PHPStorm does. [18:24:41] I don't think there's any big need to avoid naming collisions in our own code. [18:24:51] the value they add is avoiding name clashes. [18:25:16] there is, if we want to modularize our code, and make it re-usable. [18:25:22] there also is this need between extensions. [18:25:45] So we could have all our code in one big namespace, and let extensions put themselves in a different namespace if they don't want to collide with core. [18:25:51] also, with PSR4, namespaces mirror the directory structure [18:26:04] yea, let'S also put all our files into one directory [18:26:39] There isn't any "ls" for namespaces that I know of. [18:26:39] i mean, it's convenient, everything is in the same place. no need to search around. [18:26:49] it'S called an IDE :) [18:27:07] Hmm, maybe our difference here is that you use an IDE and I use vim. [18:27:39] yes, i have found that to be true a lot. tooling dictates coding style. [18:27:58] If you're using some sort of navigational tool that lists all the classes organized by namespaces, it seems handy to have them in hierarchical namespaces. [18:28:10] If you're not, it's only annoying. [18:28:16] people who use vim hate it when there is a lot of small clases. because they are a pain to manage without an IDE. [18:28:27] so using plain editors prevents fine gained modeling. [18:28:42] DanielK_WMDE_: Oh, LinkTarget is namespaced. [18:28:42] I don't mind small classes. Maybe it depends on one's workflow. [18:28:48] But Title, TitleValue are not. [18:28:49] OK [18:29:19] Another disadvantage of namespaces is when you start with un-namespaced code and then add namespaces to only parts of it. This is exacerbated if there's no clear policy on what namespace anything should be in. [18:29:47] And also, our directory structure is unpredictable too. [18:29:52] Aha, but... we have an RFC that will fix it all :P [18:30:06] I actually remember when all the source files were in one big directory. I didn't mind. [18:30:16] Is that the title? "RFC: Fix it all" :D [18:30:20] It would probably be a bit unmanageable by now, though. [18:30:43] https://phabricator.wikimedia.org/T166010 [18:31:30] FWIW, Mozilla's policy is that everything goes in a "mozilla" namespace and no sub-namespaces should be created (a few are grandfathered in). [18:32:00] On the other hand, I don't know how many Mozilla hackers use IDEs with cool features like DanielK_WMDE_'s, because I don't know if they would actually work on two million LOC. [18:32:02] AryehGregor: I think you're uniquely positioned to both know generally what each of these things does and is for, but also not too close to recent developments, so that you actually get value of grouping and organisation, whilst also being potentially genuinely confused by mis-grouping (whereas others might not get confused due to knowing it too well). [18:32:07] Or whatever Mozilla is. [18:32:11] That is, please comment on the RFC :) [18:32:33] DanielK_WMDE_: Thanks, I don't know how long it would've taken me to notice it was namespaced. [18:33:05] Krinkle: I've made the same mistake multiple times in about 2.5 weeks of working on the Brave New World of namespaced MediaWiki. [18:42:57] Krinkle: It doesn't look like an RFC anymore, it looks like a fait accompli by now. [19:56:13] AryehGregor: I think the main convenience of namespacing is PSR-4 autoloading (where ns+class name matches directory/file naming) so we don't maintain class maps anymore, and consistency with the rest of the PHP world that seems to have adopted it [20:26:06] The PHP world also adopted composer [20:26:11] Wait, did I say that aloud? ;-) [20:27:20] no_justification: still better than npm [20:27:33] Not having any software at all is better than npm [20:27:53] :-P [20:31:50] NPM is fine. Its packages, however... [20:33:18] https://www.npmjs.com/package/is-even [20:34:34] I like how it depends on is-odd [20:34:43] which depends on is-number [20:34:50] I was about to write the same :D [20:34:51] >_> [20:40:01] it's also wrong [20:40:24] so in addition to unnecessary dependency hell, it gives wrong answers [20:40:25] gg [20:41:14] (it'll happily tell you that -3 is even) [20:44:55] oh nvm, I thought js was one's complement in the vm for some reason [20:51:18] ol' good PECL made installing packages such hell that you would think twice and bundle lots of functionality in big hearty packages without a mountain of dependencies [21:18:36] Oh what's the dumb one I saw the other day? [21:18:41] Like, is-thirteen? [21:18:45] Seriously? [21:18:48] Fuck off, whoever you are. [21:22:02] There's also /noop[2-6]?/ [23:26:51] https://github.com/sindresorhus/noop3/issues [23:26:54] Nice art [23:34:57] ZALGO HE COMES