[15:54:57] Morning folks [15:55:11] Am I right that DST is still in effect in the US? [15:55:34] shouldn't be [15:55:37] I have no idea though [15:55:43] check the internets [15:55:54] I didn't notice DST had dropped out until the evening afterwards [15:55:58] we are still on daylight saving time [15:55:59] I thought I'd left my watch on CET [15:56:06] (from Brussels) [15:56:12] Yeah, I saw that [15:56:32] for more fun, I'm going into EET tomorrow, and CET on Thursday, before returning to BST for Tuesday and Wednesday and back to CET on Thursday [15:56:51] Where in EET are you going again? Greece? [15:56:54] yes [15:56:59] Finland's also in EET, right? [15:57:05] yes [15:57:11] and Sweden, maybe [15:57:14] nkomura: When does DST stop in the US, do you know off the top of your head [15:57:19] No, not in Sweden [15:57:20] if only there were some sort of map of this stuff [15:57:24] heh [15:58:02] RoanKattouw: Nov 1 [15:58:10] Ah yes [15:58:13] So it's just this week [15:58:54] argh, this is so annoying [15:59:04] I'm setting a click handler on an element, and it doesn't seem to be firing [15:59:07] oh, I bet I know [15:59:16] it's probably because I'm moving it into a menu [15:59:30] You're setting the click handler, then moving it? [15:59:35] yes [16:00:41] Yeah that probably doesn't work well [16:01:02] You can get around it by using $('#myID').live( 'click', function() { ... } ); [16:01:14] I jus t moved the setting to after it's moved. [16:01:16] easier :P [16:01:22] Oh yeah if that works too [16:01:34] Not always easy to do, depending on how your code is layed out [16:03:23] :) it was easy to do in this case [17:37:04] good morning RoanKottouw [17:37:18] Morning [17:38:00] nimish_g: When would you like your "how Wikimedia's caching system works" explanation? [17:38:24] now's good [17:38:39] OK [17:38:55] So there's different layers of caching [17:39:09] From the outside in, there's Squid cache, APC and memcached [17:39:53] Squid caches entire HTML pages for quicker serving; this happens only for anonymous page views (not for logged-in users, or for history, RC, edit form, etc.) [17:40:36] This helps performance because those views are a large proportion of the requests, and because it allows us to exploit the fact that some of them are in Amsterdam [17:41:12] Any request to Wikipedia always goes through Squid first; it'll be proxied to an Apache upon a cache miss [17:41:39] Whenever a page is edited, its rendered version is purged from the Squid caches [17:42:35] So that's Squid [17:43:20] The next layer is APC, which caches PHP bytecode. Basically PHP compiles .php files to bytecode and executes that; caching that bytecode speeds up stuff a lot. You don't have to worry about this layer, though, because it doesn't introduce any complexities in the MW software [17:44:08] After that, there's memcached, which is basically a daemon that allows you to cache PHP values and objects in memory [17:45:34] We use memcached for things like the parser cache (caching of parsed wikitext), cached user objects, localization cache (or maybe we put that in files, dunno), and random stuff like login throttles [17:46:22] Generally memcached is not totally reliable in terms of preserving data (it's in memory, after all), so it's only used for stuff that can be gotten from the database anyway or stuff that doesn't matter too much if it disappears every so often (like throttles) [17:47:35] That pretty much concludes my overview of our caching layers [17:47:38] ok, so squid cache is really the only one that might be tricky [17:47:44] thank you =) [17:47:51] Yes [17:48:08] Primarily in combination with anonymous users [17:48:35] However, the approach I took in implementing clicktracking for the left navbar shouldn't be hindered by it much [17:48:57] The actual tracking is done by secretly pointing the link to api.php, which then redirects to the original link destination [17:49:03] api.php requests are never cached by Squid [17:49:32] So the only thing that could go wrong is that the ClickTracking JS is not included on a page view because there's a pre-deployment version of the HTML in Squid [17:49:40] Which will be thrown out eventually when the page is edited [17:53:29] this *would* be a problem, though, if we bucketed users [17:53:44] Bucketed? How? [17:53:50] actually...do anon users get any cookies at all? [17:54:08] Some, I think [17:55:07] basically, we check if a user has, let's call it a "bucket cookie". if they do, great. if not, we give them one. Then, later based on how we distributed bucket cookies, we can say something like "all users with bucket cookie X get certain things turned on or off" [17:55:25] Ah yes [17:55:39] That'd still work, but only if you process cookies on the JS level [17:55:51] then, we see if that changes aspects of their clicks. Like, if they have bucket cookie 1, maybe we show them our skin with color scheme 1, and we see if all of the sudden the clicks change [17:55:55] hm, ok [17:56:33] And you should consider the fact that pushing new JS to anons gets delayed by caching [17:56:47] Because pages referring to the old JS will stick around in cache for a while [17:58:00] RoanKattouw: you forgot about client-side caching [17:58:15] We update style versions aggressively [17:58:35] wouldn't it be the same JS? I mean, ideally I was thinking it'd be a property of the $wgUser global variable in PHP space [17:59:13] nimish_g: If you change the settings, like users in bucket 1 now get different settings, you'd presumably do so by changing something in the .js file [17:59:36] Generally, anything done in PHP will fail for anons because Squid is between you and them [17:59:51] werdna: Updating style versions should fix that, right? [18:02:00] RoanKattouw: ugh, style versions are eeevil [18:02:33] Yeah what's the other thing called again [18:02:53] ok, so squid takes the php output and caches that, not the actual PHP [18:02:57] gotcha [18:02:58] Yes [18:03:02] well, you could easily generate a style version with some filemtime() magic :) [18:03:06] And only for anonymous reads [18:03:22] werdna: Yeah but there's this other thing, lemme look up the name [18:04:11] ETags [18:04:35] well they aren't *that* useful [18:04:42] it's no more useful than If-Modified-Since [18:05:17] Yes, I just realized that from reading up on them [18:05:19] All that means is that the client sends a request, and along with If-Modified-Since it sends If-None-Match [18:06:55] Yeah that creates 304 roundtrips, not that good [18:14:09] member:identifier:roankattouw - do i need to bump any version numbers when I alter vector css files? [18:14:42] adam_miller: $wgStyleVersion in includes/DefaultSettings.php [18:14:48] thanks [18:23:52] TrevorParscal, RoanKattouw and adam_miller, I just found this site exists: http://browsershots.org/ might be useful for quick sanity testing [18:24:32] Yeah I know but it's rate limited and you have to wait like 30 mins [18:24:44] Plus it doesn't show which JS errors there are, only that they're there [18:42:48] adam_miller: how did the code review go on Friday? [18:43:29] i sent brion all my revision numbers and then he went offline [18:43:31] TrevorParscal: At some point, could you look at all the IE-specific bugs in Bugzilla and try to reproduce them? It's OK if you do the minimal amount of work to diagnose the bug so I can fix it, it's just that I don't have IE :) [18:43:48] adam_miller: lost connection the other day sorry [18:43:52] I'm looking at them right now actually [18:43:58] Oh good [18:44:02] most of what I will probably be doing today... [18:44:08] adam_miller: Do you know about tags in CodeReview? [18:44:10] yeah, things are all wonky! [18:44:29] but bug #21293 is most likely going to be a trailing comma somwhere... [18:44:31] roankattouw: i do not. enlighten me [18:44:33] tracking it down now [18:44:37] I think acaifix may be appropriate; also, for CollapsibleTabs, brion could probably just review the existing state of the extension as you wrote it from scratch [18:45:21] adam_miller: If you're logged in and go to view a revision at [[mw:Special:Code]], there's an "add tag" field where you can enter a tag (say acaifix), then view tagged revisions through Special:Code/MediaWiki/tag/acaifix [18:46:14] yeah it'd be best to review it from it's current state, as I just switched some things around so that CollapsibleTabs worked for RTL languages as well [18:48:25] brion: In case you're not keeping up with conversation in this channel: the CollapsibleTabs extension was only recently started, so a review of its current state rather than all revisions is probably best [18:53:18] nkomura: What do you mean by "jquery support for Vector" in your latest e-mail (meeting agenda)? [18:53:38] RoanKattouw: making the library available for our release [18:53:52] Yeah that doesn't really require effort [18:54:06] The very little effort required (moving it to core) I've already done [18:54:08] it will not be available for all pages [18:54:14] True [18:54:25] We wouldn't enable jQuery for /all/ pages, just pages that have the new search bar [18:54:27] cool, will you let tim know that [18:54:35] Which is still everything if you have SS and Vector enabled [18:54:49] neither TrevorParscal or you were available for the meeting [18:55:02] so we didn't know you've done it all ready [18:55:04] Tim was not keen on enabling it on all pages until later as far as I understood. [18:55:04] (we load jQuery on-demand, so if SimpleSearch is supposed to be on a page then it'll ask for jQuery and get it) [18:55:19] Where all pages is really everything? [18:55:22] Like, including Monobook? [18:55:24] right [18:56:43] nkomura: Also, don't worry too much about the time, the DST mis-sync is helping here; thanks to that it's only 9-10 pm instead of 10-11 pm for us [18:58:07] RoanKattouw: i'm not worried about the time change [18:58:29] I mean it being late [18:58:42] i hope to have a meeting from 11-12am PST/PDT so that it will be 8-9pm for CET [18:58:58] i think 10-11pm is too late for hannes [18:59:13] Yeah, and 9-10 is lunch time [19:25:36] hi everyone [19:25:41] nimish are you there? [19:34:48] hey hannes_tank [19:34:49] most of us in the office are attending the brown bag meeting right now [19:56:50] nkomura: Could you give us a signal when we should call in? [19:57:17] roan? [19:57:25] Yeah? [19:57:30] do you know how expensive such a call will be? [19:57:41] For me it's to a 0800 number [19:57:48] so its free? [19:57:51] Germany too [19:57:53] Yeah [19:57:55] oh cool [19:58:25] can u do me a favor and forward naokos mail to me? [19:58:31] the one wioth the numbers [19:58:40] I just overwrote my postbox [19:59:04] oh no...adam already did. [19:59:34] heh [19:59:38] No you've got two copies [20:00:57] :) [20:01:20] shall we call? [20:01:32] I'll just call [20:01:39] The rest is probably still in the brown bag meeting [20:02:13] we are in [20:02:21] Calling [21:22:17] RoanKattouw: this JS error is only happening on the prototype - not on my localhost [21:22:43] Weird; I'll scap [21:23:09] yeah - I'm thinking it's a trailing comma somewhere, but it's already fixed in head [21:23:36] OK the extensions dir should have been updated now, try again [21:44:28] RobH: are you there? [21:44:44] nkomura: Fred's already setting me up, if that's what you're after [21:45:07] yeah i was following up about your shell access [21:45:28] as TrevorParscal stepped out for his late lunch [21:52:03] OK thanks to Fred I now have shell access [21:52:28] I'm off to bed soon because I have an exam tomorrow, but I'll be looking into the survey thing ASAP [21:56:42] congrats! [21:57:09] good luck to your exam tomorrow [21:57:34] Thanks [21:58:06] TrevorParscal: FYI, tomorrow I'll be looking at bugs 21291, 21269, 21229, 21216, 21202 on the train [22:13:40] TrevorParscal or RoanKattouw, any idea why overflow: hidden; was applie to .wikiEditor-ui-toolbar .sections? [22:14:00] Don't look at me :) [22:14:09] when i remove that rule it fixes the problem of the heading drop down menu rendering behind the text box [22:14:36] ok i just want to make sure that it's not doing something important that I'm missing before I rip it out of there [22:18:47] adam_miller: yes [22:18:59] adam_miller: that's interesting too [22:19:10] the reason that was done is because of animation [22:19:32] but we could switch it to overflow:hidden durring animation and back to overflow: show after [22:19:54] it looks like it's causing you to lose icons when you pinch the browser as well [22:20:04] was that intentional? [22:23:20] loose icons? [22:26:19] when you have overflow set to hidden, they disappear from the menu when you make the width smaller [22:33:46] they disapear from the menu? what menu? [22:35:49] *toolbar* [22:36:23] ah [22:36:57] that's not intended [22:37:09] that happened when I did the animation changes as well [22:37:18] ok, so durring animation, overflow should be hidden [22:37:27] after animation, overflow should be show [22:38:37] ok cool, the next problem we'll have then, is when the icons bump to a second line, the textarea and navigable TOC do not move down to adjust to the change in height on the toolbar [22:42:11] TrevorParscal: I've partially done the tab thing, but my web design skills are lacking :) [22:42:35] link me [22:42:37] adam_miller: what looks wrong about this commit? http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiative/EditToolbar/EditToolbar.js?r1=57982&r2=58070 [22:42:50] I'll give you a hint, it caused https://bugzilla.wikimedia.org/show_bug.cgi?id=21293 [22:42:54] I haven't done any tab stuff at all, but I've at least put the icons in the new places [22:42:57] http://liquidthreads.labs.wikimedia.org/wiki/Feedback [22:43:52] TrevorParscal: extra comma? [22:43:57] http://trevorparscal.blogspot.com/2009/01/pitfalls-of-porting-javascript-to.html [22:44:00] bingo! [22:44:02] :) [22:44:09] please fix / close bug [22:45:40] werdna: when the reply is clicked the 2nd time (closing the reply box) just do a slideUp() [22:45:46] rather than a fadeOut(); [22:46:01] TrevorParscal: refresh my memory please - how do i reference the bug from my commit msg? [22:46:20] just use #21293 [22:46:56] also mention the revision it fixes using r57982 [22:48:46] As regexes they would be bug: /#[0-9]+/ and revision: /r[0-9]+/ [22:48:53] or something like that [22:50:30] werdna: if you can make the menu and the More \/ not have that 1px gap between them you can hide the menu on mouseout of the entire .lqt-thread-toolbar-menu [22:50:42] perhaps even show on mouseover lqt-thread-toolbar-menu [22:51:03] werdna: lookin good though [22:51:52] TrevorParscal: the positioning of the toolbar sucks [22:52:00] yeah [22:52:19] well, now that you've done the majority of the work I can take another shot at cleaning up the particulars [22:52:21] and it doesn't have the fun tab like appearance [22:52:35] I'd really like to learn how to do the tab thing, but I'm available for so little time over the next few weeks [22:53:18] well, we just need about a half day to get it sorted [22:53:36] i'm on vacation till next tuesday [22:54:10] k [22:54:19] we can just hook up then and play it by ear [22:54:53] o_O [23:01:56] Off-topic: I just updated the proposed format for template XML definitions, per Trevor's recommendations: http://usability.wikimedia.org/wiki/Template_forms#For_multi-language_wikis [23:44:12] TrevorParscal: just committed the wikiEditor changes so that overflow:hidden is only applied during transitions. [23:45:18] and now you should be able to see the other problem I was talking about earlier with resizing the window when the advanced menu toolbar is open. [23:46:24] i'm going to look into that more later, but i need to break to eat dinner now