[00:13:57] <TimStarling>	so, 1.17wmf1
[00:15:16] <RoanKattouw>	Yeah
[00:15:39] <RoanKattouw>	Before we do that, I need to add a few more of the ex-UsabilityInitiative extensions
[00:18:04] <RoanKattouw>	I'd forgotten about that, my apologies. I'll be done in like 5-10 mins
[00:20:15] <TimStarling>	we probably want $mainSourceUrl = '^/branches/REL1_17'
[00:22:12] <RoanKattouw>	Yes
[00:22:16] <RoanKattouw>	Oops, thanks for pointing that out
[00:22:40] <TimStarling>	also you can't have an extension which is both in $normalExtensions and $specialExtensions
[00:22:58] <TimStarling>	there are 7
[00:23:00] <RoanKattouw>	Also, we still have r67177 (use APC instead of memcached for languageconverter) in the merge list, is there a reason for that?
[00:23:02] <RoanKattouw>	Oh right
[00:23:05] <RoanKattouw>	Will fix
[00:24:26] <TimStarling>	you mean r60970?
[00:24:34] <RoanKattouw>	Yeah sorry
[00:26:29] <RoanKattouw>	What's the 7th duplicated extension? I found 6
[00:26:51] <RoanKattouw>	Contribution{Reporting,Tracking} DonationInterface FundraiserPortal LandingCheck VariablePage
[00:28:47] <RoanKattouw>	I'
[00:28:51] <TimStarling>	CentralNotice
[00:29:02] <RoanKattouw>	Right
[00:29:05] <RoanKattouw>	I'm clearly blind
[00:29:13] <RoanKattouw>	I just committed a bunch of changes, I'll take that one out too
[00:29:38] <TimStarling>	r60970 should stay, there's about 2MB in that cache entry
[00:29:48] <TimStarling>	it's better not to stress out the memcached servers unnecessarily
[00:29:58] <RoanKattouw>	OK
[00:30:00] <TimStarling>	in the long term, APC fetches and stores should be integrated into ObjectCache.php
[00:30:24] <TimStarling>	we should have wfGetCache(CACHE_LOCAL)->set(...)
[00:30:46] <RoanKattouw>	There's CACHE_ACCEL, right?
[00:31:37] <TimStarling>	yes, but that won't work properly if there's no accelerator
[00:31:42] <TimStarling>	you want it to fallback to memcached
[00:32:05] <RoanKattouw>	Right
[00:32:25] <TimStarling>	so I'm saying there should be a CACHE_LOCAL, the meaning of which is "use a local cache if a fast one is available, otherwise use a fast shared cache"
[00:33:07] <TimStarling>	maybe CACHE_FAST_LOCAL
[00:33:15] <RoanKattouw>	Right
[00:33:18] <RoanKattouw>	Either way
[00:33:21] <TimStarling>	since being fast is more important than being local
[00:33:24] <RoanKattouw>	I have like 20 mins left
[00:33:36] <RoanKattouw>	So do I just run make-wmf-branch 1.17wmf1 1.16wmf4 ?
[00:35:16] <TimStarling>	yes
[00:35:28] <TimStarling>	do a dry run first, it'll most likely fail horribly
[00:35:44] <TimStarling>	I did a lot of dry runs with 1.16wmf4 before I finally committed it
[00:35:47] <RoanKattouw>	Right
[00:35:57] <RoanKattouw>	echo '$dryRun = true;' > local.conf    right?
[00:36:04] <TimStarling>	yes
[00:36:42] <RoanKattouw>	It's running now
[00:37:15] <RoanKattouw>	Does ^ have a special meaning in SVN paths?
[00:38:06] <TimStarling>	yes, in subversion 1.6 or later it means the root of the repository of the working copy
[00:38:15] <RoanKattouw>	Nice
[00:38:31] <TimStarling>	so ^/trunk = svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk
[00:38:49] <RoanKattouw>	That's very cool, I'm sure this'll save me time in the future
[00:38:59] <RoanKattouw>	I thought ^ was just magic handled by the script at first
[00:51:54] <RoanKattouw>	What the...
[00:52:02] <RoanKattouw>	It just committed the new branch even though it was in dry run mode
[00:53:09] <TimStarling>	heh
[00:54:03] <TimStarling>	edit the script to tell you whether it's in dry run mode at the start
[00:54:12] <RoanKattouw>	It does
[00:54:15] <RoanKattouw>	OOoooooh wait
[00:54:18] <TimStarling>	so that you don't have to wait for the actual commit to find out
[00:54:24] <RoanKattouw>	local.conf needs <?php $dryRun=true;
[00:54:28] <RoanKattouw>	Not just $dryRun=true;
[00:54:29] *RoanKattouw 	slaps self
[00:54:31] <TimStarling>	details
[00:54:50] <RoanKattouw>	OK I have to go to this meeting with this Google Wave guy now, but I'll keep working on this
[00:54:53] <RoanKattouw>	And run the script again
[00:55:18] <TimStarling>	so it would have echoed "$dryRun=true;", and you thought, nice of it to tell me that it is true
[00:55:34] <TimStarling>	but strange formatting for a diagnostic message
[00:57:08] <TimStarling>	Google Wave? I thought that was dead and buried
[00:57:36] <Reedy>	Indeed
[01:27:16] <RoanKattouw>	Oh, awesome
[01:27:18] <RoanKattouw>	'svn' 'merge' '-q' '-c' '60970' '^/branches/wmf/1.16wmf3' '1.17wmf1'
[01:27:20] <RoanKattouw>	Conflict discovered in '1.17wmf1/languages/LanguageConverter.php'.
[01:28:00] <awjr>	that should be fun
[01:28:02] <RoanKattouw>	Oh, whitespace conflict, was fine
[01:28:02] <TimStarling>	yeah, that happens
[01:28:23] *awjr 	shakes fist at whitespace
[01:31:24] <RoanKattouw>	Alright, script ran
[01:31:32] <RoanKattouw>	Will test run the code in a bit
[15:18:14] <Krinkle>	huskyr: Heb je al een WordPress.org account ? Dat is nodig om een plugin toe te kunnen voegen en/of als 'author' gelinkt te kunnen zijn vanaf de plugin pagina
[15:18:14] <Krinkle>	http://wordpress.org/support/register.php
[15:18:29] <huskyr>	krinkle: dacht van wel
[15:18:39] <huskyr>	zelfde als forums?
[15:18:41] <huskyr>	dan wel idd
[15:20:20] <Krinkle>	nee, ze hebben twee account systemen
[15:20:29] <Krinkle>	ik weet niet welke waaraan grenst.
[15:24:06] <GerardM->	Krinkle heb jij nog wat van Indiers gehoord ?
[15:24:37] <Krinkle>	GerardM-: nee, nog niet.
[15:24:57] <Krinkle>	huskyr: Kun je ff checken op wp.org/extend in loggen en je gebruikersnaam doorgeven ?
[15:25:26] <Krinkle>	GerardM-: hoewel.. Ik check ff mn mail. Heb nogal wat gekregen laatste tijd.
[15:25:45] <huskyr>	krinkle: ik kan er gewoon in
[15:25:55] <Krinkle>	als 'huskyr' ?
[15:25:59] <huskyr>	jep
[15:26:51] <huskyr>	zelfde als forum
[15:27:15] <Krinkle>	k
[15:50:33] <Krinkle>	huskyr: Ik heb je op MW.org aan de Coders usergroup toegevoegd zodat je revisions kunt checken. Zie http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/path&path=%2Ftrunk%2Ftools%2Fwp-photocommons%2F
[15:50:48] <huskyr>	krinkle: woei!
[15:50:51] <huskyr>	wat kan ik dan? :)
[15:51:00] <Krinkle>	je krijgt een mail als iemand een follow-up doet of reacties achterlaat (sowieso al)
[15:51:11] <huskyr>	ah, dat kreeg ik al dacht ik
[15:51:12] <Krinkle>	maar wat nieuw is dat je kunt zetten naar "fixme", of "ok"
[15:51:19] <huskyr>	ah, ok
[15:51:23] <huskyr>	en ik kan jouw code bekijken :)
[15:51:28] <Krinkle>	ie. mijn commits dus (altijd handig als we elkaar checken iff)
[15:51:29] <Krinkle>	idd(
[15:51:52] <Krinkle>	ik heb die van jou zojuist even langs gelopen. Geen reacties nodig, lijkt OK.
[15:52:13] <Krinkle>	als je vanuit die link hierboven begint kun je navigeren van de ene commit naar de andere
[15:52:20] <Krinkle>	(geen nood voor 20 tabbladen openen :) )
[15:55:40] <huskyr>	ok :)
[17:19:29] <jorm>	wheee!  tahoe trip canceled.
[17:25:11] <pdhanda>	:(
[17:29:48] <flipzagging>	hey Krinkle, yt?
[17:30:21] <Krinkle>	you thirsty or your turn ?
[17:30:40] <flipzagging>	"you there"
[17:30:46] <Krinkle>	ah, didn't know that one yet :)
[17:30:50] <flipzagging>	I would offer you a drink, if I could dcc it.
[17:31:04] <Krinkle>	hehe :) - So what's up ?
[17:31:16] <flipzagging>	Trevor & Roan aren't in yet, mdale and I were looking at mediawiki.js
[17:31:38] <flipzagging>	specifically mediaWiki.html.element. If we have jquery, what's the purpose of this function?
[17:31:59] <Krinkle>	For the record, Tim-away wrote that.
[17:32:04] <flipzagging>	I know
[17:32:11] <flipzagging>	but you modified it a little :)
[17:32:13] <Krinkle>	One of the usecases is that it doesn't make it into a DOM element right away.
[17:32:26] <flipzagging>	which is good because... ?
[17:32:26] <Krinkle>	ie. <link>, <img> and <script> will not load.
[17:32:33] <flipzagging>	oh.
[17:32:43] <Krinkle>	I think, even if it were just that, it's very useful.
[17:32:53] <Krinkle>	it returns a string
[17:33:03] <Krinkle>	(like the PHP class does)
[17:33:45] <flipzagging>	yeah, that's what mdale and I said
[17:33:56] <flipzagging>	it seemed to be informed by "thinking in PHP"
[17:34:03] <Krinkle>	wheares if you make a <script> tag in jQuery it's a DOM element and/or it's made through new Image() (not sure which jQuery does or if there's a major differrent from the top of my head) - it would (pre)load it right away.
[17:34:35] <mdale>	thats not true
[17:34:40] <mdale>	you have to issue the .load call on the imate
[17:34:41] <mdale>	image
[17:34:48] <mdale>	and you get a callback
[17:34:54] <mdale>	do do predictable things
[17:35:06] <Krinkle>	afaik if I do $("<script src="foo.js" />") without anything, I just made a http request.
[17:35:12] <mdale>	nope
[17:35:19] <Krinkle>	Let's see
[17:35:19] <flipzagging>	not to my knowledge either
[17:35:20] <mdale>	you have to put it in the dom
[17:35:25] <flipzagging>	what mdale said
[17:35:46] <Krinkle>	Nope, I was right.
[17:35:47] <Krinkle>	$("<img src='foo.js' />")
[17:35:49] <Krinkle>	made a http request
[17:36:12] <Krinkle>	script doesn't always do it (only in some cases, not sure which cases), but image certainly does.
[17:36:55] <Krinkle>	Which is why in most script people have to attach the load() event first before they set the 'src' or 'href' attribute.
[17:37:22] <Krinkle>	$('<img />').load(func).attr('src', 'foo.jpg');
[17:37:25] <mdale>	yea...
[17:37:38] <mdale>	your right .. but still not a good reason to build things out with strings
[17:38:43] <Krinkle>	How so ? It doesn't always have to end up in the DOM (directly)
[17:39:06] <Krinkle>	doing $('head').append( mw.html.element( ... ) ); is obviously useless.
[17:40:14] <flipzagging>	Krinkle: at least with firefox + jquery, that auto-loading thing only happens with images, not with links or scripts, afaict.
[17:40:31] <mdale>	it sort of makes sense
[17:41:01] <Krinkle>	Sure, in most cases, escpecially when in a jQuery-using module, pre-loading makes sense.
[17:41:05] <mdale>	you may want $('<img />').attr('src', foo.jpg').load(function(){ $(this).naturalHeight; } or what have you
[17:41:39] <mdale>	I don't see why you would build out html that you don't want the image loaded for
[17:42:50] <flipzagging>	the fact that it's built with strings doesn't make it easier to attach .load(), surely
[17:43:05] <Krinkle>	If there are no usecases for it or none that aren't possible with jQuery, we could drop mediaWiki.html and migrate the .escape function to a prototype in mediaWiki's jQuery prototypes on top of mw.js
[17:43:25] <mdale>	if your ~want~ to ~not~ load the image you would use jquery.lazyload images plugin or what have you
[17:44:07] <flipzagging>	actually I have questions about a lot in mediawiki.js, not that you are the primary author...
[17:44:10] <flipzagging>	but you're here ;)
[17:44:15] <flipzagging>	like, the whole Map type
[17:44:20] <mdale>	building html with string is just "not the right way"
[17:44:22] <flipzagging>	in a language built out of a map type
[17:44:49] <Krinkle>	flipzagging: What about the Map class/object
[17:44:56] <flipzagging>	what's it for?
[17:45:06] <Krinkle>	flipzagging: Have you looked where it's used ?
[17:45:20] <Krinkle>	It's used in a lot of places and will be even more once it's deployed probably
[17:45:47] <Krinkle>	mw.config, mw.user.options, johnsGadget.settings
[17:45:54] <flipzagging>	well, I just don't get the concept
[17:46:02] <flipzagging>	javascript is all mappings already
[17:46:08] <Krinkle>	mw.msg not to forget
[17:46:39] <flipzagging>	well yeah that's where I bumped into it
[17:47:07] <flipzagging>	so every single template => message pair has a reference to the entire message table
[17:47:11] <flipzagging>	because... ?
[17:47:18] <Krinkle>	It's not ready though a .lock and .unlock function are on the waiting line for Map
[17:47:44] <Krinkle>	flipzagging: I'm not sure I understand that sentence... ?
[17:47:48] <flipzagging>	it seems to be so that .toString() can legitimately know that the key doesn't exist.... I don't know this seems confused between whether it represents a single message or all messages
[17:48:12] <Krinkle>	what does Map or mw.msg have to do with templates and the message table ?
[17:48:37] <flipzagging>	Krinkle, okay, we agree that javascript has "maps" already? object.foo = bar?
[17:48:47] <flipzagging>	so what is the Map type giving us that we didn't have?
[17:49:39] <mdale>	it gives you foo.bar.cat without an error.. but you could just as well wrap it in a try catch
[17:49:40] <Krinkle>	A simple way to get multiple values into an array, checking if certain keys exist in a single function. Providing a read-only set of values in a gadget. Making it easier for users to override settings.
[17:49:57] <flipzagging>	well read-only values are possible in other eays
[17:50:10] <flipzagging>	jquery.extend() handles overriding, as far as I know
[17:50:11] <Krinkle>	Ie no need to if ( values.this ); if (values.that), if (values.john)
[17:50:21] <Krinkle>	but values.exist( ['this', 'that', 'john'] )
[17:50:54] <mdale>	or native (  ['this', 'that', 'john'] in values )
[17:52:27] <Krinkle>	Hm.. does that work cross-browser and in IE6 ? I always thought it didn't, but I could be wrong.
[17:53:13] <flipzagging>	( values.this && values.that && values.foo ) does not strike me as too verbose, personally. Unless the set of values to be tested changes a lot. In which case you could just write a utility function.
[17:54:04] <Krinkle>	Okay, fair enough.
[17:54:14] <Krinkle>	But could be that Roan or Trevor have some points that I don't know.
[17:54:19] <Krinkle>	I didn't write the mw.js core :)
[17:54:27] <flipzagging>	yeah, Roan just showed up, we'll ask him maybe
[17:56:41] <mdale>	we have the jQuery utility 'inArray' as well
[18:00:05] <flipzagging>	[ 'foo', 'bar' ] in x doesn't work in IE6
[18:00:41] <flipzagging>	does inArray work with multiple items?
[18:00:43] <Krinkle>	No
[18:00:51] <flipzagging>	well at least it doesn't throw an error, though.
[18:00:59] <Krinkle>	It's a jquery compatibility function for indexOf.
[18:01:08] <Krinkle>	Uses indexOf if available. for() loop otherwise
[18:02:03] <Krinkle>	We could create a setInArray() prototype. But i feel as more of these small things pop up one ends up with a collection of prefixed prototypes when would be better off keeping it together as Map.
[18:02:20] <Krinkle>	<Krinkle> We could create a setInArray() prototype. But i feel as more of these small things pop up one ends up with a collection of prefixed prototypes when would be better off keeping it together as Map.
[18:03:11] <Krinkle>	And then there is ofcourse .lock() and .unlock() (not sure if those are in SVN yet, I think I didn't finish that yet)
[18:03:54] <Krinkle>	No, didn't write that yet. Need to look up why those were wanted.
[18:04:22] <flipzagging>	Krinkle: what's the purpose of lock or unlock?
[18:04:43] <flipzagging>	I'm going to guess it's to make sure some properties are read-only
[18:05:06] <Krinkle>	Well, what it would do is make the value read-only (ie. myMap.set( .., .. ) would not affect the values
[18:05:37] <flipzagging>	...
[18:05:56] <flipzagging>	yeah, i think this is a bit misguided
[18:06:52] <flipzagging>	if you have values you want not to be writable (and you really don't trust your own developers) then they should be parameters to whatever created the thing that needs immutable values.
[18:07:04] <flipzagging>	or you could just trust people not to be dumb
[18:07:49] <flipzagging>	example:  my configuredThing = thingCreator( config );
[18:08:01] <flipzagging>	er ignore the perlism there
[18:08:09] <Krinkle>	right
[18:08:15] <flipzagging>	var configuredThing = new thing( config );
[18:08:57] <flipzagging>	hey Roan
[18:08:57] <Krinkle>	RoanKattouw: http://prototype.wikimedia.org/logs/%23wikimedia-dev/20110128.txt
[18:09:03] <Krinkle>	Hi
[18:09:17] <RoanKattouw>	Morning
[18:09:34] <flipzagging>	Roan: mdale and I had a number of q's about mediawiki.js... some already discussed in the log Krinkle pointed to
[18:09:44] <RoanKattouw>	Approx timestamp?
[18:09:53] <flipzagging>	17:25
[18:09:54] <Krinkle>	[15:18:14 +
[18:10:09] <Krinkle>	oh my bad
[18:10:25] <Krinkle>	17:20 -ish indeed
[18:10:37] <RoanKattouw>	Tim wrote .html(), and he was totally right
[18:10:45] <RoanKattouw>	One reason is the img src loading thing
[18:11:29] <flipzagging>	what's bad about having preloaded images, though?
[18:11:32] <RoanKattouw>	The other is that it did strange things for unexpected input
[18:11:35] <flipzagging>	and what are the other use cases?
[18:11:47] <RoanKattouw>	Let me open my code editor and look at the function
[18:13:00] <RoanKattouw>	Hmm
[18:13:05] <RoanKattouw>	html.element does seem kind of useless
[18:13:10] <RoanKattouw>	Let me look at the commit log
[18:15:04] <RoanKattouw>	So one thing that's at least useful is the cdata thing
[18:15:09] <RoanKattouw>	I don't think jQuery lets you do that
[18:15:19] <RoanKattouw>	+					$( 'head' ).append( mediaWiki.html.element( 'style',
[18:15:21] <RoanKattouw>	+						{ type: 'text/css', media: media },
[18:15:22] <RoanKattouw>	+						new mediaWiki.html.Cdata( registry[module].style[media] )
[18:15:23] <RoanKattouw>	+					) );
[18:17:40] <flipzagging>	what's the benefit of CDATA there?
[18:18:10] <mdale>	your saying .. $('head').append( $('<style />').text( 'syle xyz; <script>alert('xss')<script>' )  ) ?
[18:18:11] <RoanKattouw>	You'd get strange escaping with normal .text() I guess
[18:18:21] <RoanKattouw>	No, that'll be safe
[18:18:24] <mdale>	yea
[18:18:27] <mdale>	so...
[18:18:29] <RoanKattouw>	Hmm so you know what I really have no clue what this is about
[18:18:34] <RoanKattouw>	We'd have to ask Tim
[18:35:02] <mdale>	RoanKattouw: one note about $('<img />').attr('src', 'imageLoadedOnFragmentCreation.jpg') issue .. as mentioned in the log there are plugins like jquery.lazyload to handle cases where you want to defer loading of images. So i don't think that should be used for an argument for html.element
[18:36:39] <RoanKattouw>	Right
[18:44:29] <Krinkle>	mdale: Does that also apply to newly created images ?
[18:44:57] <Krinkle>	lazyLoad is a plugin that stops all loading images in the passed selector and loads them when they appear from under the fold on-scroll.
[18:45:02] <mdale>	there is lots of ways that a framework could hanlde it
[18:45:04] <mdale>	handle it
[18:45:17] <mdale>	Krinkle: right
[18:45:28] <mdale>	or you could not set the src attribute until later
[18:45:42] <Krinkle>	Sure
[18:46:00] <mdale>	if you ~wanted~ that functionality
[19:38:35] <Krinkle>	RoanKattouw: Do you see any possibility of the search-api returning a value indicating the relevance ? (making it easier to mash together search results from multiple wikis)
[19:39:14] <RoanKattouw>	I don't know if the backend returns that. If it does, it can totally be added
[19:39:46] <Krinkle>	Would this differ per backend ? (ie. mw default or Lucene)
[19:40:10] <Krinkle>	I'm not sure how deep Lucene goes.
[19:40:45] <RoanKattouw>	Maybe it does, maybe it doesn't
[19:40:47] <RoanKattouw>	I don't know
[19:40:54] <RoanKattouw>	And I'm trying to do a zillion things right now
[19:40:58] <Krinkle>	k. I'll file a bug :)
[19:41:04] <RoanKattouw>	Yeah, please do
[19:41:19] <RoanKattouw>	Ryan_Lane: Bits rewrite rules work. You guys rock
[19:41:35] <Ryan_Lane>	\o/
[19:42:33] <brion>	well, lucene i believe does return relevance
[19:42:38] <brion>	mysql.... not sure if it does
[19:42:56] <brion>	don't we already have a relevancy figure in the ui returns when it's available?
[19:43:18] <brion>	maybe we took it out because the numbers were nigh-useless :D
[19:44:29] <Krinkle>	brion: Currently I see no such value returned anywhere in any way
[19:44:48] <Krinkle>	https://bugzilla.wikimedia.org/show_bug.cgi?id=27017
[19:45:41] <RoanKattouw>	Pfft, bugs are past 27k already?
[19:46:21] <brion>		function getScore() {
[19:46:21] <brion>			return null; // lucene scores are meaningless to the user...
[19:46:21] <brion>		}
[19:46:37] <brion>	indeed looks like we took em out
[19:47:28] <brion>	that's MWSearch's override of SearchResult's getScore() method (null by default)
[19:47:59] <brion>	looks like both Special:Search and API search query will make use of a score if it's provided
[19:48:07] <brion>	in ApiQuerySearch:
[19:48:08] <brion>					if ( !is_null( $result->getScore() ) && isset( $prop['score'] ) ) {
[19:48:08] <brion>						$vals['score'] = $result->getScore();
[19:48:08] <brion>					}
[19:48:39] <brion>	i'll stop pasting as it's a few more lines in SpecialSearch :)
[19:49:10] <Krinkle>	Nice
[19:49:34] <Krinkle>	so the front-end is in place. But the backend, was it null'ed or never there ?
[19:49:39] <Krinkle>	I'll look for myself :)
[19:49:53] <brion>	null'd over.
[19:50:02] <brion>	the value's all over the place in MWSearch, just take a peek
[19:50:20] <brion>	it's saved into a member variable, just not returned in getScore()
[19:50:25] <Krinkle>	 /includes/search/SearchPostgres.php does return something
[19:50:29] <Krinkle>	in getScore
[19:53:58] <Krinkle>	brion: This score-prop doesn't show up on wmf wikis though in the api.php documentation
[19:54:07] <Krinkle>	I guess it was somehow disabled or 1.17_
[19:54:21] <Krinkle>	it does in trunk
[19:54:27] <brion>	Krinkle, it doesn't show up because the backend doesn't report it
[19:54:37] <Krinkle>	I mean in the documentation, not in the results
[19:54:46] <brion>	i couldn't tell you nothin about documentation
[19:54:49] <Krinkle>	ie. under "  srprop         - What properties to return."
[19:54:53] <Krinkle>	http://www.mediawiki.org/w/api.php
[19:55:04] <Krinkle>	http://translatewiki.net/w/api.php?action=help&querymodules=search
[19:55:13] <brion>	well, go look at the code. what's it say?
[19:55:17] <Krinkle>	there are quite a few new ones
[19:56:33] <hexmode>	TrevorParscal is never around when I want him to be :(
[19:56:39] <Roan-lunch>	We're /just/ going to lunch
[19:56:41] <Roan-lunch>	It's 12:01
[19:56:49] <hexmode>	ok :)
[19:56:58] <hexmode>	Roan-lunch: holla when you get back
[20:35:09] <RoanKattouw>	hexmode: I'm back, Trevor isn't
[20:35:23] <RoanKattouw>	No idea where he is; CT and I went downstairs and there was no one there
[20:36:43] <werdna>	trevor was chatting to Anna upstairs
[20:37:23] <RoanKattouw>	Who's Anna? :D
[20:37:43] <werdna>	English volunteer lady who works here
[20:53:30] <hexmode>	RoanKattouw: how much do you know about RTL and ie6?
[20:53:37] <hexmode>	esp https://bugzilla.wikimedia.org/show_bug.cgi?id=26589
[20:53:49] <RoanKattouw>	hah
[20:53:50] <RoanKattouw>	Almost nothing
[20:54:05] <RoanKattouw>	That's really Trevor's thing
[20:54:11] <RoanKattouw>	He's back at his desk now
[20:54:14] <hexmode>	I'm thinking resource-loader may play a role here, but, well, I could be wrong
[20:54:19] <hexmode>	excellent!
[20:54:26] <RoanKattouw>	...but not on IRC
[20:54:38] <hexmode>	TrevorParscal: get on IRC
[20:54:48] <hexmode>	hrm... don't think that works
[20:56:19] <hexmode>	TrevorParscal: hey!
[20:56:28] <TrevorParscal>	howdy
[20:56:31] <hexmode>	have you looked at https://bugzilla.wikimedia.org/show_bug.cgi?id=26589
[20:56:33] <hexmode>	?
[20:58:50] <TrevorParscal>	testing
[21:14:15] <TrevorParscal>	hexmode: that bug is not relevant in the latest version of the software
[21:14:44] <hexmode>	of ResourceLoader or MW or both?
[21:14:59] <hexmode>	TrevorParscal: ^^
[21:15:26] <TrevorParscal>	the latest version of the Vector extension does not have those issues
[21:15:33] <TrevorParscal>	it happens to also depend on RL
[21:15:50] <TrevorParscal>	but they have a work around, so there's not much motivation to patch it
[21:15:52] <hexmode>	just saw your comment....
[21:16:37] <hexmode>	so, I think it should be closed, but "WORKSFORME" or "INVALID" or " ... " ?
[21:16:51] <RoanKattouw>	FIXED seems appropriate
[21:17:03] <RoanKattouw>	Was an issue before, not anymore, so it got fixed at some point
[21:17:21] <hexmode>	tyvm
[22:04:35] <Krinkle>	Hm.. secure.wm.o also has a link to /w in the root (rather than in the /project/lang/w directory). I see some scripts on commons use this to load bits.wm.o-ish stuff via secure.wm
[22:05:02] <RoanKattouw>	That sounds like a bad idea
[22:05:16] <Krinkle>	I wonder how this behaves. ie. what is $site and $wiki set to with ResourceLoader
[22:05:19] <RoanKattouw>	Or wait, if it's static files, it's probably a good idea
[22:05:26] <RoanKattouw>	Well yeah accessing load.php that way ain't gonna work
[22:05:51] <RoanKattouw>	But scripts don't need to know the URL to load.php , mw.loader abstracts that
[22:06:03] <Krinkle>	yeah
[22:06:17] <RoanKattouw>	It's gonna be bits.wikimedia.org/commons.wikimedia.org/load.php for http and secure.wm.o/wikipedia/commons/w/load.php on https
[22:06:44] <Krinkle>	so I guess there's no problems with load.php in secure right ? /project/lang/w/load.php will just w... ^^
[22:06:48] <Krinkle>	okay
[22:07:26] <Krinkle>	But if bits is going to support the domainname, is there an advantage in using bits ?
[22:07:54] <Krinkle>	other than it being a different hostname (more simultan http requests for browser)
[22:08:08] <RoanKattouw>	Yes, the fact that it uses Varnish
[22:08:17] <RoanKattouw>	Mark said that sending traffic to the normal URLs would melt the Amsterdam text Squids
[22:08:54] <Krinkle>	ah, so it's not just an internal direct. It's still fully bits-ified with the headers and the caching
[22:09:00] <Krinkle>	nice
[22:09:09] <RoanKattouw>	Yes
[22:09:13] <Krinkle>	Very nice.
[22:09:46] <RoanKattouw>	<Ryan_Lane>	# transform backend url: /<sitename>/load.php -> /w/load.php
[22:09:48] <RoanKattouw>	<Ryan_Lane>	# set host header for backend to <sitename>
[22:10:34] <Krinkle>	I'm currently attempting and thinking about getting some insight as to what legacy stuff is used accross wikis.
[22:11:09] <RoanKattouw>	That's a very useful endeavor, thanks for doing that
[22:11:18] <Krinkle>	A cross-wiki lucene front-end would really come in handy. But for now I'm hacking my own thing :P
[22:11:58] <Krinkle>	http://toolserver.org/~krinkle/CrossWikiSearch_dev.php?q=importScript#searchresults-mediawiki
[22:12:03] <Krinkle>	searches ns8 of 10 wikis
[22:13:29] <RoanKattouw>	I love how you just hack stuff together using JS and the TS whenever we don't support it :)
[22:13:41] <Krinkle>	I think especially the smaller wikis will have scripts from pre-2006 copied, via, via, via. Some old version of someting that once originated from meta or en.wiki
[22:13:59] <Krinkle>	RoanKattouw: yeah, I'm addicted to writing tools :P
[22:14:22] <bawolff>	Krinkle, honestly, non-english language wikis have scary mediawiki:Common.js files
[22:14:47] <Krinkle>	like a gazilion functions like function hasClass(); String.prototype.whatever etc.
[22:14:57] <Krinkle>	Oh yeah bawolff, very scary.
[22:15:04] <bawolff>	theres several that have errors in them, and don't work at all, and stop all js from working
[22:15:14] <Krinkle>	Some put the js in MediaWiki:common.css
[22:16:09] <bawolff>	just a couple weeks ago i saw that fa.wikinews.org had that old load an image from a toolserver, to give stats about page view scripts, even though that toolserver tool stopped working like a year before that wiki was created
[22:16:20] <Krinkle>	RoanKattouw: Any idea to to check for syntax errors somehow ? ie. some kind of virtual browser that visits all wmf wikis' front-page and see if there are any exceptions, errors. (real breakages)
[22:16:32] <Krinkle>	main-pages*
[22:16:44] <RoanKattouw>	No idea
[22:16:51] <RoanKattouw>	JS errors are usually runtime errors anyway
[22:16:57] <RoanKattouw>	Maybe a Selenium test could do it
[22:17:01] <mdale>	if we had working integration tests we could run thous across wikis.
[22:17:12] <RoanKattouw>	Not sure you can assert the absence of JS errors in Selenium, I've never worked with Se
[22:17:29] <Krinkle>	I mean like 404 errors or TypeErrors. Stuff Firebug would report.
[22:17:44] <RoanKattouw>	Right, that's all or mostly runtime
[22:17:53] *bawolff 	notes to himself that he should remove all the really scary document.write stuff in enwikinews's js before krinkle see's it ;)
[22:18:14] *RoanKattouw 	warns bawolff that document.write in site JS might break horribly with RL
[22:18:19] <RoanKattouw>	document.write is almost never a good idea
[22:18:21] *bawolff 	knows
[22:18:24] <Krinkle>	broken images in Common.css / monobook.css. TypeErrors in indirect scipts loaded via via importScript in Common.css
[22:18:27] <Krinkle>	stuff like that
[22:18:28] <RoanKattouw>	There is one case where it is, and RL abuses that
[22:19:00] <Krinkle>	document.write() only works before dom is ready. But problem is there are many cases where you think it's not but it is.
[22:19:23] <Krinkle>	For example when it's loaded through importScript, or getScript() inside addOnloadHook / jQuery(document).ready
[22:20:00] <RoanKattouw>	Yes
[22:20:01] <Krinkle>	if you do document.write('hello') in a .js file on Meta-Wiki and importScriptURI() on the first line of Common.js in 9/10 cases in WebKit you got a blank page.
[22:20:14] <Krinkle>	probably other browers too.
[22:20:29] <RoanKattouw>	I had to disable Drafts because it embedded <script>document.write(...)</script> in the edit page
[22:20:49] <RoanKattouw>	Which works on a normal edit page, but breaks horribly when the edit page is dynamically insereted by LiquidThreads
[22:21:10] <RoanKattouw>	Where "breaks horribly" means the entire page is replaced by a single, disabled (!) "Save draft" button
[22:21:13] <Krinkle>	Hm... RoanKattouw am I missing something or is there no "exact" search method ?
[22:21:36] <Krinkle>	I'm searching for "document.write" (both on-wiki and through API) and I'm getting a lot of false positives
[22:21:47] <Krinkle>	like jQuery(document.ready . foobar.write()
[22:22:13] <RoanKattouw>	How does that match document.write?
[22:22:33] <Krinkle>	it contains both "document" and "write"
[22:22:47] <RoanKattouw>	Can't you just search for the literal string 'document\.write' ?
[22:23:04] <RoanKattouw>	Maybe by using "document.write" if you're using Lucene
[22:23:10] <Krinkle>	http://meta.wikimedia.org/w/index.php?title=Special%3ASearch&search=%22document.write%22&ns8=1
[22:23:10] <RoanKattouw>	(with the double quotes)
[22:23:17] <Krinkle>	Nope, doesn't seem that way
[22:23:24] <RoanKattouw>	ugh
[22:23:30] <Krinkle>	the second result from the top
[22:23:40] <RoanKattouw>	heh, written by me
[22:23:43] <Krinkle>	jquery(<b>document</b>). ..... <b>write</b>
[22:23:47] <RoanKattouw>	yeah
[22:24:00] <Krinkle>	:(
[22:49:24] <Ryan_Lane>	RoanKattouw: can you tell me if my idea is sane: http://www.mediawiki.org/wiki/Extension:OpenStackManager#Configuration
[22:49:33] <Ryan_Lane>	specifically for $wgOpenStackManagerInstanceUserData
[22:50:02] <Ryan_Lane>	when an instance is created, these things will be added to the instance's user data
[22:50:23] <Ryan_Lane>	scripts and upstarts are added from the user data
[22:51:12] <Ryan_Lane>	I'm letting mediawiki admins configure the cloud-config (which sets up things like puppet, apt sources, etc.), and add scripts and upstart scripts
[22:51:31] <RoanKattouw>	Looks fine
[22:51:50] <RoanKattouw>	But since I have almost no background on this ext, I guess it's kinda hard to tell
[22:52:15] <Ryan_Lane>	I just want to make sure it is sane to tell people to write scripts as strings in variables
[22:52:38] <Ryan_Lane>	heredocs work well for that, but I'm wondering if it may be prone to misconfiguration
[22:54:13] <RoanKattouw>	Which language are these scripts going to be in?
[22:54:21] <Ryan_Lane>	they can be in any
[22:54:35] <RoanKattouw>	Right
[22:54:37] <Ryan_Lane>	php is likely a bad idea though
[22:54:45] <Ryan_Lane>	because they are shell scripts
[22:54:49] <RoanKattouw>	So Heredoc is gonna be a PITA for languages that use $ signs
[22:54:55] <Ryan_Lane>	upstart scripts are specifically upstart
[22:54:56] <Ryan_Lane>	ah
[22:55:04] <RoanKattouw>	You have to use \$ everywhere
[22:55:09] <Ryan_Lane>	that's annoying
[22:55:11] <RoanKattouw>	Is there a specific reason not to allow loading from a file?
[22:55:21] <Ryan_Lane>	that would work too
[22:55:53] *RoanKattouw 	disappears into a meeting
[22:56:04] <Ryan_Lane>	thanks
[22:56:14] <Ryan_Lane>	loading from a file is probably better
[22:58:56] <Krinkle>	Ryan_Lane: http://www.mediawiki.org/w/index.php?title=Extension:OpenStackManager&diff=prev&oldid=379385
[22:59:04] <Krinkle>	So it's not php ?
[22:59:47] <Ryan_Lane>	did I have bash? :)
[22:59:50] <Ryan_Lane>	heh
[22:59:56] <Ryan_Lane>	it's php
[22:59:59] <jorm>	you can haz bash
[23:00:12] <Ryan_Lane>	well, the configuration is definitely php
[23:00:16] <jorm>	HULK /bin/bash!
[23:00:25] <Ryan_Lane>	(I hate bash scripts)
[23:01:02] <jorm>	HULK BASH RYAN LANE!
[23:01:48] <Ryan_Lane>	cloud-init is pretty great :)
[23:02:18] <Krinkle>	Ryan_Lane: I wasn't sure since you mentioned allowing admins to configure it
[23:02:21] <werdna>	Ryan_Lane: Somebody I'm working with on a hosted-on-a-hosting-package website mentioned your extension the other day
[23:02:23] <Ryan_Lane>	I'm not going to have to create my own images
[23:02:28] <Krinkle>	thought perhaps it would be in a interface message or something.
[23:02:28] <Ryan_Lane>	hah
[23:02:29] <Ryan_Lane>	awesome
[23:02:44] <werdna>	"Came across this page also, http://ryandlane.com/blog/2011/01/02/building-a-test-and-development-infrastructure-using-openstack/
[23:02:47] <werdna>	An interesting development for providing a single seamless interface across multiple wikis."
[23:02:53] <Ryan_Lane>	Krinkle: ah. $wgOpenStackManagerInstanceUserData will have admin configured scripts
[23:02:54] *werdna 	sighs
[23:03:13] <Krinkle>	Okay, sounds pretty awesome.
[23:03:19] <Ryan_Lane>	single interface across wikis? :)
[23:03:32] <werdna>	yeah, that's what I thought
[23:03:44] <Ryan_Lane>	I haven't finished adding this feature yet. it's a PITA from a backend perspective
[23:04:02] <Ryan_Lane>	you have to take all of the scripts and the cloud-config yaml, and multipart-mime encode them
[23:04:26] <Ryan_Lane>	then gzip and base64 encode the entire thing