[00:00:11] Well, YAML parsing in JS isn't as easy as XML parsing [00:00:22] XML parsing comes for free, and we can use jQuery to traverse it [00:00:33] Actually, I assumed the parsing would happen in PHP... [00:00:38] XML parsing is also free in PHP using SimpleXML or whatever [00:00:47] it has to be able to happen in both places [00:00:55] in fact, it's more likely to happen on the client side [00:01:00] that's where the UI is being built [00:01:00] Why is that? [00:01:08] less load on the servers =) [00:01:24] The problem with parsing via Javascript is that it can't be extended, by extensions. [00:01:34] why build it on the server side and send HTML when you can send the XML to the client and the UI can be build around it [00:01:43] the whole time, understanding what it's building [00:01:58] not true [00:02:13] Oh, really? [00:02:20] you used even hooks in js, just like in PHP [00:02:22] *use [00:02:24] sure [00:02:33] we do it all the time [00:02:55] Oh - I asked someone else about it, who said it couldn't be done. [00:02:59] I won't name names. :) [00:03:21] ok - well you can totally do it, and we build APIs into our javascript code for exactly that reason [00:03:31] Is there an example I can see of a hook being registered in JS? [00:03:39] sure [00:03:57] http://prototype.wikimedia.org/en-wp/extensions/UsabilityInitiative/EditToolbar/EditToolbar.js?47 [00:04:30] we provide plugins with other script includes [00:04:59] and we use this script - which is provided by a MediaWiki Extension to actually use them and hook them into the document [00:05:32] Oh, how interesting. [00:05:46] http://jquery.com/ [00:05:59] it's not just a library, it's a design pattern [00:06:18] it's an alternative way of working with the dom and scripts [00:06:18] Okay... [00:06:23] Fine... [00:06:28] :) [00:06:40] Are you trying to sell me on jQuery? :) [00:06:51] the concept is, the dom IS the state - rather than trying to store the state in some javascript world object [00:07:05] Yeah, that part I know. [00:07:28] I don't really care if you love or hate jQuery, I'm just saying - we need XML not YAML or WikiFormatX or INI or whatever else these yahoos are suggesting [00:07:58] Their input is welcome and appreciated - but also measured against reality [00:08:10] Right, that makes sense (about XML being preferable). [00:08:42] right on [00:08:46] so - what else came up? [00:09:00] i18n can be optional, XML is a must.... [00:09:10] any other loose ends? [00:09:11] So basically, it seems like that entire email discussion produced no helpful ideas whatsoever. :) [00:09:29] Don't worry, thats normal [00:09:32] which list was that on? [00:09:34] 100 or so messages' worth. [00:09:38] wikitech-l. [00:09:42] :) [00:10:05] Well, the big remaining issue, I think, is nested template calls. [00:10:18] ok [00:10:34] Any further thoughts? [00:10:57] so, we should initially say that if a value of a template parameter is a template call, we will let it be plain text - overriding the "type" of the field [00:11:26] Hm - I guess that works. [00:11:40] in the future, we can make a special control that allows editing of that template call just the same way the parent call is being edited [00:12:20] so we would essentially open it up to infinite nesting [00:12:23] evil sounding [00:12:25] but possible [00:12:30] we could also make a limit of course [00:12:31] Well, I'm against that idea, but if it's reserved as a future possibility then it's fine. [00:12:41] understood [00:13:10] i gotta get going now [00:13:14] my wife came to get me :) [00:13:17] Alright. [00:13:27] I should log on here earlier in the day. [00:13:36] Talk to you later! [00:13:38] we are deploying and responding to major bugs in the next couple days [00:13:43] Ah, okay. [00:13:56] then we can focus more on Citron - part of which includes your work [00:14:04] :) [00:14:06] ok - cya [00:17:53] hm [00:18:10] ok well then i'd better not deploy updates [18:12:55] TrevorParscal: You guys ready to try updating UsabilityInitiative live? :D [18:13:08] sure [18:13:52] ok lemme poke [18:20:25] TrevorParscal: or RoanKattouw_away where's that list of which opts we have to switch on again? [18:22:19] was it wgNavigableTOCUserEnable and wgEditToolbarCGDUserEnable ? [18:22:34] dang it, I'm looking for that page now [18:22:40] hehe [18:24:10] http://wikitech.wikimedia.org/view/Babaco_deployment [18:24:38] thunderbird's mail search is just plain crap [18:24:54] the page existence check in the link dialog is insanely slow for me [18:25:07] that might just be from git-svn in the background though :D [18:25:11] tx [18:25:22] hmm [18:25:44] well i guess the delay could be set higher [18:25:53] right now I think it's pretty short [18:27:06] ok and to enable navigable toc that's a separate include right? [18:27:15] yes [18:28:28] require_once( "$IP/extensions/UsabilityInitiative/NavigableTOC/NavigableTOC.php" ); [18:28:36] testing quick... [18:30:07] they seem at least functional [18:30:22] navigabletoc still seems to give me a really big slowdown on typing though (in ff 3.5) [18:33:38] ok let's check it on test [18:33:49] ok need to add to the extension list thingy [18:34:14] we have a delayed bind thing goin on [18:34:31] but tuning it is probably going to take some fiddling [18:34:47] hmm [18:35:00] well, yeah - there's more we could do in a delayed way as well [18:35:10] patches for performance will come in the next week I'm sure [18:38:30] ok it's updated :D [18:38:38] lookin [18:38:40] give er a whirl [18:39:09]

