[00:46:43] <Krinkle>	 ori: When you search in xenon for things "being on CPU", does that include the full stack?
[00:47:06] <Krinkle>	 E.g. if foo() is called from bar() during the snapshot, does that count as "bar()" being on CPU, too?
[00:48:49] <Krinkle>	 ori: It would be interesting to capture what the most common offending code paths are to filter() during cache misses because I suspect this might be a wonky code path specifically, not a general thing.
[00:49:28] <Krinkle>	 For example, we have a known bug that since the user tokens were changed to be time-bound (instead of just session bound) for security reasons, the embedded user.tokens module is being minified each time and also cached for no reason.
[00:49:41] <Krinkle>	 Because it's never ever going to be hit. Becaue it's different on every request.
[00:58:37] <ori>	 Krinkle: we get the full stack
[00:58:57] <ori>	 take a look at /srv/xenon/logs on fluorine
[01:12:16] <Krinkle>	 ori: I'm writing a patch now that will allow user.tokens to by pass filter cache because it's useless
[01:12:19] <Krinkle>	 See also T84960
[01:21:58] <Krinkle>	 ori: Nice
[01:29:52] <Krinkle>	 ori: Arr, never mind. We're coming user.tokens with user.options, which is cacheable..
[01:30:08] <Krinkle>	 it's in the same faux request that is embedded in <script>
[01:30:21] <Krinkle>	 We'll need to separate these two soehow
[01:30:22] <Krinkle>	 somehow
[01:30:28] <Krinkle>	 which will create another <script>t ag
[01:32:26] <Krinkle>	 Oh well, I guess it works. We'll consolidate <script> tags later with some other patch.
[01:32:50] <Krinkle>	 ori: I'd be interesting to research whether this patch has a significant impact on reducing your observed filter() overhead https://gerrit.wikimedia.org/r/#/c/210845/
[01:33:15] <Krinkle>	 If my expectation is accurate, the majority of cache misses are just page views from logged-in users (every single page view incurrs it)
[01:33:27] <Krinkle>	 And this would kill that entirely
[01:42:53] <Krinkle>	 ori: 
[01:42:54] <Krinkle>	 $ ack-grep  -Q 'ResourceLoader::filter' 2015-05-13_0* | cut -d':' -f3-8 | sort | uniq -c | sort -r -n
[01:42:54] <Krinkle>	     167 /srv/mediawiki/w/index.php;MediaWiki::run;MediaWiki::main;OutputPage:
[01:42:55] <Krinkle>	      39 /srv/mediawiki/w/load.php;ResourceLoader::respond;ResourceLoader::makeModuleResponse;ResourceLoader:
[01:42:57] <Krinkle>	       7 /srv/mediawiki/w/api.php;ApiMain::execute;ApiMain::executeActionWithErrorHandling;ApiMain:
[01:43:12] <Krinkle>	 So the majority is coming from embedded modules.
[02:18:42] <ori>	 Krinkle|detached: good detective work
[02:37:56] <ori>	 TimStarling: (per #hhvm) this is why we didn't get symbols in perf: https://github.com/torvalds/linux/commit/578c03c86fadcc6fd7319ddf41dd4d1d88aab77a
[02:40:05] <TimStarling>	 I thought the JIT used a separate mmap, not the heap
[02:59:06] <ori>	 TimStarling: guess not. It's pretty damn cool to see MediaWiki functions in perf top, you should check it out. You can `sudo /home/ori/linux-4.0.3/tools/perf -p $(pidof -s hhvm)` on mw1041
[02:59:55] <ori>	 perf top -p .. that is
[03:11:22] <ori>	 HHVM is still wasting a lot of time JITting single-use regexes containing strip markers
[16:13:19] <MatmaRex>	 anomie: hey. i'm struggling to understand the purpose/design of HTMLAutoCompleteSelectField
[16:14:07] <anomie>	 MatmaRex: Purpose is to avoid having a <select> with 800+ options to dig through.
[16:14:27] <MatmaRex>	 anomie: okay, that was exactly what i wanted to ask, why it's not just a big <select>
[16:14:58] <MatmaRex>	 anomie: mark and I have been working on OOUI implementation of HTMLForm https://gerrit.wikimedia.org/r/#/c/205719/ and that one kind of didn't fit anything sensibly
[16:15:45] <MatmaRex>	 anomie: (also i totally forgot about you apisandbox thing last weekend :( but i will look at it *this* weekend, pinky-promise)
[16:16:01] <MatmaRex>	 (pinky-swear, rather. silly english)
[16:16:25] <anomie>	 I've had such a busy week I didn't even remember that was last weekend you said you'd look at that.
[16:18:46] <MatmaRex>	 anomie: so, we could probably implement that in the OOUI way the exact same way as it is now (select box + text input with autocomplete), but that's not very neat, i think
[16:19:17] <MatmaRex>	 anomie: we have a "combo box" widget, though, and i would try to use that. i'd link you to the OOUI demo to try it, but it is annoyingly down currently
[16:28:35] <anomie>	 MatmaRex: Looking at ComboBoxWidget on the demo page locally, it doesn't seem to filter the stuff in the dropdown as you type.
[16:31:20] <MatmaRex>	 hmm. yeah, it only selects an option if you type an exact value. so that probably won't work so well, actually
[16:32:24] <anomie>	 The more important thing is that typing "en." in the box should only show "en.wikipedia.org", "en.wiktionary.org", and so on in the dropdown. Then probably allowing arrows to select one, or click, or keep typing.
[16:32:56] <anomie>	 (well, not for the demo obviously, but for the places it's actually used that's what it's used for)
[16:36:48] <anomie>	 MatmaRex: If you need to see the existing implementation in action, you should be able to go to https://www.mediawiki.org/wiki/Special:OAuthConsumerRegistration/propose where it's used for "Applicable project".
[16:37:52] <anomie>	 Also https://test.wikipedia.org/wiki/Special:SecurePoll/create, if you have access to that one.
[16:38:01] <anomie>	 ("For wiki" field there)
[16:42:21] <MatmaRex>	 anomie: hmm, i think this would work better if we changed the <select> to a set of radio buttons, where one (for the 'other' option) would have the autocomplete field in the label area?
[16:43:45] <MatmaRex>	 (anomie: yeah, i've been looking at the usage in OAuth, mark is trying to make its forms use the OOUI version in https://gerrit.wikimedia.org/r/#/c/205720/)
[16:43:46] <anomie>	 MatmaRex: Maybe. These examples don't have many options in the <select>, but it could get big if there were (e.g. if someone dumped a lot of options into $wgSecurePollCreateWikiGroups)
[16:44:41] <MatmaRex>	 we can just say that someone shouldn't do that.
[16:45:04] <MatmaRex>	 :P
[16:45:14] * anomie doesn't like that suggestion much
[16:49:02] <MatmaRex>	 anomie: i'm going to dump what we said into a bug and ask nirzar or prateek to help us come up with something pretty, i think
[16:49:23] <anomie>	 MatmaRex: ok
[16:53:29] <csteipp>	 Did gerrit get upgraded?
[16:54:32] <legoktm>	 I don't think so?
[16:54:36] <csteipp>	 Oh, never mind. You can specify the display format in a link...
[16:54:51] <csteipp>	 TIL
[17:01:53] <legoktm>	 csteipp: re: composer, for the initial patch I think we'll need like 5-10 classes total, so we can probably copy them in in bd808 is ok with that...
[17:02:23] <legoktm>	 bd808: context is https://phabricator.wikimedia.org/T99086
[17:19:56] <csteipp>	 legoktm: That would be much better
[17:49:58] <legoktm>	 anomie: is the API part in https://gerrit.wikimedia.org/r/#/c/185583/9/includes/api/ApiParse.php,unified ok? is there a better way to do that?
[17:50:14] * anomie looks
[17:51:59] <Krinkle>	 ori: It's looking quite promising the replacing of meta data hashing with pure content hashing. I think for file and wiki modules we may want to stick with meta data hashing though since the disk I/O and external storage queries would be quite significant in quantity.
[17:52:51] <Krinkle>	 and besides for those methods, file system is quite reliable (aside from the fact that the timestamps reset due to fresh git clones, but we may be able to find a solution for that)
[17:53:18] <Krinkle>	 at least wiki revision numbers (page_latest) is a reliable way to determine changes.
[17:53:34] <Krinkle>	 We can make it opt-in and default to pure content hashing. That would make RL more stable by default.
[17:54:09] <anomie>	 legoktm: It's ugly that it's setting a poorly-targeted warning, and might confuse some clients into thinking they're broken if they treat warnings as errors. But the only other option at the moment is no warning at all, and the annoyance should be reduced because prop=modules is probably ("probably" == "wild guess") not used so much.
[17:54:57] <anomie>	 legoktm: Bottom line: Sure, go for it. We can always kill the warning if people complain too much.
[17:55:56] <legoktm>	 ok, sounds good :)
[18:39:20] <bd808>	 legoktm, csteipp: I'm not sure either way what the good option is for using composer classes in mw-core
[18:39:35] <bd808>	 it's a bit creepy honestly
[18:39:46] <legoktm>	 how?
[18:40:01] <legoktm>	 https://gerrit.wikimedia.org/r/#/c/210856/5/includes/registration/CoreVersionChecker.php,cm is where I want to use it
[18:40:16] <bd808>	 the mass of code that you get with the full composer package and having that on WMF prod
[18:40:29] <legoktm>	 right.
[18:40:51] <legoktm>	 so csteipp was suggesting that we just copy in the classes we need
[18:41:52] <bd808>	 Are you really just wanting version string parsing and simple range overlap validation?
[18:42:10] <legoktm>	 for now yeah
[18:42:30] <legoktm>	 whatever is in https://getcomposer.org/doc/01-basic-usage.md#package-versions
[18:43:06] <bd808>	 I wonder if we could get them to split that out upstream?
[18:43:28] <bd808>	 as a generally useful lib
[18:44:06] <bd808>	 composer as a package will pull in a ton of stuff...
[18:44:33] <legoktm>	 I'll talk to seld about that, when I asked him a few days ago we talked about the entire dependencysolver, not the linkconstraint stuff
[18:44:34] <bd808>	 symfony classes, jsonlint, json-schema
[18:45:27] <bd808>	 is this expected to be used at runtime in a web request? I'm a bit hazy on that
[18:46:21] <legoktm>	 yes
[18:47:05] <bd808>	 and that's because we will validate the extensions at runtime (every page load)
[18:47:15] <legoktm>	 when extension.json is read for the first time, it does the compatability checking, then caches it. Future requests will read from the cache and skip the version checking
[18:47:25] <bd808>	 probably with some cache magic or something?
[18:47:39] <legoktm>	 https://gerrit.wikimedia.org/r/#/c/210856/5/includes/registration/ExtensionRegistry.php,unified
[18:47:47] <legoktm>	 the readFromQueue() code path is only called on cache misses
[18:48:32] <bd808>	 *nod*
[18:49:29] <Krenair>	 speaking of extension registry, did anyone ever figure out what's up with nostalgia?
[18:49:32] <bd808>	 I guess my naive preference would go something like: upstream lib > hacked lib we make > composer in vendor
[18:50:28] <bd808>	 if they won't/can't split the lib out upstream then I kind of think we would make a new wheel that looks a lot like the wheel they made too
[18:50:35] <legoktm>	 Krenair: https://gerrit.wikimedia.org/r/#/c/210723/
[18:50:46] <bd808>	 which we should make as a lib outside of mw-core
[18:51:03] <Krenair>	 did you try that in prod with mw1017?
[18:57:50] <csteipp>	 legoktm: This runs on every page request? I thought it was CLI to start?
[19:06:02] <legoktm>	 csteipp: not every, just cache misses. We're basically re-implementing wfUseMW() in extension.json. the CLI extension management thing is going to come later.
[19:10:06] <legoktm>	 Krenair: is there an easy way to deploy it there?
[19:10:45] <Krenair>	 sure, apply the change on tin as a live hack (like you would a security patch, format-patch locally and am on tin), and sync-common on mw1017
[19:12:51] <Krenair>	 when you're done either remove the patch from tin or sync it out fully
[19:13:09] <legoktm>	 how do you remove the patch?
[19:14:45] <Krenair>	 I think you can checkout head^
[19:15:21] <Krenair>	 or... would it be reset
[19:15:37] <Krenair>	 check locally first, legoktm :P
[19:16:14] <legoktm>	 it's checkout
[19:16:25] <legoktm>	 reset gets rid of the commit but leaves unstaged changes
[19:18:59] <Krenair>	 IIRC that depends on what parameters you give it?
[19:19:23] <bd808>	 git rebase --interactive works well for selectively dropping patches too
[19:21:05] <legoktm>	 Krenair: https://nostalgia.wikipedia.org/wiki/HomePage
[19:22:16] <Krenair>	 it works
[19:22:21] <Krenair>	 (when I turn on debug headers)
[21:02:17] <legoktm>	 bd808: someone ported node's semver library to PHP: https://github.com/vierbergenlars/php-semver/tree/3.0.1
[21:02:59] <bd808>	 ooooh
[21:03:08] <bd808>	 does that give you all the bits you need?
[21:04:52] <legoktm>	 I think so
[21:05:49] <legoktm>	 code quality doesn't look super great though...
[21:06:25] <bd808>	 pull requests can fix that ;)
[21:07:04] <legoktm>	 https://github.com/vierbergenlars/php-semver/blob/3.0.1/src/vierbergenlars/SemVer/internal.php :/
[21:07:46] <bd808>	 o_0
[21:08:13] <bd808>	 LibJs is .. interesting too
[21:12:49] <legoktm>	 in composer we're using two classes, VersionConstraint (exends LinkConstraintInterface, easy to pull out) and VersionParser, which has ~2 functions which interact with "Package" and would need to be moved somewhere else
[21:34:36] <hashar>	 legoktm: I gave a very lame review to your version constraint patch :D
[21:34:44] <hashar>	 sorry if it is not that helpful :/
[21:34:49] <legoktm>	 hashar: it was, thank you :)
[21:35:14] <hashar>	 legoktm: overall I am confused as to why we need a "support" field
[21:35:36] <hashar>	 seems to me an extension would have a require: { "mediawiki/core": ">1.25" }   and that is sufficient
[21:35:52] <hashar>	 but I haven't really looked at all the composer stuff you guys worked on :]
[21:35:56] <ori>	 * legoktm commits seppuku
[21:36:08] <hashar>	 so ignore me!
[21:36:11] <hashar>	 :D
[21:36:24] <legoktm>	 hashar: that's what people were suggesting on IRC as well, I was jsut looking to get a working thing in gerrit
[21:36:44] <hashar>	 legoktm: I guess you will get more info via the hackathon
[21:39:26] <hashar>	 off
[21:39:34] <hashar>	 see you in Lyon!
[21:39:52] <hashar>	 and bring your coats. Nights are still cold in France
[21:57:58] <ori>	 bd808, legoktm: could either of you take a look at <https://gerrit.wikimedia.org/r/#/c/211048/>?
[22:01:41] <bd808>	 ori: the change looks good. Do you have a plan to fix the existing metrics it will change on the graphite side?
[22:01:56] <bd808>	 or is this new enough that won't be a big problem?
[22:02:11] <ori>	 bd808: yeah, we haven't enabled this output for prod before
[22:02:22] <ori>	 thanks to both of you
[22:02:28] <ori>	 heh, those two statements were not related
[22:02:55] <bd808>	 that legoktm is always faster with the merge finger than I am ;)
[22:03:16] <legoktm>	 :)
[22:03:35] <legoktm>	 bd808: are you using the new change screen? it has a giant CR +2 button?
[22:03:41] <legoktm>	 that last ? was a .
[22:04:03] <bd808>	 Nope. I still use the "old" ui
[22:04:24] <bd808>	 I don't remember what problem I hit with the new version
[22:04:38] <bd808>	 something I didn't like and ran away from
[22:05:11] <legoktm>	 http://i.imgur.com/XjheqQR.png giant blue button for merging :P
[23:14:04] <ori>	 greg-g: whoa, https://phabricator.wikimedia.org/T98142 is wtf-ish
[23:14:13] <ori>	 is Wikigrok no longer being actively developed?
[23:14:45] <greg-g>	 ori: that's what it appears, looking for clarification/statements