I've been spending much of the last few work days tidying up an update to our deployed codebase, which has been several weeks behind development for most components.
I'll want to start deploying this in the morning (Pacific time), so we'll have most of the day to poke around and fix up any problems on the sites... it's gonna be fun!
This'll primarily bring a lot of under-the-hood improvements, which'll let us start rolling out other fun things over the coming days/weeks including: * Daily updates of interface translations (LocalisationUpdate) * Updated PDF collection/book UI * major cleanup of maintenance scripts * foundation work for improved uploading support * foundation work for new UI stuff (JS2 / add media wizard / cool stuff from Usability team)
For those of you poking at the code, I've got the pre-deployment code currently sitting in the wmf-deployment-work branch; this'll get folded back over wmf-deployment when we're ready to go.
I believe all custom hacks from the current wmf-deployment branch have been either copied over or generalized and merged via trunk... Note I've held back updates on ProofreadPage and OggHandler for the moment, and we won't deploy the new JS2 code yet until we've shaken things down some more.
If there are any *critical* trunk fixes from the last few days (since r55160 trunk branch point) that need to be forward-ported before we start, or any other surprises, let's make sure we know about it soon. :)
-- brion
On 9/15/09 4:42 PM, brion@wikimedia.org wrote:
For those of you poking at the code, I've got the pre-deployment code currently sitting in the wmf-deployment-work branch; this'll get folded back over wmf-deployment when we're ready to go.
I have now swapped the new branch in over wmf-deployment.
Note that when svn up'ing your wmf-deployment checkouts, you might see some "tree conflicts" depending on your SVN version, as more extensions not used in live deployment have been trimmed out to simplify things.
You should be able to mass-fix those with something like:
svn -R resolve --accept=base .
Or just remove the extension dirs and re-'svn up' them.
-- brion
On 9/16/09 1:41 PM, Brion Vibber wrote:
On 9/15/09 4:42 PM, brion@wikimedia.org wrote:
For those of you poking at the code, I've got the pre-deployment code currently sitting in the wmf-deployment-work branch; this'll get folded back over wmf-deployment when we're ready to go.
I have now swapped the new branch in over wmf-deployment.
Updated tree is now on http://test.wikipedia.org/
We've sorted out the issue where you only got old JS and CSS on test now too, so it should pretty much work. :) Please help bash at it for a few minutes!
Note that updates to some extensions have been held back temporarily pending further fixes: * Collection * ProofreadPage * OggHandler and the new JS2 code isn't enabled yet.
It shouldn't look too different for users yet until more of those things start getting deployed. :)
-- brion
On Wed, Sep 16, 2009 at 6:35 PM, Brion Vibber brion@wikimedia.org wrote:
Updated tree is now on http://test.wikipedia.org/
Spot the error here:
<div class='generated-sidebar portlet' id='p-navigation'Array>
Also:
<input type="submit" value="Submit" id="submitfeedback" accesskey="&lt;readerfeedback-ak-review&gt;" title="&lt;readerfeedback-tt-review&gt; [&lt;readerfeedback-ak-review&gt;]" />
And:
<a xmlns:cc="http://creativecommons.org/ns#" href="http://en.wikipedia.org/w/index.php?title=Main_Page&action=history" property="cc:attributionName" rel="cc:attributionURL">
(& in href instead of &)
Don't know how much of this is caused by the new software deployment, I just tried validating it:
http://validator.nu/?doc=http%3A%2F%2Ftest.wikipedia.org
(I'd try fixing some of these, but I'm at school right now, so it would require some tunneling to get my dev wiki, and I'm about to head home and go to bed.)
Ok, most of the biggies have been shaken out. Will take another peek after dinner to see if we have more fixes to sync. :)
-- brion
Hi,
Something bad happened, having to do with the "legend" junk add to RC and similar pages. Firefox will go compute bound (or very nearly) as long as the page is open, even if hours.
It isn't java/javascript (first suspect ;-), turning them off has no effect. It doesn't quite happen with 50 changes shown, always happens with 100 or more. Long pages without the cruft (eg. http://en.wiktionary.org/wiki/Special:Contributions/93.152.180.56 ) don't cause the problem.
WinXP updated to current, FF at 3.5.1 and 3.5.2.
Is there a way to turn that added stuff off? It is pure noise, not helpful at all. (yes, css display:none, but must everyone do that?)
best, Robert
On Thu, Sep 17, 2009 at 4:33 AM, Brion Vibber brion@wikimedia.org wrote:
Ok, most of the biggies have been shaken out. Will take another peek after dinner to see if we have more fixes to sync. :)
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Sep 17, 2009 at 6:59 AM, Robert Ullmann rlullmann@gmail.com wrote:
Something bad happened, having to do with the "legend" junk add to RC and similar pages. Firefox will go compute bound (or very nearly) as long as the page is open, even if hours.
It isn't java/javascript (first suspect ;-), turning them off has no effect. It doesn't quite happen with 50 changes shown, always happens with 100 or more. Long pages without the cruft (eg. http://en.wiktionary.org/wiki/Special:Contributions/93.152.180.56 ) don't cause the problem.
WinXP updated to current, FF at 3.5.1 and 3.5.2.
I don't see what could cause this. I can't reproduce on Firefox 3.0.12 on RHEL 5. Does it happen on a fresh profile or on other machines? Does it go away if you hide some things with CSS? If so, what rules make it stop?
Is there a way to turn that added stuff off? It is pure noise, not helpful at all. (yes, css display:none, but must everyone do that?)
No, this is not something that justifies a user preference. It's one line and some tooltips. If it's actually causing significant problems for some users, most likely we'd just remove it altogether (and report a bug to Mozilla if appropriate).
Robert Ullmann wrote:
Hi,
Something bad happened, having to do with the "legend" junk add to RC and similar pages. Firefox will go compute bound (or very nearly) as long as the page is open, even if hours.
It isn't java/javascript (first suspect ;-), turning them off has no effect. It doesn't quite happen with 50 changes shown, always happens with 100 or more. Long pages without the cruft (eg. http://en.wiktionary.org/wiki/Special:Contributions/93.152.180.56 ) don't cause the problem.
WinXP updated to current, FF at 3.5.1 and 3.5.2.
Is there a way to turn that added stuff off? It is pure noise, not helpful at all. (yes, css display:none, but must everyone do that?)
best, Robert
Can't reproduce. Where *is* it happening? http://en.wiktionary.org/wiki/Special:RecentChanges ?
It is happening on WinXP, FF 3.5.1, 3.5.2, 3.5.3, on "clean" setup as well.
It is apparently specific to Windows (not surprising), and is some side effect of the ABBR element; using lots and lots on a page causes endless or nearly endless CPU.
Attempting to turn it off with "abbr { display:none; }" makes it worse: it is then 100% CPU instead of 95-97%. FF renders the page, then goes back and re-renders the first occurrence of each ABBR element with a superscript giving the expansion. I suspect it is doing this (re-render) for all of the elements on the page, so with more than a few it goes CPU bound for a long time. But also in some way worse than that, since it doesn't stop. (quadratic with number of the elements? ;-)
Makes RC and watchlist unusable for now.
(mozilla seems to be susceptible to going CPU bound and thrashing VM under various odd conditions, almost always on Windoze ;-)
Best, Robert
On Thu, Sep 17, 2009 at 11:20 PM, Platonides Platonides@gmail.com wrote:
Robert Ullmann wrote:
Hi,
Something bad happened, having to do with the "legend" junk add to RC and similar pages. Firefox will go compute bound (or very nearly) as long as the page is open, even if hours.
It isn't java/javascript (first suspect ;-), turning them off has no effect. It doesn't quite happen with 50 changes shown, always happens with 100 or more. Long pages without the cruft (eg. http://en.wiktionary.org/wiki/Special:Contributions/93.152.180.56 ) don't cause the problem.
WinXP updated to current, FF at 3.5.1 and 3.5.2.
Is there a way to turn that added stuff off? It is pure noise, not helpful at all. (yes, css display:none, but must everyone do that?)
best, Robert
Can't reproduce. Where *is* it happening? http://en.wiktionary.org/wiki/Special:RecentChanges ?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, Sep 20, 2009 at 6:03 AM, Robert Ullmann rlullmann@gmail.com wrote:
It is happening on WinXP, FF 3.5.1, 3.5.2, 3.5.3, on "clean" setup as well.
It is apparently specific to Windows (not surprising), and is some side effect of the ABBR element; using lots and lots on a page causes endless or nearly endless CPU.
Attempting to turn it off with "abbr { display:none; }" makes it worse: it is then 100% CPU instead of 95-97%. FF renders the page, then goes back and re-renders the first occurrence of each ABBR element with a superscript giving the expansion. I suspect it is doing this (re-render) for all of the elements on the page, so with more than a few it goes CPU bound for a long time. But also in some way worse than that, since it doesn't stop. (quadratic with number of the elements? ;-)
Makes RC and watchlist unusable for now.
(mozilla seems to be susceptible to going CPU bound and thrashing VM under various odd conditions, almost always on Windoze ;-)
I've been meaning to investigate this, but haven't found the time yet. Have you come up with a minimal test case, or filed a bug with Mozilla? I'd be willing to look at this if I get the time, but I don't know how soon I will get the time, so it would help if someone else tried to debug it. Does it occur if you turn off JavaScript and/or CSS?
Aryeh Gregor wrote:
I've been meaning to investigate this, but haven't found the time yet. Have you come up with a minimal test case, or filed a bug with Mozilla? I'd be willing to look at this if I get the time, but I don't know how soon I will get the time, so it would help if someone else tried to debug it. Does it occur if you turn off JavaScript and/or CSS?
I tried with Firefox 3.5.2 on XP and still couldn't reproduce it. Reloading the page produced a CPU spike but nothing which lead me to attribute it to the reported behavior and not a normal rendering. I wonder if there might be an extension/badware checking all abbr to include ads on relevant keywords.
Hi,
On Wed, Sep 23, 2009 at 8:28 PM, Platonides Platonides@gmail.com wrote:
Aryeh Gregor wrote:
I've been meaning to investigate this, but haven't found the time yet. Have you come up with a minimal test case, or filed a bug with Mozilla? I'd be willing to look at this if I get the time, but I don't know how soon I will get the time, so it would help if someone else tried to debug it. Does it occur if you turn off JavaScript and/or CSS?
I tried with Firefox 3.5.2 on XP and still couldn't reproduce it. Reloading the page produced a CPU spike but nothing which lead me to attribute it to the reported behavior and not a normal rendering. I wonder if there might be an extension/badware checking all abbr to include ads on relevant keywords.
Got it; it had to be something not everyone was using (else everyone would be screaming), so I went back though my standard set of stuff (several font sets, other stuff, wasn't java/js/css).
On the wiktionary (and for some things on the 'pedia), Ruby support is useful, so I have the extension. But it also has the serious mis-feature of trying to "improve" on abbr tags, and a serious bug when there are lots of them.
Fix is to disable the Ruby extension, or edit "about:config" and change "rubysupport.expand.list" to remove "abbr".
Should be noted somewhere (and reported as a bug on the extension, but I have no idea where to do that).
Thanks for your help, Robert
On 9/28/09 7:57 AM, Robert Ullmann wrote:
On the wiktionary (and for some things on the 'pedia), Ruby support is useful, so I have the extension. But it also has the serious mis-feature of trying to "improve" on abbr tags, and a serious bug when there are lots of them.
Fix is to disable the Ruby extension, or edit "about:config" and change "rubysupport.expand.list" to remove "abbr".
Should be noted somewhere (and reported as a bug on the extension, but I have no idea where to do that).
If it's this extension, it looks like there's a support board or you can e-mail the author directly with bug reports; links are on this page:
http://piro.sakura.ne.jp/xul/_rubysupport.html.en
And I'll have to try that ext out sometime... wacky Japanese ruby fun! :D
-- brion
Spent some time this afternoon tracking down the problems breaking upload bot tools; confirmed Commonist and CommonsHelper fixed after relaxing the edittoken check for web file uploads:
http://techblog.wikimedia.org/2009/09/commonist-commonshelper-fixed/
-- brion
wikitech-l@lists.wikimedia.org