[03:28:35] hi [03:29:01] does anyone here have any insights into working as a software developer for wikimedia ? [12:34:35] OrenBochman: hey, how's the clone on labs [12:35:26] last I cheked it is not fully imported [12:35:30] in case you wanted me to install some extensions let me know [12:35:43] it's still in 40% [12:36:53] I think it will be done in 30 hours [12:37:08] but you can already use the site [12:37:18] it's just little bit slow [12:38:29] yep it is slow [12:38:39] it probably needs tidy as well [12:38:54] since there are broken tags [12:39:26] I can access tomcat too but jenkins does not seem to work [12:39:51] I put the war it in the web apps dir but nothing happened [12:40:21] huh [12:40:31] what [12:40:45] also the search shows only a few docs [12:40:53] but that may improve [12:41:10] aha, you mean on search [12:41:20] yes, that's because it's not finished yet [12:41:25] I agree [12:41:34] we need to let it finish [12:41:43] is there anyone else working with you [12:41:51] nope [12:42:03] I thought jeremyb \ [12:42:05] but I tried to install jenkins CI [12:42:07] he doesn't? [12:42:15] jeremyb: help out [12:42:31] helps out I mean [12:42:42] sure but only in ops [12:42:54] right, want me to help with jenkins set up? [12:43:01] he does not know much about search [12:43:03] sure [12:43:07] btw do you need a full db or latest revision only? [12:43:19] in can you wanted full you need to talk to Ryan and ask for more space [12:43:22] in case [12:43:49] ok, let me ssh [12:43:50] this instance should be just the latest revision [12:44:08] yes [12:44:11] also I you can install SOLR on tomcat [12:44:41] later I will need a much bigger instance like the real search setup [12:45:38] probaly with 4 machines in a cluseter [12:45:54] probably with 4 machines in a cluster [12:46:59] ok [12:47:04] how big db? [12:47:19] because Ryan would probably set up a separate machine for database rather than vm [12:47:28] it would be faster [12:47:44] where did you install jenkins [12:49:25] solr is installed and jenkins seems to be working [12:50:01] I think [12:50:12] I didn't set up a tunnel so I can't conect to its port [12:51:14] for full database you need at least 200 gb if you want to keep backups [12:51:56] but I think I could extract it to 80gb storage too, but probably with no recovery [12:52:11] it would not be easy though [12:53:43] btw load of test is 0.5 so I don't think it should be so slow now [14:14:07] Reedy: I am wondering how to fix that version compare stuff, is it even needed when extensions doesn't have a special page [14:14:32] 1 of 2 ways [14:14:39] You just set them unconditionally to "other2 [14:14:42] *"other" [14:14:51] Or you add the message to trunk, and then >= 1.19 you can use it [14:14:51] hm [14:15:09] it seems a reasonably enough sane group to exist [14:16:11] but it wouldn't be useable in 1.18 [14:16:22] I can't insert message to trunk anyway [14:16:26] because I don't have core access [14:16:27] indeed, not without backport [14:16:42] but I could create a ticket for that so someone would [14:38:25] @add #mediawiki-i18n [14:46:27] petan: thanks for SOLR , if you succedded with jenkins what is it's url? [14:46:54] no idea I need to properly set up proxy here [14:58:51] OrenBochman: hello :) [14:59:08] OrenBochman: I am reading a mail you sent to Sumana and mentioning Jenkins / Continuous integration [14:59:27] OrenBochman: I am the one in charge of Jenkins, so if you need anything there let me know :D [15:03:31] hashar: I think he talked about local installation of jenkins he has on labs [15:03:50] most probably [15:04:10] I don't have a big knowledge of that I hope you help him better than me [15:04:11] :D [15:04:40] or we can learn together! [15:10:07] or that :) [15:10:14] I have no idea what is actually jenkins for [15:10:26] !wiki [15:10:26] --elephant-- I don't know anything about "wiki". You might try: !1.17wmf1 !b !class !e !hook !mwbot !pad !rev [15:10:53] !wiki is http://en.wikipedia.org/wiki/`e1 [15:10:53] --elephant-- You don't have permission to do that. [15:10:58] :( [15:15:09] hi hashar [15:15:22] :) [15:15:32] I want to put search into jenkins [15:15:53] we can add a job to the existing one on http://integration.mediawiki.org/ci/ [15:16:03] I'd since it in java and has an ant build script it should be easy [15:16:27] hasar that would be great for the long term [15:16:30] that machine has both openjdk and the sunjdk installed [15:16:44] ant is 1.8 (1.7 can not be used) [15:17:51] I'd like to simply my development cycles so just bulding it is not enough - it would need to be able to access live wikis and dumps testing and benchmarking [15:18:45] OrenBochman: let me know about your plans on bigger wiki [15:18:55] we will need to talk to Ryan when he's here [15:19:29] petan I am thinking to replicate the search machines in labs [15:19:42] you wanted a full db of simple wiki? [15:20:00] no latest version is fine [15:20:05] ah ok... [15:20:12] I thought you talked about some cluster or what [15:20:18] yes [15:20:28] I'm trying to explain [15:21:49] what I will soon need is setup similar to production with machines indexing the real wikipedias with the index split on servral machines [15:22:01] ok [15:22:28] that would be possible but I think we should set up an sql server first Ryan has some plans but he didn't make a proposal yet [15:22:30] int that setup I don't need local db [15:22:49] I'll be glad to discuss with evryone [15:23:00] ok [15:23:05] I think it shouldn't be problem [15:23:26] biggest problem is storage apart of that it's ok [15:23:41] or that's what he said [15:23:45] now regarding a full db that indexer is a feature request and needs to be specified and developed (dev is easy) [15:24:07] but it is about a month away [15:24:32] it shouldn't be problem to create a full db import too, but let me know because it can take even few days to set up everything [15:24:44] ok [15:24:59] petan I'll give you a head start with that [15:25:09] import of latest rev is running since yesterday and still running but it's partially because I started it wrong [15:25:23] I should have wait for apergos [15:27:29] I am wondering if it would be possible to make a instance with lots of dbs (one per each language/script) with a about 1000 pages + the template namespace??? [15:28:00] yes [15:28:16] petan: when I imported wiktionary on a local machine and it took about 3 weeks [15:28:42] it shouldn't be problem but I want to discuss this with others before I mess it up again :) [15:28:52] no problem [15:29:27] sometimes I start working on stuff and after few hours someone tell me that if I started it in a different way it could be way more easy [15:29:32] hashar: could you help with the local jenkins instalation - on search ? [15:30:00] petan: it is the same with developing too [15:30:13] I am talking about developing :) [15:30:36] OrenBochman: maybe ;-) [15:30:54] hashar can I accss your jenkins ? [15:31:05] OrenBochman: yes [15:31:13] or I see you there in user list [15:31:13] :D [15:31:24] gues I should be [15:31:28] !jenkins [15:31:28] --elephant-- I don't know anything about "jenkins". [15:32:10] oh wait, no I don't see you [15:32:16] weird [15:32:33] probably someone need to insert you there, I guess hashar is right person for that :) [15:32:35] wo I;m in there already [15:32:41] ah [15:33:07] OrenBochman: https://integration.mediawiki.org/ci/ [15:33:16] maybe I see only people in same project then [15:33:16] yep I just logged in [15:33:19] if you have a lab account you should be able to identify yourself there [15:33:30] but you probably can't do that much there :D [15:34:28] hashar you need to install mave there [15:34:39] maven? [15:34:41] hashar you need to install maven there [15:34:43] yes [15:35:23] the current set up of search is in ant but I plan to move to maven [15:35:48] oh noooo [15:35:50] :-D [15:36:06] I have antlr grammers and other components that are more easy to do with maven [15:36:49] I can get maven installed, would need a list of libs to install too [15:37:03] ok [15:37:44] based on libmaven* package list for Ubuntu 10.04 (lucid) [15:38:19] if you have an email I'll drop you a note - I'll probably set things up on my local dev machine > then the labs > then your CI [15:38:39] I am wondering about one thing [15:39:11] mail: amusso at wikimedia dot org [15:51:48] OrenBochman: I have send basic changes to install Apache Maven in production [15:51:49] https://gerrit.wikimedia.org/r/#change,1768 [15:51:50] https://gerrit.wikimedia.org/r/#change,1769 [15:52:19] still need to add maven plugins though [16:22:34] *jeremyb looks up [16:25:59] OrenBochman: petan: i know a little (not a lot about how the search infra works. i know more about lucene itself (from another place where I did some hacking on an app that used lucene with a local index) but not so much about theoretical search stuff (e.g. lucene internals) [16:26:15] *jeremyb is mildly confused about why the convo is in this channel now? [19:01:50] hi all - features team - let's get started [19:02:02] Meeting Agenda: [19:02:02] 1. Brief (2-3 minutes) status update by each team for project teams listed below: [19:02:02] a. Editing tools: Visual Editor [Neil], Parser [Gabriel] [19:02:02] b. Editor Retention: Feedback Dashboard [Brandon, Benny, RobM], AFT v5 [Dario] [19:02:02] c. I18n: Narayam, WebFonts, Translate [Siebrand, Amir, Santhosh, Niklas, Gerard] [19:02:02] d. Multimedia: Upload Wizard, TMH [Ian] [19:02:02] e. Resource Loader / Gadget Manager [Timo] [19:02:03] f. Global Education [Jeroen] [19:02:03] g. Features Support (Deployments, Testing) [Roan, Timo] [19:02:04] h. Other projects [19:02:16] thanks for updating the etherpad [19:02:40] visual editor - neil - updates [19:03:00] you want me to reiterate what I wrote in the etherpad? [19:03:14] sure - highlights [19:04:19] * Refactored parser execution framework (was a bit intertwined with testing) [19:04:19] * Wrote parse.js "standalone" program. Wikitext stdin, Wikidom stdout. [19:04:19] * Wrote patch to grey out undo/redo when nothing to undo/redo (based on community patch) [19:04:38] ok, I'm trying to get to a state where the VisualEditor can request a wikidom parse of some article on the wiki [19:05:04] this will involve an API in MediaWiki, and a standalone parse service (you'll have to run node.js locally) [19:05:11] k [19:05:11] the standalone parse thing is done [19:05:33] conferring with Gabriel about redesigning the parse to be evented, I didn't manage to do it but he apparently just landed it this morning. [19:05:46] and, then I did a simple patch for VisualEditor gui related to undo/redo. [19:06:23] great! thanks [19:06:33] *werdna-holiday sneaks in late. [19:06:34] gabriel? [19:06:37] andrew! [19:06:39] hi werdna! [19:06:47] didn't work much last week [19:06:56] but got the refactoring finally checked in today [19:06:59] understandably :-) [19:07:03] andrew, were you the one who wrote the etherpad patch that fixed the padding and such? [19:07:08] so now we have async token transformations [19:07:18] gwicke: yay [19:07:19] Not I, said the little red hen [19:07:20] hopefully a good base for template expansion [19:07:33] will work with Neil on that [19:07:49] gwicke: thanks; looking forward to seeing you in sf :-) [19:07:52] there are still a few loose ends design-wise [19:08:06] but those should be tied up when it is used for templates etc [19:08:15] that's it from me for now [19:08:20] ok - thanks! [19:08:37] b. Editor Retention: Feedback Dashboard [Brandon, Benny, RobM], AFT v5 [Dario] [19:08:42] jorm: any updates [19:08:56] feedback on MAH? [19:09:02] Yeah, how IS the feedback dashboard? :) [19:09:15] well, we had a deployment. [19:09:22] it's pretty damned awesome, if i do say so myself. [19:09:23] werdna: we deployed last week on wednesday [19:09:29] Oooo [19:09:48] this latest deployment included a feature "Mark as Helpful", which allows people to say whther or not the responses they got were useful. [19:09:50] jorm: any interesting community feedback you've seen [19:10:01] it's been dead. everyone's been partying. [19:10:01] That's awesome. [19:10:10] so the volume has been down. [19:10:10] but [19:10:17] the feature is well receieved. [19:10:29] that could just mean that the trolls haven't seen it yet. [19:10:31] evening [19:10:43] right - the trolls haven't arrived yet [19:10:55] we have an office hours for features tomorrow [19:10:56] Hi Nikerabbit [19:11:04] on irc [19:11:17] so all of you are welcome to join [19:11:22] What time? [19:11:38] 3p-4p PST [19:11:53] Oh ,right [19:11:57] The midnight office hours :) [19:12:01] bsitu: anything else to add [19:12:09] Added clicktrackng to feedback response email [19:12:12] tomorrow? [19:12:15] *werdna-holiday is lucky enough to be in PST at the moment, but I'll probably be away from wifi then [19:12:18] Roan:the midnight office hours for you [19:12:24] jorm: yes [19:12:33] k. [19:12:43] i have an interview just before then but that'll be okay. [19:12:44] bsitu: did legal clear this? [19:12:50] we will be doing a features office hours once every month [19:13:06] howief: dario did talk with legal [19:13:08] howief: I got greenlight from dario so I assumed it gets cleared [19:13:15] awesome! [19:13:20] howief: it is cleared [19:13:31] What're the next steps for FBD? [19:13:32] last week, I also added page display rule to 'mark as helpful' [19:13:38] Do you want help? [19:13:47] i'm curious to hear how you implemented this. I'll follow up with you guys separately. [19:14:14] howief: yup - we should be meeting on this today at 430-5p PST [19:14:24] robm: anything else to add? [19:14:56] Not much, just that we came across some things to add in this week to MAH in regards to page rules and whatnot [19:15:10] MAH? [19:15:15] alolita, legal cleared the use of clicktracking as we planned to implement it now, for more granular data collection we will need to have a full review with them [19:15:22] werdna-holiday: mah = mark as helpful [19:15:30] Aha, thx [19:15:32] werdna-holiday: MarkAsHelpful, as opposed to Mark A. Hershberger [19:15:47] Yeah, that's what confused me. I thought we were adding features to mark [19:16:01] Like, extra beards or something [19:16:18] werdna: :-) [19:16:47] hexmode does not need more beard. [19:16:48] howief, dartar: anything else on aftv5 [19:17:08] I have just committed a fix for the clicktracking data format [19:17:08] someone is giving away beard? [19:17:17] so aftv5 [19:17:21] And I'll get Dario some dumps of that today [19:17:29] RoanKattouw: thanks! [19:17:33] the big thing is to get the links to the feedback widget more prominently displayed [19:17:33] yeah, as noted in the etherpad: we expanded the sample of cherry-picked articles and this week will work on doubling the random sample [19:17:37] RoanKattouw: awesome [19:17:46] RoanKattouw: Mark A Hershberger is marked as helpful :P [19:17:53] haha [19:18:00] *hexmode goes radio silent again [19:18:03] I got a few compliments on AFT from random strangers while I was away, by the way. Nice work! [19:18:18] werdna-holiday: that's cool [19:18:20] what did they say? [19:18:24] howief: nice work indeed [19:18:25] on aft? [19:18:30] Just that they thought it was a fantastic idea [19:18:37] cool [19:18:43] RoanKattouw: I'd like to test the accuracy of the AFT5 random bucketing on a sample of users as we discussed last week if you can help with this [19:18:45] werdna: good to hear that [19:18:56] DarTar: Right, that too [19:19:12] DarTar: Tomorrow, if that's OK with you [19:19:17] sounds good [19:19:26] DarTar: anything else to cover? [19:19:37] c. I18n: Narayam, WebFonts, Translate [Siebrand, Amir, Santhosh, Niklas, Gerard] [19:19:51] I worked further on the toolserver dashboard/feedback stream for AFT [19:20:05] as noted in the etherpad ;) [19:20:14] DarTar: great thanks! aharoni, nikerabbit: updates? [19:20:27] Hallo [19:20:34] hi amir [19:20:57] Translate extension: [19:21:02] Translate workflow states are now displayed in language and message groups statistics pages. [19:21:27] *werdna-holiday has to disappear. Back hopefully in 15 mins or so. [19:21:39] Next week i plan to complete the current "workflow states", er, roadmap, by making the state names discoverable and localizable. [19:21:40] bye werdna [19:22:04] aharoni: great, thanks [19:22:12] The extension's documentation is being improved. [19:22:28] "Review recent translations" feature was added. [19:22:33] (by Niklas) [19:22:46] nikerabbit: good stuff! [19:22:55] deployed yet? [19:23:38] deployed only on translatewiki.net, and not completely reviewed yet (i hope to finish the review today, it's quite big) [19:24:00] aharoni: are you covering for santhosh also [19:24:11] i'm trying :) [19:24:17] :-) [19:24:50] so Santhosh has been working mostly on integrating and testing gender support in JavaScript, but nikerabbit can update about this better. [19:25:15] ok, nikerabbit: ? [19:25:54] Santhosh has also been trying to make mediawiki.feedback.js useful for sending feedback about WebFonts. [19:26:23] neilk: did you have a chance to look at the ongoing gender support discussion on bugzilla [19:26:56] hmm [19:26:59] nikerabbit: ? [19:27:14] alolita: Krinkle, RoanKattouw and I are going deep into the weeds there :) [19:27:27] well our JS plural and gender work is a bit open now that RoanKattouw said he wants to have the main work done serverside [19:27:45] neilk: that's normal :D i'll catchup on that thread [19:27:56] I talked to Tim about that earlier today [19:28:00] alolita, Nikerabbit: that's what I have always wanted too, but our parser is difficult to instrument. He demonstrated a way to do it that *might* work. [19:28:11] RoanKattouw: ok, what did Tim say [19:28:27] RoanKattouw: is it likely that we can make happen together this week? [19:28:31] or should we take that offline [19:28:33] Well, probably not [19:28:51] We should probably just go forward with the existing client-side parser, it works fine [19:28:54] the question to me is, does the i18n team need to care how it's implemented [19:28:55] yeah [19:28:59] we can refactor it later [19:29:09] that sounds like a plan [19:29:10] RoanKattouw: i agree with that strategy [19:29:14] the client side cost is minimal, although the whole thing is inelegant [19:29:34] Doing things server-side would be Better (TM) (although Brion seems to disagree on wikitech-l just now), but not required [19:29:44] neilk: understood [19:29:47] oh wait, there's a thread?! [19:30:03] Not very substantial [19:30:09] [Wikitech-l] Plural, Gender parsing support for interface messages at client side [19:30:11] It was next in my queue I see it now. [19:30:15] I'm writing a reply to Brion now [19:30:20] reading it now [19:30:26] I'll also include my plan for server-side processing [19:30:36] Which is entirely different from what I showed you last night [19:30:59] alolita: we might have a larger feature deployment next week, depending on how stable we get things [19:31:16] nikerabbit: that makes sense [19:31:29] and not this week [19:31:49] yeah this week is definitely too early for Translate at least [19:31:57] *brion waves [19:32:08] server-side processing is easier in some ways yes :D [19:32:12] nikerabbit: no worries; lets do it next week during our standard window [19:32:16] brion: hi! [19:32:51] nikerabbit: anything else to add [19:33:21] else we move on to Multimedia: Upload Wizard, TMH [Ian] [19:33:26] alolita: I think we covered the most important things [19:33:34] raindrift is sick/WFH today [19:33:39] raindrift = Ian [19:33:45] nikerabbit: that works - thanks! [19:34:09] neilk: ok i guess he is not on irc - he is wfh [19:34:12] The last thing I heard was that we finally had a working chunked upload protocol with tests and stuff. [19:34:26] neilk: thanks - appreciate the update [19:34:32] We requested a review from Tim [19:34:43] great [19:35:09] there are a number of fixes piling up with UW over December, so I'm going to deploy right after Pacific time lunch, instead of 4:00pm friday, which is when Erik wanted me to deploy :) [19:35:19] (4:00pm last friday I mean) [19:35:49] neilk: no worries .... let's push these fixes this week ... today [19:35:56] we can deploy it without turning on Chunked uploading. THere's a config flag. [19:36:06] yup [19:36:07] as for TMH, I'm not sure what the status is. [19:36:24] I think that's fully reviewed by now. [19:36:38] yes - that's what ian mentioned [19:36:58] so let's move on to the resource loader - RoanKattouw, Krinkle [19:37:08] progress: ? :-) [19:37:10] neilk_: You guys got TMH reviewed before the end of the world as predicted by the Mayans? I'm impressed [19:37:14] So, ResourceLoader [19:37:27] I was poking at the server-side message loading thing, which I'm writing a wikitech-l post about right nwo [19:37:42] RoanKattouw: which means there is hope for the world? [19:37:47] My plan touches ResourceLoader code [19:38:08] RoanKattouw: what are we talking about here, server side message parsing to wikidom? [19:38:13] RoanKattouw: or something else [19:38:15] Sort of, yeah [19:38:17] I'll write a post about it [19:38:32] yeah, I noticed you used a wikidomish format which perhaps makes sense [19:38:32] Aside from that, I should pick up where I left off with my RL2 work [19:38:36] how does it affect RL code [19:38:40] Which is writing unit tests, mostly [19:38:50] RL does message delivery to the client [19:39:20] My plan would add a processing phase on the server, then the processed message would be delivered to JS, where expansion would happen [19:39:36] Changing the nature of what's being delivered means I have to change the delivery code [19:39:44] Not very substantially, but not trivially either [19:39:57] RoanKattouw, sounds good. (just sent a reply on-list -- we should be able to work with that for the mobile app) [19:39:58] right and you would be storing JSON not strings [19:40:12] caching that is [19:40:15] Right [19:40:32] siebrand: Online already? [19:40:47] So yeah, there's RL2 work to be done [19:41:01] I need to get back into that game and see what the State of the Project is there [19:41:17] RoanKattouw: yup and update / add more detail to your plan on mw.org [19:41:43] And I think Krinkle (not here?) is working on a RLv1 issue locally [19:42:00] RoanKattouw: can't see him online [19:42:03] But he's had close to no time off from his internship for the holidays, so he's busy as ever [19:42:12] wow [19:42:27] this internship is making him work hard [19:42:51] If he'd been in classes, he would've had last week and this week off [19:42:55] RoanKattouw: are you done moving [19:42:58] I was hoping to capitalize on that this week [19:43:00] Yes [19:43:03] cool [19:43:17] I'm working normally starting today [19:43:21] for as long as that lasts [19:43:28] (9 days) [19:43:30] great :-) anything else to add else moving on to jeroen (if he's around) [19:43:37] yup lots of traveling coming up [19:43:55] presentation ready for lca? [19:44:18] No, I'll contact Trevor about that today [19:44:25] I was hoping to do that this week while Trevor's on vacator [19:44:26] *vacation [19:44:36] something to celebrate: http://windowsteamblog.com/ie/b/ie/archive/2012/01/03/the-us-says-goodbye-to-ie6.aspx [19:44:36] ok thanks; [19:44:38] He seemed prepared to do that, although he was adamant about not coming into the office :) [19:45:19] jeroen: you around? [19:45:41] RoanKattouw: anything else to add on deployments [19:45:44] code review [19:46:10] Things are happening as normal [19:46:18] I guess I need to start doing CR for MB&MAH again [19:46:24] Cause there's a window tomorrow [19:46:35] RoanKattouw: yup , thanks for the update [19:46:54] any questions? [19:47:16] guess we're all cool [19:47:35] Announcements [19:48:04] I'm offically graduating in few months [19:48:13] Reminding the features team - we need to do our 20% to help keep the code review backlog in shape [19:48:15] Sweet! [19:48:19] nikerabbit: yay!! [19:48:34] leaving my thesis for official inspection this week, finally [19:48:42] so please use your day to do bug fixes, code reviews [19:48:50] Upcoming Events: [19:48:57] where the features team is participating [19:49:05] Linux.conf.au: Jan 16-19 [Trevor, Roan] [19:49:07] Nikerabbit: that will be a relief I guess ;) [19:49:14] SF Hackathon: Jan 20-12 [SF team, Gabriel, Jeroen] [19:49:22] *20-21 [19:49:22] FOSDEM: Feb 3-5 [19:49:33] Roan: thanks - fixed [19:49:43] Pune Hackathon: Feb 10-12 [19:50:09] CFPs open now: GNUnify, Pune and OSCON, Portland [19:50:19] submit your talks [19:50:34] niklas: reminder for the w3c conference [19:50:51] Reminder: Vacation Plans: Please email me with your planned vacation requests at least 1 week before you take it. [19:51:13] I think we're done otherwise on our agenda items [19:51:26] any other questions, issues ? [19:51:49] i guess we're done then :-) thanks for joining - until next week [19:52:18] see you on Monday in SF ;) [19:52:34] gwicke: see you! [19:54:00] gwicke: looking forward to it [19:54:17] me too [19:54:43] neilk_: do you have some time to chat about the parser stuff? [19:54:50] gwicke: yeah let's [19:54:57] I was reviewing the last change [19:55:06] hehe [19:55:10] a bit longish [19:55:19] is it worth it to do a walkthrough? [19:55:20] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107921 [19:55:54] it seems to me that despite the docs you've made, I still can't contribute meaningfully to the guts [19:55:56] let's go through it roughly [19:56:03] might be my problem [19:56:14] most of it is concerned about async buffering and callback chain management [19:56:23] and the phased transformation dispatching [19:56:55] ok, so what we want is to begin parsing an article as tokens are received, but to send back a completed treebuilder tree only when it's done [19:56:59] the ParserThingy looks a bit tidier now, but is not yet fully evented [19:57:09] gwicke: very much [19:57:36] neilk_: right now the pipeline is started by calling the tokenizer [19:57:42] yes [19:57:54] which used to take a big callback [19:57:57] alolita: were I supposed to book the tickets myself? [19:58:13] but it all still assumes that all tokens are processed synchronously [19:58:22] nikerabbit: for w3c - yes [19:58:27] what is rank for [19:58:27] and reimburse [19:58:28] but that will change very soon, with templates [19:58:41] alolita: will do [19:58:49] is the idea that you register handlers to hooks which have a rank [19:58:49] nikerabbit: its faster and easier for you [19:58:50] for that, we need to push the event chain further along [19:59:10] neilk_: yes, the rank determines the order and processing phase [19:59:18] k [19:59:33] i'm not sure why we need the concept of rank and phase, unless it's for ordering within a phase? [20:00:02] rank does both, but we could also split it if that is easier to understand [20:00:14] ok [20:00:26] basically 0..1 is in-order on input tokens [20:00:30] 1..2 is async [20:00:37] ah I see [20:00:41] 2..3 is in-order on output token stream [20:00:56] just the phases in the docs [20:01:11] makes sense [20:01:35] anyway that works for now [20:02:24] there are two big work areas currently: token stream transformations and making the top-level chain fully evented [20:02:55] perhaps I can work more usefully on the latter [20:03:03] I see you are now inheriting from EventEmitter [20:03:06] the latter is partly done, but needs to be pushed all the way to parser tests etc [20:03:24] the inheritance is a bit broken though [20:03:37] we should use extend instead afaik [20:04:04] to avoid polluting the EventEmitter prototype [20:04:11] ? [20:04:33] you are doing inheritance via prototype = object [20:04:39] there's no pollution that way [20:05:02] hrm- I would think that modifications to the prototype affect the object [20:05:24] and tracebacks I got while debugging seem to support that [20:05:38] but that should be relatively simple to check [20:06:42] anyway, that is not really a big issue [20:06:54] but for async stuff to work, it all needs to be async [20:07:14] that's the big downside in node, IMO [20:07:23] gwicke: just tested, no they do not pollute original prototype. Anyway. [20:07:43] ok, that is good [20:08:07] I got a traceback, where one of my internal methods was listed as method of EventEmitter [20:08:18] so I figured there might be pollution [20:09:40] so we need to make the parser and event emitter, and register the last part of parse() and getWikiDom() with it in an event chain [20:09:59] s/ the parser and event/ the parser an event/ [20:10:27] and then so on into parser tests or the network wrapper [20:13:42] the treeBuilder already emits the 'end' event, so you could take it from there if you want [20:13:47] gwicke: maybe I need to zoom out a bit here [20:14:03] gwicke: I'm thinking that the end stage of making this evented looks like this: [20:14:17] gwicke: we make a number of objects, configred. [20:14:32] gwicke: then we put them into some structure which makes a pipeline. [20:14:51] that is already done in the constructor [20:14:57] kind of yes [20:15:30] the pipeline extends all through your program unfortunately [20:15:49] well, it may be premature to boil it down to a simpler interface atm [20:16:05] unless we run it in webworkers or the like [20:17:05] I think you hope to contain the async callback chain in an async island [20:17:33] not necessarily [20:18:15] https://github.com/creationix/step [20:18:40] step is a framework that can handle parallelism and sequentialism with relative ease [20:19:30] hrm- and you have a sequential thread on the outside? [20:20:07] it would depend [20:20:24] would surprise me if that was possible in a JS runtime [20:20:28] probably it's best to use step at the highest level, because you can't have a sequential thread waiting for async. [20:20:30] apart from webworkers [20:20:35] no, it's not. [20:20:56] well, there sort of is a way, but it's not implemented in V8 -- yield() [20:20:59] but we digress [20:21:45] basically, we are working in a relatively impoverished environment [20:22:11] well, what is the model you would really like -- threads? [20:22:41] I like the Haskell toolbox really [20:22:45] haha [20:22:47] well [20:22:50] message passing, STM etc [20:23:03] and nice userspace threads with event loop in the background [20:23:20] basically node with a lot of nice things on top.. [20:23:22] ok, I agree everything is impoverished relative to Haskell [20:24:12] the async stuff I just wrote does something similar to step [20:24:15] Haskell essentially removes the difference between math and programming, so of course :) [20:24:23] anyway, my vision here was that we'd have a framework wrapping up a lot of processes that were individually async -- that's the way to do it in JS, and still have a pipeline that doesn't make you want to claw your eyes out. [20:24:37] except that it is a bit more specialized for buffering and expansions-at-any-time [20:25:03] everyone who writes JS ends up doing a library like this :) [20:25:38] but, if we have a consistent interface, then we can reason about errors and so on in a non-insane manner. For instance, exception handling in JS async just does not work [20:27:06] that sounds very general [20:27:23] right now we have events between stages [20:27:54] my thinking here might not be clear enough yet. [20:27:56] and specialized stuff for token stream processing [20:28:31] the specialized stuff is all encapsulated within TokenTransformDispatcher [20:28:54] so to the outside, it looks like an event consumer and -emitter, nothing else [20:29:31] I think I have to go now [20:29:47] I'm not sure that I'm offering anything constructive -- I should review this code more and reread your design notes [20:29:59] ttyl? [20:30:13] I'll be on the phone in the next half hour or so [20:30:21] but after that maybe [20:30:33] well I mean generally later -- it's very late for you [20:30:38] by email [20:30:46] yeah, sure [20:31:02] will be on IRC tomorrow as well [20:31:12] okay, till then [20:31:14] see you later! [20:57:46] hashar: pign [20:58:02] pong [20:58:06] Krinkle: pong [20:58:22] so as you've probably noticed, our primary testswarm install has been buggy lately [20:58:38] I know why, but as I don't have access I can't fix it [20:58:53] There is an invalid row in the jobs or runs database table [20:59:05] probably from when we were testing [20:59:19] since it is the oldest, it is ran last. But it can never complete because it has an invalid URL [20:59:29] so whenever it comes up the client hangs for ever [20:59:38] and then the client will never refresh again [20:59:53] also contains upstream issue (client should recover) - but we can fix our invalid row. [20:59:55] can you do so please ? [21:00:16] a few SELECT queries will pinpoint them problematic rows, then just DELETE them. [21:01:15] sure [21:01:18] let me finish a bug report [21:03:17] Krinkle: sorry for going AFK earlier. Really had to take care of my daughter at home :/ [21:03:25] np, had to go myself [21:03:32] just got back now [21:04:50] I am on the db :D [21:06:30] ok [21:06:39] I had to drop some old jobs id [21:06:45] not sure I dropped them cleanly though :( [21:07:21] I know the db from the top of my head. [21:07:28] what did you remove ? [21:08:13] (or just dump the query here) [21:08:16] jobs iirc [21:08:22] but that was like 2 weeks ago [21:08:33] oh [21:09:34] I am not sure from where the clients fetch their changes [21:09:37] well, every job has a number of runs [21:09:58] and runs each have several user agents that need it needs to run in [21:10:04] so just removing a row from 'jobs' is harmful. [21:10:18] that is probably what I did [21:10:42] table runs has a reference to job_id, and table run_useragent has link to run_id [21:11:16] hashar: okay, there's about 10 queries we need to do to fix this. but there may be an easier solution [21:11:44] hashar: since TestSwarm doesn't have a proper "updater" (jQuery's install is updated by nuking DB and reinstalling from testswarm.sql) [21:11:53] can't i just drop row in 'runs' where job_id do not exist ? [21:11:58] how about we take this opportunity to update it to the latest HEAD ? [21:12:10] cant do that :D [21:12:13] hashar: sure, but also remove run_useragent where no run ID [21:12:21] hashar: why not [21:12:21] we need upstream to tag a release in github [21:12:25] okay, I'll do that [21:12:36] then we could update the debian package using debian tools [21:12:44] (something like uupdate) [21:13:13] the package will be something like testswarm-v0.2.0.deb that we could then test on the VM and upload to apt [21:13:32] I need to describe that full process though [21:13:40] 0.1.1 is ok ? [21:13:50] yeah [21:14:01] no new things were added. Just more user agents etc. [21:14:05] but will never be deployed this evenbut it is not going to be deployed this evening :D [21:14:09] oh [21:14:12] and updating which are "active" and which are "beta" [21:14:21] I can update the useragents by altering the db manually [21:14:21] we don't need to update. If you can nuke the live db and reinstall, that's ok too. [21:14:26] did so already to add some firefox / opera [21:14:43] or we can do the manual thingies in runs and run_useragent [21:14:47] whatever you want [21:15:04] but we might as well update everything, why not ? [21:15:05] the problem with wiping the useragent table, is that we need to wipe all the rest [21:15:12] yes, I mean everything [21:15:26] it doesn't matter afaik, it's all green right now. No unfixed stuff. [21:15:54] and will also speed it up a bit since it's fairly inefficient anyway [21:17:25] hashar: so, what do you want to do ? to avoid doing something that isn't needed. [21:17:47] here is the useragent table: http://dpaste.org/fsTa1/ [21:17:50] we need to do something as right now nobody can connect to the swarm without being disconnected after a few minutes when a few tests are done. [21:18:22] about the runs, I think the easiest is to wipe the old runs with no jobs [21:18:27] ok [21:18:44] so delete runs where run_id not in jobs, and then delete run_useragent where run_id not in runs. [21:19:09] !r r107919 [21:19:09] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/r107919 [21:19:25] that broke some unit tests [21:20:29] oh, right. [21:21:28] ok run deleted :D [21:22:00] okay, we'll find out in a few minutes if it fixed the problem [21:22:34] run_useragent still has all the old runs though [21:22:50] run_useragent is the one the client gets data from [21:23:21] it checks if there are unrun runs for the current user agent, and if so it retrieves the run/job info. [21:24:28] select distinct min(id) from runs; => 3174 [21:24:38] select count(*) from run_useragent where run_id < 3174; => 43187 (out of 126000) [21:25:04] hm???. is that safe ? [21:25:24] no idea :-D [21:25:25] oh it has MIN() [21:25:31] yeah, should be fine [21:25:41] Isn't there an "IN" syntax ? [21:25:41] but it looks like those 43187 rows can be dropped [21:26:02] DELETE FROM run_useragent WHERE run_id NOT IN ( ???.. runs ???.. ) [21:26:06] something like that [21:26:23] or that one join and check null [21:26:27] I always forget which join [21:27:01] well DELETE FROM t1 JOIN T2 WHERE t1.id=t2.id AND t2.id=3000 [21:27:04] something like that [21:28:00] deleted them [21:28:18] DELETE from run_useragent WHERE run_id < 3174; [21:28:18] Query OK, 43187 rows affected (0.70 sec) [21:28:55] "DELETE FROM t1 JOIN T2 WHERE t1.id=t2.id AND t2.id=3000" isn't that just "DELETE FROM t1 WHERE id=3000;" ? [21:29:01] deletes one rwo [21:29:29] just pretend the last is t2.username [21:29:35] DELETE FROM t1 JOIN T2 WHERE t1.id=t2.id AND t2.username='Krinkle' [21:30:21] don't know what that is supposed to do [21:30:53] think about T1 having blog posts written by users [21:31:10] user being referenced by an ID there [21:31:29] you want to deleted all blog posts written by a given USERNAME. The ID - USERNAME is stocked in T2 [21:31:32] or: [21:31:40] Yes [21:32:06] Yes, then that query makes sense [21:32:18] DELETE FROM posts JOIN authors WHERE posts.author_id=authors.id AND authors.name = 'krinkle'; [21:32:49] yep [21:33:04] it is also possible to delete 'posts' for which the author_id is not found in authors [21:33:22] but I never remember how to do it so I have to look it up [21:33:52] LEFT JOIN and IS NULL ? [21:34:10] DELETE FROM posts LEFT JOIN authors ON posts.author_id = authors.id WHERE authors.name IS NULL; perhaps? [21:35:00] yup something like that [21:35:51] thanks RoanKattouw ! [21:36:27] AHHHH [21:36:40] Huh, that query was for deleting posts of which no author exists ? [21:36:52] yeah :) [21:36:55] I thought you were trying to explain something else [21:36:59] the join with null makes sense [21:37:10] I learned that from Roan probably :D [21:37:13] because I manually deleted some authors :D [21:37:18] and forgot to remove their posts [21:37:35] hacking on fenari from SF at 8pm [21:37:58] some category tree bug if I recall correctly [21:38:20] hehe [21:38:34] Oh, speaking of SF, I learned about something atrocious today [21:38:39] Krinkle: testswarm is still submitting jobs against the HTML test suite [21:38:48] That restaurant I was talking about earlier, Flames, was closed for a while, remember? [21:38:55] hashar: yes, of course [21:39:00] that's good [21:39:01] Apparently it changed owners and has now become some crappy gyros place [21:39:06] Krinkle: in trunk, two tests are failing cause of the config change ... [21:39:14] I know, I said that 30 minutes ago, Im working on it [21:39:21] I am not sure there is anything we can do [21:39:23] I forgot to keep backwards compatibility [21:39:26] we can, it's easy [21:39:32] \o/ [21:39:49] sorry, did not pay attention earlier :( [21:39:51] that was the whole point, otherwise we should've kept the branch separate as the special page is untested with testswarm. [21:39:52] np [21:39:57] I was asking three things at once [21:40:57] ahhh [21:42:05] when merging I only took care of [[Special:JavaScriptTest/qunit]] [21:42:19] Krinkle: shouldn't we drop the .html suite [21:42:21] ? [21:42:40] no [21:42:47] not until after the special page is tested and worked [21:42:54] within testswarm [21:43:16] it says that .html is going away soon everywhere in the code [21:43:22] somewhere [21:43:30] fine [21:49:45] testing now in browserstack to make sure [21:50:18] *Krinkle loves BrowserStack, easy to set up localhost tunnel to the VM, all inside the browser [21:52:10] http://i.imgur.com/yAnib.png [21:52:57] Krinkle.browserstack.com is set up as a local hosts-file thing when entering the VM pointing to their proxy server [21:54:41] looks great for testing :D [21:54:54] you even have firebug \O/ [21:55:32] thanks for the test fix r107946. Will have a look at it tomorrow [21:55:50] yeah, it's got it pretty goot [21:55:52] and hack around to add a new job submitter [21:56:49] basically a copy of the current submitter, except for the URL part, that should start with /w/index.php/Special:JavaScriptTest/qunit/?module= instead of /tests/qunit/index.html?module= [21:57:24] perhaps even use the existing submitter so that we don't need two checkouts, makes sense as the submitter that installs etc. is made for this, the static thing doesn't need the php/database [21:57:45] hashar: Can you do one other thing in the submitter ? Include in the job name so that it can link to CR on mw.org [21:57:54] it's raw html [21:57:54] ohh [21:58:12] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/$1">$1 or something like that [21:59:20] I have sent myself a reminder :D [21:59:24] cool [21:59:48] night time now :) [21:59:51] see you later! [22:32:10] brion: btw, I remember something about wmf having a deal with one of the cross-browser vm sites out there, correct ? [22:32:20] I've got an account via jQuery team on browserstack.com: http://i.imgur.com/yAnib.png [22:32:26] something, i don't recall details [22:33:02] *Krinkle likes that a lot [22:33:19] comes with proper debugging tools in all browsers [22:33:54] and VMs start swiftly and have limited OS access, although still a sample directory for uploading/downloading files and instant re-born on disconnect [22:34:11] on vm per browser per os. [22:37:10] ah, wmf is with CrossBrowserTesting.com [22:37:55] hm.. preliminary demo shows me it's less advanced. Just plain VMs for each customer with full OS access and starting browsers manually, no dev tools that I can see. [22:38:02] not sure how the pricing compares though [22:38:51] Krinkle, sounds nice! [22:39:01] main thing we need is for them to sit around churning tests i suppose [22:39:17] though full dev tools is nice if people don't have VMs handy for fixing problems [22:40:13] well, browserstack.com is more advanced in that every user in an organization can create sessions at will. and for each session one can choose OS/browser/resolution/and optional tunnel to local server and it is created on the fly [22:40:31] downside: disconnected after 5 minutes of inactivity and my browser needs to stay open [22:40:41] eek [22:40:48] it's for testing by developers [22:40:48] yeah that's not ideal for testswarm :D [22:40:55] no, that's not it's intention either [22:41:15] but hold on, the point of testswarm is that we don't need to do this ourselves [22:41:36] although it may be too much to expect that the community will have sufficient clients open, it's worth a shot. [22:41:46] just devs keeping a tab open in a browser here and there [22:42:13] main prob is keeping oldish browsers in the set :) [22:42:24] yeah [22:43:03] browsers tend to auto-upgrade and kill their siblings at arrival [22:44:55] brion: but since testswarm clients mostly maintain themselves (thats a high priority for the testwarm, clients should be unable to crash and survive connection drops) - all we need is a few VMs that open browsers on startup and testswarm as homepage. [22:45:05] should be much easier to maintain that Grid was. [22:45:22] yep [22:50:32] brion: Reedy Hm.. we've got Testing infrastructure and Continuous integration in our BugZilla's Wikimedia product now. [22:50:35] eh ? [22:50:58] yup [22:51:06] one isn't needed, right? [22:53:10] only 2 bugs [22:53:11] The component Continuous Integration has been deleted. [22:53:17] CC-list merged