[18:39:14] i18n issue? [18:39:44] hrmmmmm still? *stab* [18:40:22] werdna: other than updating the extensions-list file do we still need to do something else? [18:40:24] or do i need to touch it again? [18:40:44] this patch http://www.mediawiki.org/wiki/Special:Code/MediaWiki/57160 never made it into the instructions to you [18:41:01] but it would be nice to have whenever we can do it [18:41:17] we didn't want to give you more crap to do while things weren't working out well for you :) [18:41:27] TrevorParscal: it's from yesterday and i just merged to current [18:41:27] so i assume it's in there? [18:41:36] sorry if this is annoyingly late notice of a patch, but it's purely aesthetic [18:41:47] hmm [18:41:56] ha [18:41:57] ok [18:41:59] nevermind [18:42:04] shift+refresh [18:42:06] :) [18:42:08] \o/ [18:42:38] OMG!! [18:45:47] brion: I'm here again [18:45:52] brion: you have to scap [18:46:11] brion: and during scap it runs mergeMessagesFiles.php or something from maintenance/ [18:46:12] NTOC working great [18:46:55] (i.e. running a scap will do the regeneration for you) [18:47:53] ok so i guess not [18:47:55] cause i ran scap [18:48:05] unless it needs another tweak to the extensions list file? [18:48:31] what extension is it? [18:49:24] UsabilityInitiative? Isn't that already in the list? [18:50:13] * Usage: Inlcude the modules you want to use specifically by adding a line in [18:50:17] * LocalSettings.php for each of them like this: [18:50:19] ah I see, you have sub-extensions [18:50:20] wacky [18:50:22] * require_once( "$IP/extensions/UsabilityInitiative/EditToolbar/EditToolbar.php" ); [18:51:35] brion: NavigableTOC isn't appearing inExtensionMessages.php, which is what is populated by that script [18:51:41] # Regenerate the extension message file list [18:51:41] echo Updating ExtensionMessages.php... [18:51:41] php $SOURCE/maintenance/mergeMessageFileList.php --list-file=$SOURCE/wmf-config/extension-list \ --output=$SOURCE/wmf-config/ExtensionMessages.php [18:51:49] brion: try running that manually [18:52:05] werdna: you go ahead, i'm trying to catch up the general merge [18:52:12] brion: sure, can do :) [18:52:13] UsabilityInitative/NavigableTOC.php [19:00:37] this is baffling, if I source that file in eval.php, it has no impact on $wgExtensionMessagesFiles [19:00:58] Even though its third to last line is this: $wgExtensionMessagesFiles['NavigableTOC'] = dirname( __FILE__ ) . '/NavigableTOC.i18n.php'; [19:01:01] and it works fine locally [19:06:45] aha [19:06:53] It's because that file has already somehow been included [19:07:22] and (I suspect), $wgExtensionMessagesFiles is overridden by the localisation cache [19:08:22] brion: thank you so much for your help in code review and deployment for the past three weeks! [19:08:41] i'll make sure to blog about today's usability deployment! [19:09:48] brion: I'm going to momentarily disable NavigableTOC to fix this problem, if that's cool. [19:10:08] actually, maybe I can just remove the l10n cache [19:15:09] nkomura / brion / TrevorParscal is the issue fixed? [19:15:27] lemme refresh and try again [19:16:26] YAY! [19:16:32] all clear [19:16:33] :)) [19:16:36] brion: fixed :D [19:16:41] thank you! [19:16:41] yay [19:17:00] brion: left a note in server admin log about the trick to fix it -- it can't be active on aawiki to recache :) [19:17:06] werdna: hmm, i'm pretty sure i sync-file'd extension-list before turning on generally. that not enough? bah :D [19:17:19] lunch brion? [19:17:20] brion: you have to scap, that's the script that runs the merge [19:17:31] the thing that actually needs to be synced is ExtensionMessages.php [19:22:58] i'll be at indian restaurant if local folks can join :) [19:25:09] Database returned error "1146: Table 'deploywiki.parsertest_user_daily_contribs' doesn't exist (localhost)" [19:25:16] nimish_g: need to add that to parsertest tables hook [20:06:48] brion-away: I've got some NTOC performance improvements in my local copy [20:45:19] RoanKattouw: what else did you come up with to improve performance? [20:45:43] hey TrevorParscal [20:45:54] yo [20:47:50] brion-away: is that a new DB? [20:48:59] TrevorParscal: Building the NTOC once on init instead of twice [20:49:24] Changed some $j('

