Re: [Wikitech-l] A potential land mine
dan nessett dness...@yahoo.com wrote in message
news:271560.93058...@web32504.mail.mud.yahoo.com...
Brion Vibber br...@wikimedia.org wrote:
Unless there's some reason to do otherwise, I'd recommend dropping the
$IP from the autogen'd LocalSettings.php and pulling in
DefaultSettings.php from the level above. (Keeping in mind that we
should retain compat with existing LocalSettings.php files that are
still pulling it.)
Better, but what about /config/index.php, noMediaWikiConfig.php,
validate.php
and Maintenance.php? Having only two different places where $IP is
computed
is a definite improvement (assuming you fix the 4 files just mentioned),
but it still
means the code in WebStart.php and Command.inc is file position dependent.
If this is the best that can be done, then that is that. However, it would
really be
better if all position dependent code could be eliminated.
To be honest, I don't know why there is more than one entry point at all.
Surely it would be better if all requests went through index.php:
?php
//index.php - the only MW entry point
// First, do all stuff that is always required.
$IP = realpath(dirname(__FILE__));
include($IP . /LocalSettings.php);
//...and any other actions that should be performed in all cases...
if ( !isset( $_SERVER ) || !array_key_exists( 'REQUEST_METHOD', $_SERVER ) )
{
include($IP . /maintenance/commandLine.inc);
return;
}
// Rest of index.php as current.
?
Any maintenance scripts would then include(../index.php) instead of
commandLine.inc, and voila - all code-duplication at the various entry
points has been removed.
- Mark Clements (HappyDog)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW test infrastructure architecture
Bryan Tong Minh bryan.tongm...@gmail.com wrote in message news:fd5886130908120137h13b0aad9xdd2f05c8a362c...@mail.gmail.com... On Wed, Aug 12, 2009 at 2:38 AM, Chadinnocentkil...@gmail.com wrote: My point is that not declaring visibility on new code (ie: leaving everything public) is poor form. It usually doesn't take very long to make the decision about what scope to put a function or variable in, and it can always be changed later if the choice was wrong. Well, you can always go up (privateprotectedpublic), but not necessarily go down without possibly breaking things you are unaware of. True - and not specifying a scope means the visibility defaults to public. Therefore requiring a scope to be declared can only be a good thing. - Mark Clements (HappyDog) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A potential land mine
On 20/08/2009, at 10:29 AM, Mark Clements (HappyDog) wrote:
To be honest, I don't know why there is more than one entry point at
all.
Surely it would be better if all requests went through index.php:
?php
//index.php - the only MW entry point
// First, do all stuff that is always required.
$IP = realpath(dirname(__FILE__));
include($IP . /LocalSettings.php);
//...and any other actions that should be performed in all cases...
if ( !isset( $_SERVER ) || !array_key_exists( 'REQUEST_METHOD',
$_SERVER ) )
{
include($IP . /maintenance/commandLine.inc);
return;
}
// Rest of index.php as current.
?
That's totally bizarre, why not just have both index.php and command-
line scripts include another file, like, say, Setup.php?
... Which is what we already do (although it's done from
commandLine.inc, because that has some useful stuff for command-line
scripts in it).
What problem are you trying to solve here?
--
Andrew Garrett
agarr...@wikimedia.org
http://werdn.us/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] CPRT feasibility
I am looking into the feasibility of writing a comprehensive parser regression test (CPRT). Before writing code, I thought I would try to get some idea of how well such a tool would perform and what gotchas might pop up. An easy first step is to run dump_HTML and capture some data and statistics. I tried to run the version of dumpHTML in r54724, but it failed. So, I went back to 1.14 and ran that version against a small personal wiki database I have. I did this to get an idea of what structures dump_HTML produces and also to get some performance data with which to do projections of runtime/resource usage. I ran dumpHTML twice using the same MW version and same database. I then diff'd the two directories produced. One would expect no differences, but that expectation is wrong. I got a bunch of diffs of the following form (I have put a newline between the two file names to shorten the line length): diff -r HTML_Dump/articles/d/n/e/User~Dnessett_Bref_Examples_Example1_Chapter_1_4083.html HTML_Dump2/articles/d/n/e/User~Dnessett_Bref_Examples_Example1_Chapter_1_4083.html 77,78c77,78 Post-expand include size: 16145/2097152 bytes Template argument size: 12139/2097152 bytes --- Post-expand include size: 16235/2097152 bytes Template argument size: 12151/2097152 bytes I looked at one of the html files to see where these differences appear. They occur in an html comment: !-- NewPP limit report Preprocessor node count: 1891/100 Post-expand include size: 16145/2097152 bytes Template argument size: 12139/2097152 bytes Expensive parser function count: 0/100 -- Does anyone have an idea of what this is for? Is there any way to configure MW so it isn't produced? I will post some performance data later. Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] CPRT feasibility
On 20/08/2009, at 6:19 PM, dan nessett wrote: !-- NewPP limit report Preprocessor node count: 1891/100 Post-expand include size: 16145/2097152 bytes Template argument size: 12139/2097152 bytes Expensive parser function count: 0/100 -- Does anyone have an idea of what this is for? Is there any way to configure MW so it isn't produced? As the title implies, it is a performance limit report. You can remove it by changing the parser options passed to the parser. Look at the ParserOptions and Parser classes. -- Andrew Garrett agarr...@wikimedia.org http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] CPRT feasibility
--- On Thu, 8/20/09, Andrew Garrett agarr...@wikimedia.org wrote: As the title implies, it is a performance limit report. You can remove it by changing the parser options passed to the parser. Look at the ParserOptions and Parser classes. Thanks. It appears dumpHTML has no command option to turn off this report (the parser option is mEnableLimitReport). A question to the developer community: Is it better to change dumpHTML to accept a new option (to turn off Limit Reports) or copy dumpHTML into a new CPRT extension and change it. I strongly feel that having two extensions with essentially the same functionality is bad practice. On the other hand, changing dumpHTML means it becomes dual purposed, which has the potential of making it big and ugly. One compromise position is to attempt to factor dumpHTML so that a core provides common functionality to two different upper layers. However, I don't know if that is acceptable practice for extensions. A short term fix is to pipe the output of dumpHTML through a filter that removes the Limit Report. That would allow developers to use dumpHTML (as a CPRT) fairly quickly to find and fix the known-to-fail parser bugs. The downside to this is it may significantly degrade performance. Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Browser sniffing in JavaScript (and elsewhere)
On Mon, Aug 17, 2009 at 12:30 PM, Roan Kattouwroan.katt...@gmail.com wrote:
Both the usabilty and new upload JS use jQuery, which hides most
browser sniffing you need in abstraction layers. To my knowledge the
jQuery devs do sniff browsers properly, and if something should go
wrong in jQuery, it's not just Wikipedia that'll break.
This doesn't look like doing things properly to me:
js/js2/jquery-ui-1.7.2.js- // Prevent text selection in IE
js/js2/jquery-ui-1.7.2.js: if ($.browser.msie) {
js/js2/jquery-ui-1.7.2.js-
this._mouseUnselectable = this.element.attr('unselectable');
js/js2/jquery-ui-1.7.2.js-
this.element.attr('unselectable', 'on');
js/js2/jquery-ui-1.7.2.js- }
js/js2/jquery-ui-1.7.2.js- // preventDefault() is used to
prevent the selection of text here -
js/js2/jquery-ui-1.7.2.js- // however, in Safari, this
causes select boxes not to be selectable
js/js2/jquery-ui-1.7.2.js- // anymore, so this fix is needed
js/js2/jquery-ui-1.7.2.js: ($.browser.safari ||
event.preventDefault());
js/js2/jquery-ui-1.7.2.js- return {
js/js2/jquery-ui-1.7.2.js- top: (
js/js2/jquery-ui-1.7.2.js- pos.top
// The absolute mouse position
js/js2/jquery-ui-1.7.2.js- +
this.offset.relative.top * mod
// Only for relative positioned nodes: Relative offset
from element to offset parent
js/js2/jquery-ui-1.7.2.js- +
this.offset.parent.top * mod
// The offsetParent's offset without borders (offset + border)
js/js2/jquery-ui-1.7.2.js: -
($.browser.safari this.cssPosition == 'fixed' ? 0 : (
this.cssPosition == 'fixed' ? -this.scrollParent.scrollTop() : (
scrollIsRootNode ? 0 : scroll.scrollTop() ) ) * mod)
js/js2/jquery-ui-1.7.2.js- ),
js/js2/jquery-ui-1.7.2.js- left: (
js/js2/jquery-ui-1.7.2.js- pos.left
// The absolute mouse position
js/js2/jquery-ui-1.7.2.js- +
this.offset.relative.left * mod
// Only for relative positioned nodes: Relative offset
from element to offset parent
js/js2/jquery-ui-1.7.2.js- +
this.offset.parent.left * mod
// The offsetParent's offset without borders (offset + border)
js/js2/jquery-ui-1.7.2.js: -
($.browser.safari this.cssPosition == 'fixed' ? 0 : (
this.cssPosition == 'fixed' ? -this.scrollParent.scrollLeft() :
scrollIsRootNode ? 0 : scroll.scrollLeft() ) * mod)
js/js2/jquery-ui-1.7.2.js- )
js/js2/jquery-ui-1.7.2.js- };
js/js2/jquery-ui-1.7.2.js-
js/js2/jquery-ui-1.7.2.js- },
js/js2/jquery-ui-1.7.2.js- //Opera fix for
relative positioning
js/js2/jquery-ui-1.7.2.js: if
(/relative/.test(this.element.css('position')) $.browser.opera)
js/js2/jquery-ui-1.7.2.js-
this.element.css({ position: 'relative', top: 'auto', left: 'auto' });
js/js2/jquery-ui-1.7.2.js- // Prevent IE from
keeping other link focussed when using the back button
js/js2/jquery-ui-1.7.2.js- // and remove dotted
border from clicked link. This is controlled via CSS
js/js2/jquery-ui-1.7.2.js- // in modern browsers;
blur() removes focus from address bar in Firefox
js/js2/jquery-ui-1.7.2.js- // which can become a
usability and annoying problem with tabs('rotate').
js/js2/jquery-ui-1.7.2.js: if ($.browser.msie) {
js/js2/jquery-ui-1.7.2.js- this.blur();
js/js2/jquery-ui-1.7.2.js- }
etc. There are lots more like that. And that's only one file, and
only the ones that looked like they were clearly wrong. It seems to
be part of jQuery itself and not our code, but there are examples from
our code too. Like r55269, which I've already commented on.
(Although it apparently was already scapped less than two hours after
it was committed, before I or probably almost anyone else had a chance
to look at it, when we have thousands of commits dating back more than
two months that are still not live?)
We have some things in core as well, like this in wikibits.js:
if (is_gecko) {
// Mozilla needs to wait until after load, otherwise the
window doesn't scroll
addOnloadHook(function () {
if (window.location.hash == )
window.location.hash = fragment;
});
} else {
Is this necessary for recent FF versions? I don't know. From looking
at it, it will degrade the user experience, causing a jump possibly
even after the user has already started scrolling.
___
Wikitech-l mailing list
