[07:40:57] hello [08:50:55] don't we have a way to display a notification to the users ? [08:51:12] my use case is having a list of actions, each action points to a new form [08:51:21] on form submission I would like to redirect the user to the list of actions [08:51:30] and add a notification at the top saying how well the action went [08:51:43] (aka a nice green box saying "action completed successfully" [09:17:47] hmpf these fake @users.mediawiki.org emails make finding contacts of commit authors even more a pain [09:31:14] hashar: for instance how do I find if Rotem Liss is still active? [09:33:07] Nemo_bis: the name@users.mediawiki.org could probably be mapped using the USERINFO files [09:33:22] Nemo_bis: or poke ^daemon about it whenever he comes back :-D [09:33:40] Nemo_bis: as for rotem activity, I have no idea. I don't have any specific access on labs to figure it out [09:35:04] it shouldn't be so hard [09:35:33] it used to be so simple, go to the table and click https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/rotem [09:38:04] hashar: also, I'm learning to use git blame, but how do I find what tobias is this? 22d58ec0 (Tobias 2009-09-23 19:55:45 +0000 20) 'cite_text' => '', # Do not translate this [09:39:53] Nemo_bis: git show 22d58ec0 ? [09:40:20] hashar: ok [09:40:47] let's hope I never have to guess from commit name [10:22:25] Nemo_bis if a commit is named "suicide" is that tasteless or worse? [10:23:38] ToAruShiroiNeko: I guess it would be a way to test WMF's emergency system [14:20:10] Hexmode: for my extension, if a php extension it relies on is not present, just $wgOut->addWikiText( $error_msg ); and leave MW to finish up? How should I log it, etc? [14:23:19] ^ [14:23:44] You could [14:23:53] Or just have it in the loaderfile to die if it's not loaded [14:26:20] How would I do the latter? and how/where should I log such an error? [14:27:36] (also looking up OutputPage::showErrorPage() [14:27:40] ) [14:33:12] if ( !extension_loaded( 'foo' ) ) { echo 'PHP extension foo isn\'t loaded'; } [14:38:59] kk [15:28:21] New patchset: Hashar; "pass PIDFILE to status_of_proc helper" [analytics/udplog] (master) - https://gerrit.wikimedia.org/r/16414 [15:29:17] New review: Hashar; "Added Asher, Tim and Diederik since they were in the recent history." [analytics/udplog] (master) C: 0; - https://gerrit.wikimedia.org/r/16414 [15:46:57] jeremyb: Did you ever get a chance to look at the debian packaging for Etherpad Lite? [15:54:37] https://www.mediawiki.org/wiki/MediaWiki_1.20/wmf8 [15:56:54] \o/ [15:57:38] "c8ce42c - Do not put slugs after nested lists" [15:57:46] I don't think I want any slugs at all in my wiki.. [15:58:41] It's also talking about killing children [15:58:42] Reedy: Come now, they're a natural part of the ecosystem [15:58:55] The ciiiiiiiircle of liiiiiiife [15:59:58] * ^demon whacks gerrit with a 2x4 [16:00:45] <^demon> http://code.google.com/p/gerrit/source/browse/gerrit-extension-api/src/main/java/com/google/gerrit/extensions/events/NewProjectCreatedListener.java is the entire new project hook. [16:01:06] <^demon> I have almost zero info to work with, and you don't have ability to affect further actions. [16:04:41] ^demon: Can you easily add things to that interface? [16:05:10] <^demon> I could, but I don't know if it'd get accepted upstream. [16:05:23] <^demon> I want to pass a way of halting further execution in certain scenarios. [16:05:36] <^demon> My use case is this: have a skeleton repo that gets copied over on new repo initialization. [16:09:22] ^demon: Why not have the repo, wait for the new repo to be ready, then do a merge of the skele-repo? [16:09:33] * marktraceur is just brainstorming [16:10:53] <^demon> Actually, I might factor "initial empty commit" out, making that part easier to plug. [16:14:30] <^demon> marktraceur: In "really, you're just now thinking of that" news....https://gerrit-review.googlesource.com/#/c/35220/ [16:18:34] ^demon: Ha! That should make Gerrit even faster then, eh? [16:18:49] <^demon> Yup. Prolly won't make it in the 2.5 cycle, but who knows. [16:18:52] <^demon> :) [16:28:50] chrismcmahon: feel free to start poking 1.20wmf8 on test2wiki [16:29:56] Reedy: check [16:32:37] hey - does anyone know the irc names of aaron schultz or mglaser? [16:33:19] Aaron is usually AaronSchulz, likely be around soon [16:33:35] I think markus uses mglaser, but he's not around on irc so often [16:33:36] ah. sweet. Just wanted to ask him a question about his code review. Make sure I'm looking at the same thing he mentioned. [17:42:18] hey Platonides. Thanks for your review. [17:42:24] I just realized that [17:42:26] not sure why [17:42:42] I checked the files on my local branch and they're showing tabs [18:00:35] marktraceur: people have just started departing from my city post wikimania [18:00:57] jeremyb: Fair enough, just checking in [18:00:57] marktraceur: remind me the status? [18:01:20] or should i just check mail from you? [18:02:51] jeremyb: I have a package up at http://marktraceur.info/shared/packages/etherpad-lite/ [18:03:04] And the code is up at my github repo, sec [18:03:18] https://github.com/MarkTraceur/etherpad-lite [18:03:23] is there a source package too? [18:03:32] Errrr, maybe [18:03:43] I'll see if I can pull it up, if I can, I'll put it in the same spot [18:04:02] k [18:04:49] jeremyb: OK, my noobness in debian packaging shows: Would it have a different file extension? Did debuild -us -uc build it for me? [18:05:04] uhhh, i don't know [18:05:22] Hm. [18:05:52] marktraceur: also, was typing: fyi, realistically I have some stuff (unrelated) coming due at the end of this month that I need to work on. so i might not look much until august. can poke a few people to see if they want to take a stab first [18:06:10] lets see if they have an answer to that most recent question ;) [18:07:35] marktraceur: /j #wikimedia-operations [18:10:15] marktraceur: err, actually it wasn't so hard for me to find the answer myself. see the top of the options section @ `man dpkg-buildpackage` [18:11:34] marktraceur: have you discovered whether you can work on i18n issues? [18:12:13] Nemo_bis: The ones on transaletwiki? My stance is still "probably not", let me ping Erik and see if he's firm on letting UW be [18:12:22] oki [18:12:35] Nemo_bis: The issue is, very few people are available for UW code review, so my patchsets are piling up [18:12:55] everyone's patchsets are piling p becase gerrit is aweful [18:13:12] *awful [18:13:24] Nemo_bis: https://gerrit.wikimedia.org/r/#/q/owner:MarkTraceur+status:open+project:mediawiki/extensions/UploadWizard,n,z [18:13:25] haha [18:13:30] Not as bad as it used to be, though [18:13:36] *click* [18:15:29] marktraceur: look at it from the other side, e.g. https://gerrit.wikimedia.org/r/#/dashboard/93 [18:16:21] Nemo_bis: Guh, I can see the problem :) [18:16:42] If only there were a way I could help....don't have enough experience with core or other extensions, methinks [18:20:02] Nemo_bis: Could you PM an email address so I can CC you? [18:25:03] marktraceur, you want a task? [18:25:29] wow, Nike has a really long queue of review requests [18:25:31] Platonides: *gasp* a task!? What kind? [18:25:54] (and yeah, seriously) [18:26:39] I thought Siebrand might have more, but evidently not [18:27:27] you see, the logging table stores the log_namespace, log_entry of the affected pages [18:27:35] it also stores at log_page the page_id [18:27:59] for an upload action, log_page gets a 0 [18:28:14] the goal is to store there the page_id of the description page [18:28:49] Hm, yes, that sounds about right [18:29:29] it will be very useful during WLM2012 to have that fixed [18:29:49] Platonides: I'm not certain I'm the right person to ask; have you filed a bug and added it to the WLM 2012 tracking bug? [18:29:51] you'll probably need to dive into log classes [18:30:01] nope [18:30:12] it's just one of those things "I had in mind to do" [18:30:34] !b 37144 | Platonides [18:30:34] Platonides: https://bugzilla.wikimedia.org/show_bug.cgi?id=37144 [18:31:13] that's a bug against upload wizard :P [18:31:21] this is a bug in core [18:31:25] Platonides: True, but there are core bugs listed too [18:31:30] Platonides: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&component=Logging [18:32:20] I'll happily create a bug for that [18:32:26] !32410 | Platonides: Example of tracked core bug: [18:32:31] !b 32410 | Platonides: Example of tracked core bug: [18:32:31] will that make you merrily go fixing it? :) [18:32:32] Platonides: Example of tracked core bug:: https://bugzilla.wikimedia.org/show_bug.cgi?id=32410 [18:35:05] Platonides: It will be a very good start, yes [18:37:00] {{done}} [18:37:07] https://bugzilla.wikimedia.org/show_bug.cgi?id=38606 [18:39:05] Platonides: I see! I'll add this to my other discussions about UploadWizard at earliest convenience [18:40:20] Warning: socket_getpeername(): supplied resource is not a valid Socket resource in /usr/local/apache/common-local/php-1.20wmf8/includes/objectcache/MemcachedCl [18:40:20] ient.php on line 946 [18:41:01] IIRC nothing has changed in that.. [18:49:05] is there a special channel to ask about skins or extensions, or is this a good channel? (I don't want to bug you if this is the wrong list) [18:53:01] shepazu, #mediawiki [18:53:09] thanks, MaxSem [20:04:37] * marktraceur feels a little self-destructive today [20:04:58] If there are any pending JavaScript changes that people would like preliminary review for, I'd be willing to help out [20:05:11] Sort of speed up the process a bit [20:06:22] Krinkle-meeting: https://gerrit.wikimedia.org/r/#/c/15626/1/INSTALL [20:12:47] marktraceur: AFAIK there are some outstanding for the apisandbox [20:13:20] Reedy: Mmmkay, pending someone pointing me at changes, I'll browse that [20:14:22] Only three, but thanks [20:14:34] probably a load more [20:17:11] I can only see three, but if you know where more are, I'd be happy to glance at them [20:17:29] they might've been reviewed [20:17:34] I think there were others about [20:50:25] So apparently all my extensions weren't fully upto daate... :| [20:51:21] I wish it just worked as well as svn update ~/mediawiki --ignore-externals [20:51:44] We apparently have an extension called carp.. [20:51:46] !e Carp [20:51:46] https://www.mediawiki.org/wiki/Extension:Carp [20:52:24] marktraceur: that syntaxhighlight geshi bug must be new.. [20:52:59] Reedy: can I have your opinion about more options in bugzilla? [20:53:14] all of the options? [20:53:20] * Reedy goes to find a drink [20:54:30] Warren Ellis's cocktail. [20:55:19] no, I suggest adding fix released when adding a patch, and fix committed when it gets into production [20:55:30] better than fixed resolved I think [20:56:26] and more descriptive. the option of fix released has no equivalent today [20:57:28] Someone changing site css most likely [20:59:05] https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en-gb&modules=site&only=styles&skin=vector&* [20:59:29] matanya, it'd be nice if that last step happened automatically [20:59:38] it can [21:00:00] it could be done by bot, for instance [21:00:02] * Handle overflow (bug 260) [21:00:02] * Experimental [21:00:02] */ [21:00:02] pre, .mw-code { [21:00:02] white-space: pre-wrap; [21:00:05] word-wrap: break-word; [21:00:07] } [21:00:11] https://www.mediawiki.org/wiki/MediaWiki:Common.css [21:00:24] Yup [21:00:28] I thought it might be [21:00:31] * Reedy blames Krinkle-meeting [21:00:43] Platonides: quite easily, I done it at work [21:02:22] Reedy: Thanks for the fix! Was it really a mw.org-specific thing? [21:02:37] Yup [21:02:43] Added 2 days ago by Krinkle [21:03:09] Platonides: what is needed to process this? a bug on bugzilla? [21:03:14] Hm [21:03:16] Craziness [21:03:48] We need something like git blame, but for MediaWiki [21:03:57] It would make things like this much easier :) [21:05:20] it is called history on mediawiki :P [21:05:51] matanya: Which is sort of like git diff HEAD~1 HEAD~2 .... git diff HEAD~2 HEAD~3 [21:06:12] yes, somewhat annoying [21:06:14] git blame MediaWiki:Common.css BAM it's Krinkle-meeting's fault [21:06:25] marktraceur: long requested feature [21:06:26] hey, could someone with deployment rights syncdir extensions/E3Experiments to testwiki? (cs: https://gerrit.wikimedia.org/r/#/c/16448/) [21:06:33] yeaj [21:06:34] Nail the bad guy, get the love interest, happily ever after [21:07:25] Reedy: thanks again, that's awesome [21:07:28] Done [21:10:03] Augh, the fates, curse them [21:10:07] Reedy: something what is it about? I did indeed add that on mw.org, did it break something? Am I missing part of the convo here? [21:10:12] anyway, heading out to lunch, brb later [21:10:16] * marktraceur faintly remembered the "file:" syntax in gerrit [21:10:19] Added leading newlines [21:10:28] * marktraceur had forgotten that it didn't work for most queries [21:11:38] Krinkle-meeting: You made the area for the highlighted code have about three extra newlines, which was particularly noticeable in pages with many one-line code examples [21:12:32] Reedy: w00t :) thanks again [21:12:54] Krinkle-meeting: Unrelated matter, 16151 needs merging, needed for other work [21:13:17] (I can merge it, I'd just like to make sure your review is satisfied) [21:13:19] !g 16151 [21:13:19] https://gerrit.wikimedia.org/r/#q,16151,n,z [21:14:03] RoanKattouw: Up for some JavaScript review? :) [21:14:10] Going to lunch [21:14:19] I'm onboarding Krinkle-meeting onto the VE team so we're all busy [21:15:12] *nod* best of luck [21:15:25] Ha, who am I talking to? [21:15:38] <^demon> Yourself. Don't worry, it's perfectly natural. [21:16:49] ^demon: Your encouragement may not be healthy, but it certainly is appreciated [21:16:58] <^demon> :) [21:17:14] Also, /me hadn't realized 'til just now that Catrope == RoanKattouw [21:17:46] marktraceur: for your ease --> https://meta.wikimedia.org/wiki/System_administrators :) [21:20:48] matanya: This makes life so much less complicated, thank you [21:20:53] Ctrl+b [21:21:05] * marktraceur forgot how to bookmark [21:21:09] Ctrl+d [21:21:26] in firefox it is the ctrl + b [21:22:53] marktraceur, the Catrope nickname is barely used these days [21:35:42] matanya: Ctrl+b brings up the bookmark interface, Ctrl+d bookmarks the page and opens a dialog for renaming/reorganizing it [21:35:58] oh [21:52:40] Things I learned today: I've been writing anonymous function definitions correctly the whole time [21:52:49] Self-doubt, begone [22:01:33] AaronSchulz: if you have any hint about thumb_handler.php I am all for it [22:02:50] hashar, you have problems there? [22:03:04] well I need to fix up the thumb system on beta [22:03:12] AaronSchulz told me about thumb_handler.php [22:03:20] which seems to be meant to be used as a 404 error handler [22:03:34] I guess I could make the beta apache to use that script to handle 404s [22:04:00] it's so nice that things are working at production but we don't know how they are done... [22:04:16] so far I have been mostly fighting with the beta logging system to find out what the issue was [22:04:25] ooo [22:04:31] we know how it is done in production :-] [22:04:34] it is well documented [22:04:49] but there is two layers of lvs (which we don't have in beta), a nginx proxy and some over stuff [22:06:08] Platonides: https://wikitech.wikimedia.org/view/Swift/Dev_Notes#Thumbnail_Retrieval ;) [22:06:21] the current path https://wikitech.wikimedia.org/view/File:Thumbnail_request_path.jpg [22:11:36] hashar: so does labs have dedicated scalars now? [22:12:12] * AaronSchulz wonders if there are some docs somewhere [22:13:49] * marktraceur read "does labs have dedicated scholars now?" [22:14:14] Not sure what was in that water, it must have been pretty good stuff [22:18:32] AaronSchulz: I wrote a small overview at https://labsconsole.wikimedia.org/wiki/Deployment/Overview [22:18:55] basically the thumbs are supposed to be sent to the application servers [22:19:06] I got a squid as frontend for upload.beta.wmflabs.org [22:19:21] but then there is all the rewriting stuff to handle :-/ [22:19:57] for now I have the nice "The source file for the specified thumbnail does not exist" [22:19:58] http://commons.wikipedia.beta.wmflabs.org/w/thumb.php?f=Demo_MenuActions4.png&width=800 [22:20:09] must be a filebackend misconfiguration somewhere [22:22:07] hashar, it doesn't seem to live there [22:22:15] try with a file locally uploaded first [22:22:24] instead of one transcluded from the real commons [22:25:34] well we have a foreignAPI backend [22:25:56] I am kind of expecting thumb system to trigger a fetch from the foreign backend [22:26:02] hashar: is there a beta commons? [22:26:09] FileBackendStore::getFileStat: File mwstore://local-backend/local-thumb/e/ef/ResizeIssue_bla_bla.png/180px-ResizeIssue_bla_bla.png does not exist. [22:26:21] AaronSchulz: there is one at http://commons.wikimedia.beta.wmflabs.org/ [22:26:25] hashar, http://commons.wikipedia.beta.wmflabs.org/w/thumb.php?f=Nigerians_glamorizes.jpg&width=200 works [22:27:00] so it works with local files [22:27:07] ahhh [22:27:09] it is a problem with commons foreign repo [22:27:15] thumb.php only checks the local repo [22:27:16] thanks for debugging that [22:27:32] !g 14404 | hashar: Ping re [22:27:32] hashar: Ping re: https://gerrit.wikimedia.org/r/#q,14404,n,z [22:27:54] (I'm sure you're busy, but worth a reminder) [22:28:03] the conf is in wmf-config/filebackend-wmflabs.php . Commons indeed just have a $wgLocalFileRepo :D [22:28:30] marktraceur: 14404 is merged in :-] [22:28:41] Oops [22:28:47] !g 14401 | hashar: Ping re [22:28:47] hashar: Ping re: https://gerrit.wikimedia.org/r/#q,14401,n,z [22:28:58] marktraceur: I was supposed to review your changes today (which is my codereview day) [22:29:05] need to concentrate on your change and get them merged in [22:29:22] *nod* OK! I'm not super-rushed about it, but good to know you're on the way to it [22:29:42] Actually, I should rebase [22:30:04] if you feel like doing it, go ahead :-] that is a good git/gerrit exercise [22:30:36] *nod* [22:30:43] I think I have some local changes as well [22:30:48] might not have pushed them in Gerrit [22:31:35] Noo, looks like you pushed some [22:32:21] Once these get merged, I have a lot of new methods to check [22:32:28] Which should be fun [22:32:31] :-D [22:32:46] I have sent me a reminder to move that to the top of my backlog :-D [22:32:53] hopefully will manage to review them "soon" [22:33:02] Good plan [22:33:20] * marktraceur tries to rebase off master [22:33:33] Ha, too much to hope gor [22:33:35] for* [22:33:58] AaronSchulz: should we make thumbs.php to check the foreign repo [22:33:59] ? [22:34:42] not sure [22:35:02] that would be great for beta [22:35:06] so you want real commons files to work on betalabs? [22:35:14] cause we don't have a full snapshot of commons images [22:35:24] and the beta wikis are using some extract of the real wikis pages [22:35:34] example: http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page [22:36:34] I'm not sure that would work [22:37:01] I think the wikipedias will need to have the real commons configured [22:37:31] or simply, if betacommons has a full copy of image table [22:37:35] that should trick them [22:37:51] we are rendering on the handler after all [22:39:37] well I am off [22:39:37] [22:39:52] at least I have some explanation about the thumbnails ! thanks Platonides and AaronSchulz ! very helpfull. [22:39:56] have a nice afternoon / night [22:40:05] see you [22:40:28] Reedy: i think this is the last one https://gerrit.wikimedia.org/r/#/c/16456/ (if you still have a moment) [22:41:34] Reedy: thanks [22:43:01] !g 134323 [22:43:01] https://gerrit.wikimedia.org/r/#q,134323,n,z [22:43:24] ori-l: done [22:46:31] Reedy: much obliged [23:06:01] anyone have any thoughts on https://wiki.php.net/ideas/bytecodetollvm ? [23:08:32] I think it's an idea that will stall [23:09:33] TimStarling: yeah I don't see it gaining any traction [23:10:03] I did some work on it over the last few days [23:10:34] it looks like it may provide a small performance gain for a small amount of effort [23:10:37] TimStarling: from scratch? [23:10:46] TimStarling: or from the prototype? [23:11:03] mostly just trying to get the prototype working with the current version of LLVM and PHP [23:11:41] so I've read the code, and a lot of the LLVM docs and source as well [23:12:36] it's only ~1000 lines, maybe it would be 2000 if it were completed [23:12:46] tiny compared to hiphop or any other PHP compiler [23:13:35] it's not really clear from that wiki page, it actually has stalled already [23:13:59] i.e. Nuno Lopes wrote it in 2009 and then no work has been done on it since then [23:14:12] * AaronSchulz would be interested if it was 10% [23:14:48] TimStarling: I'm familiar with it it was part of the GSOC 2009 I believe [23:15:27] it's small enough that we could complete it and maintain it ourselves [23:16:14] TimStarling: do you like this idea better than HipHop? [23:16:59] HipHop is a complete rewrite of PHP, there's no way we can even maintain it ourselves, let alone write significant functionality [23:17:29] and Facebook haven't been releasing their internal work on HipHop recently, and they haven't been responding to github pull requests or bug reports [23:17:57] it's not really clear how committed they are to making it a public-facing open source project [23:18:37] TimStarling: yeah that's fair [23:19:01] TimStarling: what repo did you get the prototype from? [23:19:23] svn.php.net [23:20:30] TimStarling: so this one http://svn.php.net/viewvc/pecl/llvm/trunk/ [23:20:38] yes [23:22:11] TimStarling: have you talked to nlopess at all? [23:22:29] I sent an email, no response yet [23:34:37] TimStarling: would you add caching to it? [23:34:55] yeah, it'd have to have caching of some kind [23:35:29] * marktraceur just tried Phabricator a bit [23:35:35] It seems like a shockingly solid tool [23:35:54] Not sure it can totally replace Gerrit, but maybe with the right configuration it would be great [23:37:26] TimStarling: so Nuno Lopes wrote, "Basically, no, so there was little to no interest, okay, so I was contacted by two companies only, but then eventually the interest just fell down and so the project just died." [23:37:46] TimStarling: that is his reason for no more commits [23:38:16] TimStarling: and, "Yeah, so we had a student working on this for the Google Summer of Code, and his name was Joonas Govenius , if I get it right." [23:38:32] TimStarling: but it's probably worth us looking into for sure [23:39:33] I read this from http://www.phpclasses.org/blog/post/170-The-Debate-of-Making-PHP-Faster-using-a-JIT-Compiler--Lately-in-PHP-podcast-episode-19.html in the "The Debate of PHP JIT compilers (3:14)" section [23:39:51] the reason I started thinking about it was because I was looking at some PHP profiling results from Intel's profiling tool [23:40:20] it showed about 6% of execution time being due to branch misprediction in the VM [23:40:30] the Zend VM, I mean [23:40:53] most likely the reason is because of the way it fetches opcode handlers and then follows function pointers [23:41:11] the processor isn't smart enough to know what opcode handler you're going to call [23:41:48] but any VM implementation would have branch mispredictions on every opline, I don't think there's any way around it [23:42:24] but unrolling the VM main loop into a sequence of calls should avoid those branch mispredictions, and so give you that ~6% back [23:42:39] that's before any optimisation of the resulting assembly code [23:42:57] TimStarling: yeah for sure [23:43:34] TimStarling: I wouldn't be too surprised if we couldn't get it to like ~10% or so [23:46:34] btw I also did some profiling comparing PHP 5.3 with 5.4 [23:47:14] the main source of the performance improvement seems to be the introduction of the zend_literal abstraction [23:47:29] TimStarling: did you find an explanation for why the array copy test was slower in 5.4? [23:47:31] which allows a few places in the code to skip hash calculations [23:47:44] binasher: no, I didn't look at that