') to $j('

') , which is a lot faster [20:49:52] Two culprits I didn't get to yet is that $.wikiEditor.fixOperaBrokenness() and NTOC's build() function are slow [20:50:20] The former takes 150 ms for the first call, the latter about 180 ms plus it calls the former [20:56:15] OK - we may want to push r57250 to the cluster when possible [20:56:34] I've got some to [20:56:40] RoanKattouw: I will look at it too and do some profiling [20:56:44] I'll tag them babacofix and untag the deployed ones [20:56:48] I may be able to improve the speed of the parser [20:57:01] I changed the regex, not sure what the effect of that was [20:57:23] It failed to account for trailing spaces or level-six headers, so I just stole the one from Parser.php [20:58:28] nimish_g: when running the parser test suite we clone the table structure in the database; anything that's gonna get written to while we work needs to be included in on that. there's a hook to add to the list of tables that get cloned for the test suite [20:58:37] pretty easy to stash that into UserDailyContribs [20:59:24] Gah I hate my uni schedule. If it was better, I'd be able to come to the office for two weeks, one is just so short :( [20:59:41] :( [21:02:08] ok, I'll need to add it for the clicktracking table as well then [21:02:51] RoanKattouw: the buildList function could be faster for sure [21:02:59] is that the one you were working on? [21:03:42] Nah, that one's not the problem, only 42 ms [21:03:54] The one that adds the

elements, right? [21:04:23] yeah [21:04:24] and the m in /^={1,6}.+={1,6}\s*$/gm means multi-line, why would we need that option? hmm... [21:04:45] So ^and $ do what you expect [21:05:02] Without /m they mean the beginning and end of the whole string, respectively [21:05:15] hmm -ok, yeah [21:05:31] You did some weird (?= construct at the end that I didn't understand [21:05:39] hmm [21:05:46] Plus you had .* instead of .+ and {1,5} instead of {1,6} [21:06:15] for sure on the 1,6 [21:06:26] that was someting I kept thinking in my mind I needed to change [21:08:04] but um.. the parser currently says ====== is h2 with == as text [21:08:34] our TOC does not [21:08:55] How many equals signs is that? [21:08:59] 6 [21:09:12] it thinks == == == [21:09:14] Ah that's because it does the regexes decrementally [21:09:32] First it does /^======.+======\s*$/m [21:09:37] Then with 5 equals signs, etc. [21:09:51] yeah, i think that's a bug in the parser actually [21:09:55] it should just be nothing [21:10:05] It doesn't double-match because it replaces them with $1 [21:10:08] Yeah [21:10:24] .+ should be [^=].* [21:10:25] our js version had a [^=]* which probably should have been [^=]+ but still [21:10:45] yeah [21:10:48] yours was right [21:10:53] Yeah [21:11:02] that way an = is ok in the heading like == This = that == [21:11:04] Yours doesn't allow stuff like === Why e=mc^2 is true === [21:11:10] right [21:11:19] nimish_g: thx! [21:11:36] this is silly though -> http://localhost/~tparscal/prototype/index.php/Main_Page [21:11:55] brion: np, I'm gonna put that in the clicktracking extension too b/c it creates 2 tables [21:11:56] There's a shitload of bugs (again; I woke up to like 8 new ones today) in Bugzilla, I'll get cracking at some over the weekend [21:12:03] TrevorParscal: And I have access to your localhost because... [21:12:08] sorry [21:12:09] oops [21:12:12] ha ha ha [21:12:15] *TrevorParscal feels silly [21:12:41] http://img198.imageshack.us/img198/626/picture1ff.png [21:12:58] heheh [21:13:11] So that's 6, 8, 10, 6? [21:13:26] ==== [21:13:26] ====== [21:13:26] ======== [21:13:26] ==== [21:13:49] brion: If you deploy nimish_g 's fix, please also do the two revs tagged babacofix, or at least the top one (highest revid) of those [21:14:52] RoanKattouw: if those are the same two babacofix revs from earlier they're already up [21:15:23] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/babacofix [21:15:56] brion: possibility of r57250 being deployed soon? [21:16:13] *TrevorParscal apologizes for fragmented deployment [21:16:13] i give no guarantees of anything right now [21:16:18] not sure i'll have time for anything else today [21:16:57] brion: r57250 is a trivial message change [21:17:39] *TrevorParscal backs away while steam emerges from brion's ears [21:18:21] \me is glad that RoanKattouw is at a safe distance [21:18:36] *parutron never learns. [21:19:11] *RoanKattouw makes a mental note to find out where Brion lives and avoid the general area next time he's in SF [21:19:11] is \me speaking in 4th person? [21:19:55] :D [21:21:04] OK boys and girls I'm off to bed [21:21:18] goodnight catrope! [21:21:21] nini [21:21:23] I'll embark on another bugfixing spree during office hours tomorrow [21:21:27] whee [22:04:49] hi team! [22:04:58] well team that's not here. [22:06:17] nevermind, remotees are all gone! [22:08:29] *werdna waves parutron [22:08:31] I'm here :) [22:45:16] brion: are we deploying ClickTracking as well today? (it's all set to be off until we get the backfill data in there) [22:45:55] hm, so what do we need to do for it? [22:47:02] before we can activate it you mean? or just to deploy it? [22:47:04] so excited for click tracking! [22:47:15] *parutron is so excited for click tracking! [22:47:26] just in case you were wondering who that parutron girl was. [22:47:33] well if we're waiting on the backfill for UserDailyContribs, do we need to do anything now? [22:47:39] hehe [22:50:17] nope, but would you be comfortable deploying it right after the backfill information is available? I figured it might be easier if you've reviewed the code now (in case you see any issues with it) and once we get the backfill data, just set $wgClickTrackThrottle to whatever % we want...I just don't want to unnecessarily delay it [22:54:34] sure, let's plan a day next week or so? [22:56:37] ok