[00:00:08] and I (personally) still don't believe that composer is the right solution for extension management [00:00:44] it's "an" solution, but "right" is an interesting question [00:01:23] omg coding style wars [00:02:10] a sad but common occurance [00:02:22] https://gerrit.wikimedia.org/r/#/c/177747/1/includes/EditPage.php,unified [00:02:33] someone did a search and replace in the codebase but didn't update my brain [00:02:42] what to do? [00:02:54] reboot! [00:04:13] My lame approach to MW's php style is try to make it look like the rest of the class I'm changing and then just do the things reviewers whine about [00:04:46] it is not just me is it? it is seriously weird to style your multi-line if statements like this: http://paste.tstarling.com/p/MZlGxV.html [00:04:51] bd808: I started working on a script that takes multiple composer.json files as arguments, and spits out one unified composer.json file in $IP/vendor/ [00:04:54] right? [00:05:21] TimStarling: it's not just your brain that winces at it [00:06:31] but Timo trained me to do mostly that via code review. I think I still sneak the conjunction operator on the end of the line instead of the beginning [00:06:46] But our whitespace rules make my head hurt too [00:07:10] I've always thought a single { on it's own line looked weird, and ) { is a little less weird, probably because I've been trained like that :P [00:07:17] TimStarling: I always pair ") {" [00:07:20] trained by who? [00:07:34] TimStarling: I think it goes together with something else. Which is closing parenthesis of a function call [00:07:42] glibc uses a half indent for the conditional and then a brace on its own line [00:07:46] code reviewers, I don't remember any specific people [00:07:59] the kernel uses a half indent for the conditional and then a brace on the same line [00:08:28] TimStarling: Do you do $x->thing( 'x', array( array(\n\t.... ) ); or $x->thing( 'x', array( array( \n \t ....\n) ); [00:09:00] I think in our code it's conventional to close at the same indention level as the opening. That way the inner value is clear (or whatever excuse, it's about consistency, making it rational doesn't usually work either way). [00:09:21] So with that, I think it makes sense to keep the ) back under 'if ('. [00:09:21] well, I used to do the second one, but I agreed to do the first one because it is MW site style [00:09:41] but I never agreed to treat closing parentheses of if statements by analogy, that is just weird [00:09:55] TimStarling: It actually surprised me earlier this week to see your comment saying ) { is ... unreadable (you used a different word, I forget) [00:10:14] idiosyncratic [00:10:52] which strictly means the habits of a single person which are unlike those of any others [00:12:16] btw glibc puts all its braces on their own lines [00:12:48] so both kernel and glibc are similar in not making any differentiation for multi-line conditionals [00:13:28] randomly switching between the two could be called weird too [00:13:34] Yeah, but don't we use the brace style where the brace is at the end of the previous line? [00:13:42] curly brace that is [00:14:16] for single-line conditionals yes [00:14:22] like the kernel [00:14:42] but for multi-line conditionals we use ) { on its own line, which is like nothing that I know of [00:14:47] TimStarling: https://gist.github.com/Krinkle/993ad860b7f9f5c0cc1d [00:15:08] I think it keeps indentation more untuitive by going back to the left with ) { so that the next code indents from there [00:15:20] Just like function calls and arrays nesting going back to their starting level before the next statement [00:15:54] yeah, but intuition and consistency are often opposed [00:15:58] everyone has their own intuition [00:16:40] https://gist.github.com/Krinkle/993ad860b7f9f5c0cc1d?r2 [00:16:55] I don't really like half indents because I liked the idea of user-customisable tab sizes [00:17:04] I agree [00:18:41] line 2 & 10 looks like the kernel when you have your tab settings wrong [00:19:09] 32 & 42 look like glibc with half-indents rounded off, which was basically what I was going for [00:19:31] there are no (intentional) half-idents. That's the github editor and highlighter beign weird. [00:19:34] They're all tabs [00:19:51] Apparently PSR-2 agrees about the paired paren and brace (at least for function declarations) -- "When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them." [00:20:10] Not that PSR-2 is a paragon of beautiful style [00:20:21] it's a mishmash designed by committee [00:20:27] grrr [00:20:42] That may be where it crept in from though [00:20:42] begruding thanks for facts bd808 [00:20:55] TimStarling: :/ yeah [00:21:13] TimStarling: mhttps://gist.github.com/Krinkle/993ad860b7f9f5c0cc1d?r3 [00:21:14] https://gist.github.com/Krinkle/993ad860b7f9f5c0cc1d [00:21:22] 8 space tabs for you [00:22:10] Krinkle: yeah, I know you have no half-indents, I'm saying it's like glibc except without half-indents [00:22:16] ok [00:22:39] The interesting thing about the inclusion of that MUST in PSR-2 is that I don't see it as one of the survey questions the standard was supposedly created from via consensus [00:23:31] most code conventions don't say not to use Yoda style conditionals. It's presumed that the default is to not do weird shit like that. I think whoever wrote PSR-2 made that same assumption about placement of ) { [00:23:54] Yoda style? [00:23:54] * bd808 likes yoda conditiuonals [00:23:58] I tend to agree with this one though. I find ) and { separate rather weird. Especially in context of MediaWiki where we don't place braces on their own line. [00:24:05] TimStarling: if ( 'value' === $bar ) {} [00:24:25] That habit comes from java coding [00:24:28] well, there are defensible reasons for doing that [00:24:37] and string tests in java specfically [00:24:40] I think it probably predates java [00:25:02] It also helps prevent assignment when you meant to test equality and missed an = [00:25:03] TimStarling: One common reason in javascript environments is that with Yoda conditionals you can't accidentally assign instead of compare. [00:25:09] right [00:25:13] Though that's better accomplished with a linter / coding style rule. [00:25:23] phpcs, jscs and jshint catch these [00:25:42] And if you use a proper editor with plugins for these, you get it as you type. No need to run any scripts. [00:25:42] I think it probably originates in C or some other earlier language where accidental assignment is a concern [00:25:45] * Krinkle doens't like running phpcs or jshint [00:26:16] * bd808 doesn't like his editor to do much more than syntax highlight [00:27:13] it's noticable cut down the time I spent writing code. Especially when contributing to other projects, it's great seeing their structure and style rules right then and there. Autoamtically adapting to the dotfiles in the repo I'm in. [00:27:30] As opposed to seeing it when you run 'make/grunt/composer test' or a day later in review. [00:27:47] But whatever floats your boat :) [00:28:01] True enough [00:28:16] bd808: I can see how it might be distracting. [00:29:22] I got my start in the cave man days of TurboPascal. [00:29:59] or the TSR-80 in the way way back. That was real programming. :)) [00:30:31] * TimStarling reads https://en.wikipedia.org/wiki/Relational_operator#Equality [00:30:49] apparently BCPL had := for assignment [00:30:58] which seems like a sensible convention [00:31:26] so it was really C that screwed it up for everyone by using = and == [00:31:37] golang has that for variable declaration with initializer [00:31:42] it's nice because it lets you omit the type [00:32:18] foo := 4 [00:37:58] ori: Type coercion? [00:38:28] inference, not coercion [00:43:56] MaxSem: https://en.wikipedia.org/wiki/MediaWiki:Gadget-popups.js is still broken, blargh. [00:44:10] LOLWTF [00:44:42] ori, and no traces in logs? [00:45:32] there was the math fatal i thought i had fixed yesterday, but it looks like i didn't cherry pick it to wmf10 [00:47:40] MaxSem: heh, yeah, it was the math fatal. it looks like i forgot the submodule update for wmf10 [00:48:29] eurgh, and why did it crash on a page without math? [00:48:50] that's a good question [00:52:23] fixed! [00:52:30] thanks ori [00:52:45] * - Better support for [00:52:54] maybe it was getting parsed? [00:54:45] if I run it through Special:ExpandTemplates, it displays an error: "Failed to parse (unknown error): * - Full support for ..." [00:54:57] and we parse them for link tables [01:21:40] TimStarling: would you like me to merge the 'move idiosyncratic .gdbinit' patch from a while ago? It has been open for a while. I have no problem with it. [01:25:07] I'm in a meeting at the moment [01:26:05] OK [01:26:12] meet on [01:43:44] 3MediaWiki-Core-Team: Performance tweaks based on profiler - https://phabricator.wikimedia.org/T76677#835719 (10aaron) [01:47:08] 3MediaWiki-Core-Team, MediaWiki-API: Query error in ApiOpenSearch::search - https://phabricator.wikimedia.org/T78074#835721 (10Legoktm) 5Open>3Resolved [02:36:53] ori: I guess you were putting things in /etc/gdb/gdbinit because you often want to run gdb as root? [02:38:31] I would be fine with you adding user-defined commands to /etc/gdb/gdbinit [02:38:41] you could have an ori-setup command or something [02:38:47] TimStarling: no, because I wanted to make it a nice debugging environment for everybody. For example, for a while, the package's debug symbols referred to a source tree in /home/joe/..., so the path substitution seemed unobjectionable. [02:39:42] yeah, but it is applied regardless of what binary you are editing, and it seems very strange to get source from /home/joe anyway [02:40:16] the HHVM-specific stuff could be in an HHVM setup command [02:41:16] HHVM pretty printing is poorly maintained and usually harmful, whenever I had it loaded, I just ended up adding /r to most of my print statements [02:41:25] after I finished patching it of course [02:41:41] it was ridiculously badly broken before my patches [02:42:13] well, 'set substitute-path /home/joe/HHVM/hhvm /usr/local/src/hhvm' doesn't load from /home/joe, it loads from /usr/local/src, and it doesn't do anything unless it actually encounters that path; 'add-auto-load-safe-path /usr/lib/x86_64-linux-gnu' is similar; the libstdc++-dbg package puts pretty-printers there that gdb tried to autoload but since the path was not declared safe you get a warning every time [02:42:30] the hhvm pretty-printing stuff could just be removed [02:43:40] let's just remove it; _joe_ is building things in /usr/src nowadays, and the followup patch i submitted just ensures the hhvm source tree is actually there, removing the need for any path substitution [02:44:21] the rest is my opinionated take on what makes for a pleasant gdb environment, but if your preferences differ, then it's just tyrannical on my part [02:44:45] I can't count the number of times I've been glad of paging [02:45:18] I rely on scrollback pretty heavily, and it's very easy to accidentally run a command that sends hundreds of thousands of lines to the terminal [02:45:37] I often end commands before they have finished all their output, like bt [02:45:45] makes sense. so yeah, let's kill it [02:45:50] I just view the number of pages necessary to understand what's going on [02:46:01] no offense taken or anything [02:46:17] i have to run at the moment so i can't merge it but i can later [02:46:55] no, don't merge it, we'll do something different [04:19:25] <^d> Hmm, none of my elastic buddies around :| [07:16:42] <_joe_> ori: around? [07:17:09] <_joe_> if so, I'd like to re-convert one jobrunner to HHVM this week [07:17:25] yeah, let's do it [07:17:43] <_joe_> (your wake-on-irc protocol is amaizing :P) [07:18:56] <_joe_> ori: by any chance, do you know who I could harass about the imagescalers? it seems we have quite a few things that are not well documented - like which packages we rebuild, why, with which patches... [07:19:30] <_joe_> I'm already harassing paravoid of course, but someone on the dev side would be nice [07:20:13] tim, maybe aaron or chad [07:20:26] i'm probably the person that knows least about it in mediawiki-core, in fact [07:20:54] <_joe_> eheh ok [07:21:15] in your TZ, maybe gilles? [07:21:39] <_joe_> one thing we should do is audit our prod code for places where we handle Content-length naively [07:22:16] <_joe_> apache would autocorrect some lame results from mod_php, and it's not doing it for mod_proxy_fastcgi [07:22:25] meh, if there are issues we haven't discovered they're probably minor or they'd have surfaced already [07:25:15] <_joe_> yeah, one surfaced yesterday with the PediaPress code [07:25:27] mw1020.eqiad.wmnet: [07:25:28] tmpfs 1.2G 1.2G 72M 95% /run [07:25:33] <_joe_> mmmh [07:25:43] <_joe_> ok time to do a clean sweep there [07:25:45] there are a couple of others too [07:25:46] mw1018 [07:25:53] <_joe_> of course the older ones [07:27:06] <_joe_> ori: I'll set up a nagios check today. and do some cleaning [07:28:05] sorted by % full: https://dpaste.de/gtQn/raw [07:28:10] this sucks :( [07:28:22] we should come up with a way to automate this that doesn't require depooling the server [07:29:05] <_joe_> ori: or make depooling automatable [07:29:35] yeah, we should do that regardless, but it's annoying to have to do it for _that_ [07:30:04] but it's worth poking at the file with a sqlite client [07:30:18] maybe pruning isn't hard and perhaps it could be done from a separate process [07:30:36] <_joe_> yeah [07:30:36] does sqlite allow concurrent writes? [07:30:47] <_joe_> mh yes I think so [07:31:02] apparently yes: "SQLite handles concurrency well, but it isn't the best from a performance angle. " [07:31:40] <_joe_> yes, I was thinking of the different processes on the same db case [07:31:41] but that's ok, because we're talking about a periodic, short-lived pruning job [07:31:46] <_joe_> I'm not sure about that [07:31:58] <_joe_> yes [07:33:32] wow, mw1019 got reimaged 112 days ago?! [07:33:35] time flies [07:33:45] <_joe_> yeah [07:33:46] if it's only filling up now, that's not too bad [07:36:02] you know, this would really be enough: [07:38:05] <_joe_> ori: https://commons.wikimedia.org/wiki/File:DeEenzamenPost.gif is this served from swift? [07:38:47] Dec 10 07:38:25 mw1019 hhvm: #012Fatal error: Call to undefined method DOMText::hasAttribute() in /srv/mediawiki/php-1.25wmf11/extensions/CommonsMetadata/TemplateParser.php on line 333 [07:40:02] <_joe_> curl -I -H 'Host: commons.wikimedia.org' http://mw1032.eqiad.wmnet/wiki/File:DeEenzamenPost.gif gives 500 in fact [07:40:16] yeah, that's what i just did [07:40:20] except i used furl ;) [07:40:23] <_joe_> ehehe [07:40:43] i'll look at CommonsMetadata, sec [07:40:45] <_joe_> DOMText::hasAttribute() feels wrong [07:40:58] <_joe_> DOMText shouldm [07:41:05] <_joe_> *n't [07:41:27] <_joe_> or maybe I forgot the joys of the DOM [07:41:33] my version has... [07:41:34] if ( $nukeLink && $nukeLink->hasAttribute( 'href' ) ) { [07:43:03] yeah, it's https://gerrit.wikimedia.org/r/#/c/176510/ [07:43:47] so presumably nukeLink isn't an object [07:43:47] should be hasAttributes, no? [07:43:50] <^d> Yes. [07:43:57] <^d> I was about to say, left off a character. [07:44:14] http://php.net/manual/en/domelement.hasattribute.php [07:44:20] DOMElement::hasAttribute — Checks to see if attribute exists [07:44:23] WFM [07:44:36] <^d> Also, it has no parameters. [07:45:04] <^d> DOMText doesn't inherit from DOMElement. [07:45:43] <_joe_> http://php.net/manual/en/class.domtext.php [07:46:05] <_joe_> whoo I do still remember DOMshit [07:46:21] oh, so: [07:46:24] it should be: [07:46:28] if ( $nukeLink && $nukeNode->hasAttribute( 'href' ) ) { [07:46:36] the second nukeLink should be nukeNode, right? [07:47:23] no [07:47:45] <^d> I'm not sure. [07:48:00] <^d> foreach ( $domNavigator->findElementsWithClass( '*', 'nuke' ) as $nukeNode ) { [07:48:00] <^d> $nukeLink = $nukeNode->firstChild; [07:48:00] <^d> if ( $nukeLink && $nukeLink->hasAttribute( 'href' ) ) { [07:48:02] <^d> $urlBits = wfParseUrl( $nukeLink->getAttribute( 'href' ) ); [07:48:38] 3MediaWiki-Core-Team: LoadBalancer slave lag tweaks - https://phabricator.wikimedia.org/T78124 (10aaron) 3NEW p:3Triage a:3aaron [07:48:43] <^d> I think they're expecting firstChild to be a DOMElement but really it's just a DOMNode. [07:51:07] we have php code to scrape templates? [07:51:41] <^d> I have no earthly idea what this is for [07:56:56] <_joe_> if you don't have an obvious solution, we could rollback for now, no? [07:56:58] 3MediaWiki-Core-Team: LoadBalancer slave lag tweaks - https://phabricator.wikimedia.org/T78124#836047 (10aaron) https://gerrit.wikimedia.org/r/#/c/178787/ [07:58:38] i think i have one [08:02:52] the CommonsMetadata extension was written by bawolff to scrape metadata out of templates for MMV until there was a proper structured data system on commons [08:03:46] yep [08:05:26] i.e. until 2024 [08:07:01] https://gerrit.wikimedia.org/r/178790 [08:10:58] _joe_: fixed: https://commons.wikimedia.org/wiki/File:DeEenzamenPost.gif [08:11:20] <_joe_> ori: \o/ [08:12:12] <_joe_> ori: as simple as that? [08:12:39] <_joe_> (every time I see or write '===', it makes me sad) [08:31:50] <_joe_> mmmh still getting the error on the original url though [08:32:26] <_joe_> and it worked earlier.... [08:33:51] <_joe_> did someone revert ori's commit? I'm seeing 500s again for that url [08:35:07] (purging doesn't help) [08:36:56] <_joe_> Nemo_bis: do not purge urls, we don't need that for debugging [08:36:57] <_joe_> :) [08:37:08] 3MediaWiki-Core-Team: LoadBalancer slave lag tweaks - https://phabricator.wikimedia.org/T78124#836063 (10aaron) [08:37:43] <_joe_> ori: your code has been reverted apparently? [08:38:12] <_joe_> in prod I do not see your fix in /srv/mediawiki/php-1.25wmf11/extensions/CommonsMetadata/TemplateParser.php:333 [08:39:05] <_joe_> mmmh, or just not synced [08:39:07] <_joe_> wtf [08:39:14] yeah, i didn't update the submodule apparently [08:39:18] <_joe_> mw1030 has the old version of the file [08:39:24] not any more [08:39:28] <_joe_> ok :) [08:39:33] <_joe_> how come it worked earlier? [08:39:36] <_joe_> :P [08:40:14] i live-hacked mw1019, maybe you happened to hit it [08:40:22] or just luck, i dunno [08:52:09] <_joe_> ori: cache I think [08:56:37] right [12:21:18] 3MediaWiki-Core-Team, MediaWiki-Parser: Make Parser::parse handle recursion better (throw exception or tolerate it) - https://phabricator.wikimedia.org/T76651#836266 (10Aklapper) [14:43:03] <^d> manybubbles: I wrote a patch last night for Phab to let them create an actual mapping/analysis rather than just relying on autocreation. [14:43:17] oh, yeah, they should have that [14:43:29] they could use templates I guess if they really wanted autocreation [14:44:18] <^d> They don't really want/need it, just using it :) [14:57:49] 3MediaWiki-Core-Team: Convert old 1.23wmf* and 1.24wmf* deployment branches to tags - https://phabricator.wikimedia.org/T1288#836914 (10Krinkle) Tried the following on `mediawiki/extensions/TemplateData` as test. Seems to work fine. ``` #!/usr/bin/env bash remote='origin' version='1.23' git remote update $remot... [15:42:13] <^d> manybubbles: It includes some sane analysis so we'll get substring matches :) [15:43:53] <^d> https://phabricator.wikimedia.org/P140 [15:54:03] grr. Why is phabricator sending me a bunch of "diffusion committed" emails that have links I can't actually see? [15:54:43] <^d> Known. Not sure. [15:54:47] <^d> A) It wasn't supposed to notify. [15:54:50] <^d> And didn't in testing. [15:55:07] <^d> B) Not sure why the commits aren't showing up for non-admins yet. Waiting to see if it's a "wait until it's done importing" thing. [15:55:53] 'A' is the annoying part. [15:56:49] <^d> Yes. [15:57:13] <_joe_> manybubbles: java 8 is ok-ish [15:57:26] <^d> anomie: (B) seems to be self-resolving as things finish importing at least. [15:57:28] <_joe_> meaning, if we need it, we can build a package [15:57:32] <^d> I'm going to send an apology to wikitech-l. [15:57:37] _joe_: yeah? no openjdk package for it? [15:57:52] <_joe_> manybubbles: I didn't check the version on jessie [15:58:42] <_joe_> and no, no openjdk-8 package it seems [15:58:48] <^d> anomie: https://lists.wikimedia.org/pipermail/wikitech-l/2014-December/079810.html [15:58:52] bleh [15:59:03] <_joe_> it's in sid though [15:59:11] <_joe_> so presumably an easy backport [15:59:17] ah cool [15:59:41] <_joe_> manybubbles: do we have a phab board for the project? [15:59:48] <_joe_> I can start putting tasks there [16:32:31] ugh [16:32:47] i'm getting silly emails from Diffusion about really old revisions as they're being imported [16:32:54] <^d> Yes yes yes. [16:32:58] <^d> Read your wikitech-l. [16:33:03] okay. [16:33:22] (i don't mind, but figured it's worth saying. i haven't gotten to wikitech-l in my mail today yet. :) ) [16:36:39] I just noticed that Echo's callsign is ECHO. :D [16:41:06] <^d> Yeah it got lucky like that :) [16:41:28] <^d> MatmaRex: tldr: sorry about the e-mails, shouldn't have gone out. [16:41:34] <^d> You can disable the notifs in your prefs. [16:42:16] i don't mind, that's barely a blip in my inbox. ;) [16:56:11] * MatmaRex wonders what is the purpose of https://phabricator.wikimedia.org/project/wiki/ [16:56:53] <_joe_> manybubbles: so, add me to your meetings [16:56:59] _joe_: will do! [16:57:13] <_joe_> also, do you have a phab board for the project? [16:57:52] MatmaRex: an error page describing what to do if you had the wiki extension/plugin installed, which we don't (for obvious reasons) [16:58:08] _joe_: done [16:58:56] <^d> MatmaRex: No idea. Nothing we setup afaik. [16:59:26] it's linked from the UI [16:59:42] (on https://phabricator.wikimedia.org/project/view/13/ for example) [16:59:56] i know that phab liked bait-and-switch, just saying. :) [16:59:58] likes* [17:00:31] (speaking of which, you could totally add me to that project.) [17:00:50] <^d> {{done}} [17:01:12] <^d> Oh, it's grey. [17:01:18] <^d> You're not supposed to click that I guess ;-) [17:01:29] <^d> Phab does silly things like that. [17:01:41] <^d> "Oh this button. You shouldn't click that. So we'll just dim it a bit and pop up if you do" [17:01:54] <^d> Other things they do totally right! :) [17:02:12] it's not grey for me [17:02:15] hm [17:02:19] not as grey as other buttons [17:02:23] i guess it's a middle grey [17:02:38] if i had better eyesight and brighter display, perhaps i could distinguish all these greys! [17:02:58] http://i.imgur.com/0zJVQyN.png [17:12:31] bd808: around? [17:12:44] hey aude. what's up? [17:13:53] in terbium or somewhere, i want to find out how fast a particular method is in wikibase (e.g. via eval.php) [17:13:58] and alternative [17:14:18] and get xhprof results somewher [17:14:23] if/how ? [17:14:38] * aude sees https://gerrit.wikimedia.org/r/#/c/174372/2/wmf-config/StartProfiler.php from tim but not exactly waht i need [17:15:03] hmmm... I think that it's possible. Aaron did some related work recently I think. [17:15:22] We don't have xhprof on terbium though :( [17:15:32] we only have xhprof on the hhvm servers [17:15:42] <^d> We really need terbium/tin to move to trusty. [17:15:49] yeah [17:16:29] ^d: do you remember the way to profile an mwscript off the top of your head? [17:16:54] It should take a --profile arg I think. [17:16:56] ah, ok [17:17:04] --profile might work [17:17:11] <^d> --profiler=text [17:17:12] aude: Yep, it does [17:17:18] I literally just used it [17:17:18] https://gist.github.com/filbertkm/24d1dd082daae5bdb2b1 is basically what i need [17:17:21] <^d> On all maintenance scripts. [17:18:10] and then see if doing further filtering in the query is better or filter in php after, since our table is gigantinormous and slow [17:18:23] thanks :) [17:18:24] We don't install the mwscript wrapper on the mwXXXX servers, but it's just a little wrapper [17:18:43] <^d> --profiler isn't a mwscript thing, it's a core MW thing. [17:18:56] yeah, you should be able to ssh to an mw box and run a script without it [17:20:10] I've found a crazy hack to make a script and run it with eval.php -- cat create-monolog-config.php | tr "\n" " " | mwscript eval.php --wiki=enwiki | tee monolog.php [17:20:13] ok [17:20:22] :) [17:20:35] O.ri said there was something easier for this but I never found the code [17:21:10] My "create-monolog-config.php" does not have an opening Does anyone know if the config we have to make a separate log file for slow-parse on the private wikis is super important? I'm trying to write a monolog config for prod and wondering how complicated I need to make it. [17:36:34] sounds meh to me [17:36:55] That's the sort of answer I was hoping for. :) [17:37:23] bd808: at one point there was a plan to expose the slow-parse log publicly (or semi-publicly) so people could improve templates and stuff, but I don't think that ever happened [17:37:42] ah. That would make the separation make sense [17:38:27] how about the 'articles' and 'imagemove' logs for testwiki? [17:39:33] no idea... [17:39:38] It amy just be easier as a first step to generate this config at runtime I guess... [17:39:43] *may [17:39:56] it's just slotting some stuff in arrays [17:40:17] * bd808 works on a patch to do that as step-0 [18:00:20] anomie: Who do you need to review https://gerrit.wikimedia.org/r/#/c/171989/ ? [18:00:34] Language / niklas? [18:01:10] csteipp: Yes. I think I saw Nikerabbit say he's planning to look at it Thursday. [18:01:17] cool [18:04:18] <^d> manybubbles: As phab catches up and starts indexing a bajillion things the phabricatormain index may get larger. I'm keeping an eye on things and might end up resharding if need be. [18:05:13] <^d> Primary store size is still under 1gb so we're fine. [18:08:05] anyone know what the status of hhvm on api machines is? [18:08:35] all API servers run hhvm now [18:08:46] awesome [18:08:51] https://lists.wikimedia.org/pipermail/wikitech-l/2014-December/079795.html [18:09:13] ahh cool. I should probably be on that mailing list [18:09:53] legoktm: do you still have any machines left using PHP5? [18:10:05] <^d> image scalers [18:10:07] <^d> job runners [18:10:19] lots of misc boxes [18:10:26] <^d> deploy host (tin), scripting/cron host (terbium) are notable. [18:10:33] dump servers [18:11:06] ok [18:11:32] I kind of wonder what will be helped and what will be hurt by making terbium run hhvm as /usr/bin/php. [18:12:19] We should convert deployment-bastion in beta to see what breaks first I suppose [18:12:54] <^d> bawolff suggested image scalers next which is interesting. [18:13:04] ori: The unit tests found a little problem with MWTidy -- https://gerrit.wikimedia.org/r/#/c/178872/ [18:13:15] <^d> less so for hhvm but moreso us wanting trusty anyway for that. [18:13:36] Yeah, he wants newer image libraires [18:14:13] AaronS: Should that be backported? It read to me like tidy is disabled on hhvm otherwise [18:15:02] ^d: unless you're scaling images by twdlding bits in php code I wouldn't expect hhvm to help too much there [18:15:10] <^d> Nah, it won't :) [18:15:27] <^d> We just want trusty for updated libav & so forth. [18:15:46] we could rewrite libav in hack :) [18:15:48] ah yeah [18:15:53] haha [18:16:11] well we do want to be fast enough that most extensions can be written in pure php [18:16:18] I doubt we'll ever get there for image scaling though :P [18:16:43] ^d: https://gerrit.wikimedia.org/r/#/c/178447/ [18:20:17] bd808: how so? [18:20:47] if ( !class_exists( 'tidy' ) ) { ... return null } ? [18:21:41] Or have we not switched on the internal vs shelling out flag yet? [18:31:16] it's set to internal afaik [18:48:00] <_joe_> swtaarrs: API is 100% HHVM [18:48:18] <_joe_> sorry I mentioned that in #hhvm-dev yesterday and I thought you was there :) [18:50:36] AaronS: Looks like $wgTidyInternal == false (via eval.php on terbium), so no need to backport as long as ori isn't planning on changing that soon for hhvm servers. [18:50:44] _joe_: cool, thanks. I'm sure I was there but I miss lots of messages that don't get highlighted :) [18:52:36] <_joe_> swtaarrs: btw https://twitter.com/HipHopVM/status/542386731300163585 [18:52:48] yeah :) [18:52:50] pretty awesome [18:53:01] bd808: huh, I thought we switched to internal to avoid slowness in the api [18:53:02] and that's without stat_cache, right? I think ori's still playing around with that on just a couple servers [18:54:06] <_joe_> swtaarrs: with stat_cache [18:54:18] <_joe_> we decided it was good enough for us [18:54:23] oh, ok [18:54:34] that's less of a difference than a www machine [18:54:36] at least the one I saw [18:54:51] is there something I can do to the url of ganglia graphs to shift the time window they show? [18:54:54] AaronS: Well if we had it would have gotten really fast by returning null instead of cleaned html [18:55:45] bd808|LUNCH: on class_exists( 'tidy' )? [18:56:41] AaronS: I *think* so but maybe that's a false assumption. The jenkins tests are still failing with the same error. [18:56:50] * bd808|LUNCH rechecks locally [18:56:59] that wasn't changed in your patch [18:57:21] <_joe_> swtaarrs: select with the mouse [18:57:25] <_joe_> in the graph [18:57:31] hmm [18:57:32] <_joe_> it sucks badly btw [18:57:34] just a new way to return null [18:57:36] _joe_: I'm looking at http://ganglia.wikimedia.org/latest/graph.php?r=week&z=xlarge&h=mw1081.eqiad.wmnet&m=cpu_report&s=descending&mc=2&g=cpu_report&c=Application+servers+eqiad [18:57:41] it's just a static image [18:58:11] AaronS: apparently my patch is worthless. The tests pass for me locally without it as well [18:58:12] bd808|LUNCH: did you mean to include !wfIsHHVM() for the class check? [18:58:49] <_joe_> swtaarrs: from here I mean http://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&m=cpu_report&c=Application+servers+eqiad&h=mw1081.eqiad.wmnet&tab=m&vn=&hide-hf=false&mc=2&z=small&metric_group=ALLGROUPS [18:59:00] _joe_: ahh, thanks [18:59:19] <_joe_> swtaarrs: told you, it sucks :) [18:59:47] <_joe_> oh after you selected an interval, in order to remove it you need to click 'clear' above the graphs [19:00:01] ok [19:00:19] AaronS: Yeah my logic there is broken too. It should check for the class in php5 and the function in hhvm exclusively [19:00:45] <^d> Nikerabbit: Do you think we still need the solr box around for TTM? [19:00:52] but whatever I guess. Seems to still be a jenkins slave issue somehow anyway [19:01:17] bd808|LUNCH: right, I thought it was just a sanity commit when I first saw, didn't check the summary well enough [19:03:11] <_joe_> ori: around? [19:03:22] <_joe_> I have moderately good news about this [19:03:44] <_joe_> ehrr, the imagescalers/videoscalers [19:03:46] bd808|LUNCH: making a follow up [19:04:07] <_joe_> bbiab [19:05:19] bd808|LUNCH: https://gerrit.wikimedia.org/r/#/c/178884/2 [19:07:43] * bd808|LUNCH really gets food now [19:10:33] ^d: the "make results consistent enough" task was closed, fwiw [19:26:51] _joe_: is there any way to increase the precision of http://ganglia.wikimedia.org/latest/graph.php?h=mw1072.eqiad.wmnet&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=11%2F29%2F2014%2014%3A24&ce=12%2F8%2F2014%2020%3A10&st=1418239523&g=cpu_report&z=xlarge&c=Application%20servers%20eqiad , or is the data just stored with less resolution over time? [19:31:59] <_joe_> swtaarrs: not that I know off, no [19:49:15] <^d> legoktm: I think the feed jobs are going down now. [19:49:26] <^d> bots etc should start catching up. [19:50:54] ^d: I killed wikibugs so I could deploy some other changes to it (and one that will prevent it from getting backlogged again) so it lost the backlog [19:51:05] <^d> ah k [19:51:36] <^d> PhabricatorSearchWorker 531,633 [19:51:36] <^d> FeedPublisherWorker 144,330 [19:51:36] <^d> PhabricatorRepositoryCommitOwnersWorker 25,154 [19:51:38] <^d> PhabricatorRepositoryGitCommitChangeParserWorker 1,516 [19:51:40] <^d> PhabricatorMetaMTAWorker 189 [19:51:42] <^d> PhabricatorRepositoryGitCommitMessageParserWorker 63 [19:51:44] <^d> PhabricatorRepositoryCommitHeraldWorker 53 [20:21:59] 3MediaWiki-General-or-Unknown, MediaWiki-Core-Team: MediaWiki tests using Tidy do not pass on HHVM - https://phabricator.wikimedia.org/T78166#838803 (10hashar) The first time the tests fails is https://integration.wikimedia.org/ci/job/mediawiki-core-regression-hhvm-master/2902/testReport/ at noon. Around that t... [20:31:41] manybubbles: https://github.com/orientechnologies/orientdb/issues/2160 is amusing [20:34:40] wow that is a lot of back and forth [20:34:58] AaronS: so it looks like someone implemented another improvement and used it as an excuse to close the issue [20:35:07] ;) [20:35:35] I love the "yeah, but it didn't add anything" bits, heh [20:36:29] Like ES, I think all of the distributed stuff and conflict management will be very "Call me Maybe" [20:40:15] ^d: ops have ticket for killing it [20:40:47] <^d> Ah cool [20:45:28] AaronS: if we're doing wfRunHooks-->Hooks::run, does it also make sense to change other global functions that are direct wrappers like wfGetCache-->ObjectCache::getInstance? [20:45:47] probably [20:46:06] 3MediaWiki-General-or-Unknown, MediaWiki-Core-Team: MediaWiki tests using Tidy do not pass on HHVM - https://phabricator.wikimedia.org/T78166#838955 (10hashar) 5Open>3Resolved a:3hashar The latest change merged no more has the problems: https://integration.wikimedia.org/ci/job/mediawiki-core-regression-hhv... [20:50:24] mh :/ [20:52:21] tinkerpop3 has time limits http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#timelimit-step - nice! [21:01:45] SMalyshev: yeah! they were excited about them [21:14:19] this one is nice: http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#local-step probably can be very useful for qualifiers [21:35:06] <_joe_> SMalyshev: I took a look at tinkerpop, it makes me want TSQL [21:35:30] <_joe_> but well, I like sql :) [22:32:38] Can somebody look at https://gerrit.wikimedia.org/r/#/c/178977 to see if I did anything obviously stupid before I push it to beta? [22:33:41] the_nobodies: ^ maybe you've got a minute? [22:33:58] yep, I've already seen you adding me as a reviewer [22:34:20] looks reasonable, but I don't know this stuff [22:34:32] merge and see if something breaks? [22:34:44] Yeah I think it's a bit like that [22:35:09] * bd808 is parked on tin and will do the deed [22:36:24] the_nobodies: I thought you'd at least like to see the +74,-711 part of that since you cringed when I did the initial patch :) [22:36:36] :P [22:48:13] 3MediaWiki-Core-Team: Look at WDQ tool API - https://phabricator.wikimedia.org/T78203#839321 (10aaron) 3NEW [22:48:26] 3MediaWiki-Core-Team: Look at WDQ tool API - https://phabricator.wikimedia.org/T78203#839321 (10aaron) p:5Triage>3Normal a:3aaron [22:49:24] 3MediaWiki-Core-Team: Look into WDQ tool API language - https://phabricator.wikimedia.org/T78203#839321 (10aaron) [22:49:58] <^d> manybubbles: Using Elastica has spoiled me. [22:50:03] :) [22:50:13] <^d> In Phab I'm having to create arrays of parameters and fire off http requests :p [22:56:17] <^d> manybubbles: On the upside their mapping is dead freaking simple and only like 2 fields need any real analysis. [22:56:30] oh, well, that'll be nice and quick [22:56:34] <^d> The rest are pretty static type things like types, cross-references, etc. [23:05:05] TimStarling: AaronS, we're in the hangout and about to start [23:05:18] "no value is represented as item 4294967295", "unknown value is represented as item 4294967294" [23:05:21] manybubbles: heh [23:05:46] that. sounds. like. a way to do it, actually [23:06:28] and, yeah, FFFFFFFF [23:07:33] ^d: I'm an optional person ;) [23:09:37] <^d> AaronS: Yea no worries. [23:11:04] http://etherpad.wikimedia.org/p/MWCore2015Jan [23:33:19] ori, https://en.wikipedia.org/wiki/MediaWiki:Gadget-popups.js :P [23:42:35] the_nobodies: https://en.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-popups.js&diff=637544961&oldid=635402064 [23:43:20] sigh [23:44:27] https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&oldid=635402064 still reproduces the error [23:45:08] why is it even 503 instead of displaying a WMF error? [23:55:11] 3MediaWiki-Parser, MediaWiki-Core-Team: Make Parser::parse handle recursion better (throw exception or tolerate it) - https://phabricator.wikimedia.org/T76651#839468 (10Welterkj) A trivial test using WikitextContent::getParser copied from MessageCache::getParser worked (replaced all instances of $wgParser in Wik...