[Wikitech-l] Haifa Hackathon schedule / Lightning talks proposals

[Amir E. Aharoni]

Shalom all,

A draft schedule for the Haifa Hackathon has been published:
http://wikimania2011.wikimedia.org/wiki/Developer_Days

Some last details are being worked out. In particular, there are still
many slots for 5-minute lightning talks every hour. Many of the topics
listed under the "Topics" heading on that page can be subjects of
lightning talks, so if you can present it as a lightning, please add
it at the bottom.

See you in Haifa... in two days!!

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r93573]: New comment added

[MediaWiki Mail]

User "Peachey88" posted a comment on MediaWiki.r93573.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93573#c20319
Commit summary:

Added README file.

Comment:

Probably be better if you wrapped your text at either 72 or 80 characters per 
line.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93174]: New comment added

[MediaWiki Mail]

User "Jlemley" posted a comment on MediaWiki.r93174.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93174#c20318
Commit summary:

Followup r93154: Tweak extension credits and message files for consisteny
Add extension to Translatewiki

Comment:

Can this be marked as resolved?  See r93334.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93564]: Revision status changed

[MediaWiki Mail]

User "^demon" changed the status of MediaWiki.r93564.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93564#c0
Commit summary:

MFT r93563: (bug 30131) XCache with variable caching disabled no longer used 
for variable caching (CACHE_ACCEL)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93563]: Revision status changed

[MediaWiki Mail]

User "^demon" changed the status of MediaWiki.r93563.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93563#c0
Commit summary:

* (bug 30131) XCache with variable caching disabled no longer used for variable 
caching (CACHE_ACCEL)

Patch from John Du Hart: 
https://bugzilla.wikimedia.org/attachment.cgi?id=8849&action=diff

If XCache is present, but the xcache.var_size setting is off, we'll now 
consider it as xcache being disabled for CACHE_ACCEL purposes. It won't trigger 
view of the accelerator option in the installer, and at runtime if using 
CACHE_ACCEL and no other modules are available, it'll throw an error so you 
know that it doesn't work!

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93566]: New comment added

[MediaWiki Mail]

User "Kaldari" posted a comment on MediaWiki.r93566.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93566#c20317
Commit summary:

fix for Bug 30139 - JS error in Chrome

Comment:

Actually, I just realized someone might set landingPages equal to 'false' or 
'0' or something (as unlikely as that may be), so I've replaced this with 
r93567.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93397]: Revision status changed

[MediaWiki Mail]

User "MarkAHershberger" changed the status of MediaWiki.r93397.

Old Status: fixme
New Status: new

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93397#c0
Commit summary:

Reduce mail header differences by moving all the header creation code
to one place.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93563]: New comment added

[MediaWiki Mail]

User "Brion VIBBER" posted a comment on MediaWiki.r93563.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93563#c20316
Commit summary:

* (bug 30131) XCache with variable caching disabled no longer used for variable 
caching (CACHE_ACCEL)

Patch from John Du Hart: 
https://bugzilla.wikimedia.org/attachment.cgi?id=8849&action=diff

If XCache is present, but the xcache.var_size setting is off, we'll now 
consider it as xcache being disabled for CACHE_ACCEL purposes. It won't trigger 
view of the accelerator option in the installer, and at runtime if using 
CACHE_ACCEL and no other modules are available, it'll throw an error so you 
know that it doesn't work!

Comment:

Took the liberty of doing it for 1.18 in r93564.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93563]: New comment added

[MediaWiki Mail]

User "Brion VIBBER" posted a comment on MediaWiki.r93563.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93563#c20315
Commit summary:

* (bug 30131) XCache with variable caching disabled no longer used for variable 
caching (CACHE_ACCEL)

Patch from John Du Hart: 
https://bugzilla.wikimedia.org/attachment.cgi?id=8849&action=diff

If XCache is present, but the xcache.var_size setting is off, we'll now 
consider it as xcache being disabled for CACHE_ACCEL purposes. It won't trigger 
view of the accelerator option in the installer, and at runtime if using 
CACHE_ACCEL and no other modules are available, it'll throw an error so you 
know that it doesn't work!

Comment:

Recommend for merge to 1.18 (hence putting it in the 1.18 release notes ;) and 
to 1.17 (where it'd go out in the next bugfix update).

No need to copy it to 1.17wmf1 manually -- we don't use xcache in production.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] FW: [SMW-devel] SMW Selenium system tests available

[Benedikt Kämpgen]

Thanks, Sumana, for giving me this hint, that I now finally follow:

We have made available Selenium tests for Semantic MediaWiki (see email
below).

Regards,

Benedikt

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946 
Email: benedikt.kaemp...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en 



-Original Message-
From: Benedikt Kämpgen [mailto:benedikt.kaemp...@kit.edu] 
Sent: Wednesday, July 20, 2011 2:14 AM
To: Semantic MediaWiki developers; Krzysztof Krzyżaniak
Subject: [SMW-devel] SMW Selenium system tests available

Hello,

Semantic MediaWiki is now ready to be tested using Selenium, e.g., for
regression tests after code changes:

* We have uploaded one test suite with several test cases to
SemanticMediaWiki/tests/selenium/suites.
* We plan to upload more. 
* For information of how to use the test suite, see our updated
documentation at [1].
* We rely on the Selenium Framework [2] recently provided by MediaWiki. 

The Wikimedia Foundation has not yet decided, whether it will continuously
support this Selenium Framework. Still, we think Selenium system testing has
potential for two reasons:

* With Selenium IDE [3], it is very easy to create system tests, even for
less technically-skilled or SMW-experienced people.
* Also more complex Selenium system tests are possible, though in this case
writing PHP code will be needed.

We'd be happy to hear about your experiences.

Best,
Benedikt

[1] http://www.semantic-mediawiki.org/wiki/SMW_System_Testing_with_Selenium
[2] http://www.mediawiki.org/wiki/Selenium_Framework
[3] http://seleniumhq.org/projects/ide/ 

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946
Email: benedikt.kaemp...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mysql_* functions and MediaWiki

[Domas Mituzas]

> c) Both PDO and MySQLi support "prepared" statements, which could let us 
> introduce a form of statement cache so that if we need to execute the 
> same query multiple times except with different parameters, there is 
> less overhead involved since the statement is already prepared and just 
> needs the data values to use.

That statement cache needs persistent connections, which are somewhat 
expensive. 
Otherwise you're doing two roundtrips instead of one, and there's not much 
performance win anyway.

> Another bonus of prepared statements is 
> that it properly escapes everything according to whatever database 
> engine you happen to be using when you substitute in parameters.

I don't think that has been an issue lately.

Domas


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mysql_* functions and MediaWiki

[Platonides]

John Du Hart wrote:
> Earlier this month, the PHP developer team moved to start soft deprecating
> the mysql.so extension via documentation, with a intent to fully
> E_DEPRECATED in a later release. [1] Therefore, I thought it would be
> appropriate to start a small discussion as to how this should be handled.


The goal is to recommend alternatives that would make new code use the 
other options, due to security issues with most mysql code.
Given that mediawiki uses a wrapper which escapes the variables, I see 
no hurry in adding a  mysqli implementation.


> At the current moment, MediaWiki is still using these functions in its
> DatabaseMysql class. Being a new contributor to MW this came across as odd
> as to why no MySQLi implementation was available, so I went ahead and
> created one [2] (Patch [3]).
There was no need for it.

> Right now it's just another $wgDBtype, how it
> should really be integrated is what I want to discuss. Should any
> implementation (not necessarily mine) using MySQLi just be another DBType in
> the installer perhaps? (Most software I've seen goes this route)
Yes. Having it as another $wgDBtype is the right way (perhaps with a 
common parent for both mysql classes?).

> Also, at
> what point (time or event) do we do away with mysql function support? Also,
> are there any performance regressions with MySQLi that we should be aware
> about?

Probably, some time after mysql is removed from php, which could never 
happen.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r93343]: New comment added

[MediaWiki Mail]

User "Platonides" posted a comment on MediaWiki.r93343.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93343#c20314
Commit summary:

make sure sockets are enabled

Comment:

I was thinking in just sticking a wfDebug() call there.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] mysql_* functions and MediaWiki

[Ryan Schmidt]

On 7/30/2011 1:07 PM, John Du Hart wrote:
> Earlier this month, the PHP developer team moved to start soft deprecating
> the mysql.so extension via documentation, with a intent to fully
> E_DEPRECATED in a later release. [1] Therefore, I thought it would be
> appropriate to start a small discussion as to how this should be handled.
>
> At the current moment, MediaWiki is still using these functions in its
> DatabaseMysql class. Being a new contributor to MW this came across as odd
> as to why no MySQLi implementation was available, so I went ahead and
> created one [2] (Patch [3]). Right now it's just another $wgDBtype, how it
> should really be integrated is what I want to discuss. Should any
> implementation (not necessarily mine) using MySQLi just be another DBType in
> the installer perhaps? (Most software I've seen goes this route) Also, at
> what point (time or event) do we do away with mysql function support? Also,
> are there any performance regressions with MySQLi that we should be aware
> about?
>
> [1]: 
> http://marc.info/?l=php-internals&m=131031747409271&w=
> 2
> [2]:
> https://github.com/johnduhart/mediawiki-trunk-phase3/commit/552a90f5142bb108cb268e1e47da10351b4f873f
> [3]: https://gist.github.com/1115789

I'd like to see PDO support[1] in addition to MySQLi, reasons being is that:
a) PDO is a common interface for all types of databases (supports MySQL, 
Postgres, SQLite, and bunch of others) as long as the appropriate 
drivers are installed, which would allow us to cut down on the amount of 
code in the Database* classes considerably (to the point where most of 
the methods could probably be implemented in DatabaseBase without any issue)
b) PDO ships with PHP 5.1+ (and MediaWiki requres 5.2+), although it 
seems that only the SQLite driver is installed by default. Haven't 
checked packages to see what the various distros all enable yet.
c) Both PDO and MySQLi support "prepared" statements, which could let us 
introduce a form of statement cache so that if we need to execute the 
same query multiple times except with different parameters, there is 
less overhead involved since the statement is already prepared and just 
needs the data values to use. Another bonus of prepared statements is 
that it properly escapes everything according to whatever database 
engine you happen to be using when you substitute in parameters.
d) Supporting both PDO and MySQLi will allow MediaWiki to be installed 
in more server configurations, as some hosts may have one enabled but 
not the other.

I think that they should be considered separate db types as far as the 
installer is concerned so that users can choose between the one they 
wish to use (we can of course mark the old mysql one as "not 
recommended" to coerce users into picking one of the other two if they 
have them available for use).

[1] http://www.php.net/manual/en/book.pdo.php

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r93557]: New comment added

[MediaWiki Mail]

User "Siebrand" posted a comment on MediaWiki.r93557.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93557#c20313
Commit summary:

* Made OutputPage extend ContextSource instead of duplicating its code; this 
also adds getLang() that was missing
* Use getLang() instead of $wgLang

Comment:

Nice!

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93343]: New comment added

[MediaWiki Mail]

User "Kaldari" posted a comment on MediaWiki.r93343.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93343#c20312
Commit summary:

make sure sockets are enabled

Comment:

How do you do that?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] mysql_* functions and MediaWiki

[John Du Hart]

Earlier this month, the PHP developer team moved to start soft deprecating
the mysql.so extension via documentation, with a intent to fully
E_DEPRECATED in a later release. [1] Therefore, I thought it would be
appropriate to start a small discussion as to how this should be handled.

At the current moment, MediaWiki is still using these functions in its
DatabaseMysql class. Being a new contributor to MW this came across as odd
as to why no MySQLi implementation was available, so I went ahead and
created one [2] (Patch [3]). Right now it's just another $wgDBtype, how it
should really be integrated is what I want to discuss. Should any
implementation (not necessarily mine) using MySQLi just be another DBType in
the installer perhaps? (Most software I've seen goes this route) Also, at
what point (time or event) do we do away with mysql function support? Also,
are there any performance regressions with MySQLi that we should be aware
about?

[1]: 
http://marc.info/?l=php-internals&m=131031747409271&w=
2 
[2]:
https://github.com/johnduhart/mediawiki-trunk-phase3/commit/552a90f5142bb108cb268e1e47da10351b4f873f
[3]: https://gist.github.com/1115789

-- 
John
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r93539]: Revision status changed

[MediaWiki Mail]

User "Platonides" changed the status of MediaWiki.r93539.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93539#c0
Commit summary:

That branch isn't doing what I thought it might let me, typical

Kill it

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] "Ask the Developers" panel at Wikimania

[Daniel Kinzler]

Hi all!

Ask you may know, there will be an "Ask the Developers" panel at Wikimania.
However, there are no developers to ask, yet :)  To make this work, we need a
few lead WMF developers on the stage, ready to answer questions. So please let
me know if you would be willing to do that, or tell me who I could ask to take
part in the panel.

In any case I want to invite all developers to be there at least in the
audience, so specific questions can be answered directly by someone working on
that topic. Originally, this sessions was planned as a "fish bowl" type
discussion on Danes' suggestion, which would remove the distinction between
panelists and audience. But since she won't be there and I don't have any
experience with that kind of thing, it's going to be a regular panel.

The session is scheduled in the block starting on 10:15 on Friday. Shortly
before that, Guillome has his "Wikimedia technical staff vs. the_World" -
perhaps we could arrange to combine or rather links these two events? Have the
"ask the devs" basically as the discussion round to "staff vs. world"? What do
you think?

See you in Haifa, hopefully for the Hacking Days already

-- daniel

* http://wikimania2011.wikimedia.org/wiki/Submissions/Ask_the_Developers

*
http://wikimania2011.wikimedia.org/wiki/Submissions/Wikimedia_technical_staff_vs._the_World

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r93535]: Revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r93535.

Old Status: new
New Status: reverted

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93535#c0
Commit summary:

Rebranching iwtransclusion from r93533 in trunk

Gives stable working point for working from

Breaks unit tests as below, not going to be able to fix them before I disappear 
for the evening, so might aswell leave trunk clean

ArticleTablesTest testbug14404

Error:
ArticleTablesTest::testbug14404
Undefined offset: 0

/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/ArticleTablesTest.php:31
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiTestCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiPHPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.php:60

ParserTests testParserTest #552 - testParserTest with data set #551

Failure:
ParserTests::testParserTest with data set #551 ('RAW magic word', 
'{{RAW:QUERTY}}', 'Template:QUERTY
', '', '')
RAW magic word
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Template:QUERTY
+Template:RAW:QUERTY


/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/parser/NewParserTest.php:545
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiTestCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiPHPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.php:60

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93523]: New comment added

[MediaWiki Mail]

User "Jack Phoenix" posted a comment on MediaWiki.r93523.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93523#c20311
Commit summary:

Automatic Board Welcome extension -- automatically posts a welcome message on 
new users' user boards on account creation.
The message is sent by a randomly-chosen administrator (one who is a member of 
the 'sysop' group), who is not blocked.
Requires SocialProfile, obviously.

Comment:

If by recent you mean 1.17 or newer, I wouldn't worry too much about it since 
SocialProfile currently runs as intended only on 1.16. See also bug #29984.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93523]: New comment added

[MediaWiki Mail]

User "Jack Phoenix" posted a comment on MediaWiki.r93523.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93523#c20310
Commit summary:

Automatic Board Welcome extension -- automatically posts a welcome message on 
new users' user boards on account creation.
The message is sent by a randomly-chosen administrator (one who is a member of 
the 'sysop' group), who is not blocked.
Requires SocialProfile, obviously.

Comment:

Good catch, thanks! This should be fixed as of r93538.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93536]: New comment added

[MediaWiki Mail]

User "TheDJ" posted a comment on MediaWiki.r93536.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93536#c20309
Commit summary:

Make Back, Continue translatable.

Comment:

thx !

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93536]: Revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r93536.

Old Status: fixme
New Status: resolved

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93536#c0
Commit summary:

Make Back, Continue translatable.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93536]: New comment added, and revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r93536.

Old Status: new
New Status: fixme

User "Reedy" also posted a comment on MediaWiki.r93536.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93536#c20308
Commit summary:

Make Back, Continue translatable.

Comment:


'mobile-frontend-back-button' => 'Back',


exists, but 'mobile-frontend-wml-continue' and 'mobile-frontend-wml-back' 
doesn't

Did you mean to check in the .i18n file too?


___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93528]: New comment added

[MediaWiki Mail]

User "IAlex" posted a comment on MediaWiki.r93528.

Full URL: 
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/93528#c20307
Commit summary:

Added TitleBlacklist::singleton() to get an instance of the TitleBlacklist 
instead of having to use $wgTitleBlacklist and call efInitTitleBlacklist()

Comment:

No, with the "static" declaration of $instance, its value will be kept between 
calls.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93528]: New comment added

[MediaWiki Mail]

User "Siebrand" posted a comment on MediaWiki.r93528.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93528#c20306
Commit summary:

Added TitleBlacklist::singleton() to get an instance of the TitleBlacklist 
instead of having to use $wgTitleBlacklist and call efInitTitleBlacklist()

Comment:

Time to learn for me, or I may have spotted a bug :)

+    public static function singleton() {
+        static $instance = null;
+
+        if ( $instance === null ) {
+            $instance = new self;
+        }
+        return $instance;
+    }


If you set $instance to null each time, then will it not always === null?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] On refactorings and huge changes

[Platonides]

> PS: sorry for TLDR-ness... :-(

It was worth reading!
You make very good points.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please don't commit broken code

[Platonides]

Ashar Voultoiz wrote:
> On 29/07/11 02:05, MZMcBride wrote:
> 
>> Sometimes the only way people can get their code reviewed is to commit it.
>
> In a BRANCH! :-)
>
> Although, you will have to find out someone to review your changes, but
> at least it saves you the hassle of being reverted on sight.
>
> If you don't have commit access, use something like github.com which
> offers a friendly interface to comment on patch / fork etc ...

I don't mind if people provides sample in github or pastebin, but don't 
expect me to comment and follow up there (I might do, but don't take 
that for granted).
Those sites are designed to be the central place, but they are not for 
our community, so anything there will be less viewed than eg. a CR comment.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r93523]: New comment added

[MediaWiki Mail]

User "IAlex" posted a comment on MediaWiki.r93523.

Full URL: 
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/93523#c20305
Commit summary:

Automatic Board Welcome extension -- automatically posts a welcome message on 
new users' user boards on account creation.
The message is sent by a randomly-chosen administrator (one who is a member of 
the 'sysop' group), who is not blocked.
Requires SocialProfile, obviously.

Comment:

Unless I'm mistaken, the message is not sent at all if the user selected to 
send the message is blocked. Shouldn't the extension select another sysop in 
such case?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93523]: New comment added

[MediaWiki Mail]

User "Nikerabbit" posted a comment on MediaWiki.r93523.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93523#c20304
Commit summary:

Automatic Board Welcome extension -- automatically posts a welcome message on 
new users' user boards on account creation.
The message is sent by a randomly-chosen administrator (one who is a member of 
the 'sysop' group), who is not blocked.
Requires SocialProfile, obviously.

Comment:

Looks like that wfEmptyMsg call might fail in recent version of MediaWiki which 
ignores the second parameter and users interface language instead.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93503]: Revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r93503.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93503#c0
Commit summary:

Tag for version 0.4.9.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93507]: Revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r93507.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93507#c0
Commit summary:

Adding tag dir for Semantic Watchlist extension

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93291]: New comment added

[MediaWiki Mail]

User "Platonides" posted a comment on MediaWiki.r93291.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93291#c20303
Commit summary:

Unicode space separator characters (Zs) now terminates links

Fix 19052 which was only reporting the issue for U+3000 IDEOGRAPHIC SPACE.
Covers both external links and images links. See parser tests for examples.

Unicode 'Zs' includes all characters from the 'separator, space' category.
Characters part of this category are:

CharName
U+0020  SPACE
U+00A0  NO-BREAK SPACE
U+1680  OGHAM SPACE MARK
U+180E  MONGOLIAN VOWEL SEPARATOR
U+2000  EN QUAD
U+2001  EM QUAD
U+2002  EN SPACE
U+2003  EM SPACE
U+2004  THREE-PER-EM SPACE
U+2005  FOUR-PER-EM SPACE
U+2006  SIX-PER-EM SPACE
U+2007  FIGURE SPACE
U+2008  PUNCTUATION SPACE
U+2009  THIN SPACE
U+200A  HAIR SPACE
U+202F  NARROW NO-BREAK SPACE
U+205F  MEDIUM MATHEMATICAL SPACE
U+3000  IDEOGRAPHIC SPACE


TEST PLAN:

$ php parserTests.php --quiet
This is MediaWiki version 1.19alpha (r93258).

Reading tests from "tests/parser/parserTests.txt"...
Reading tests from "tests/parser/extraParserTests.txt"...
Reading tests from "../mwexts/LabeledSectionTransclusion/lstParserTests.txt"...
Passed 686 of 686 tests (100%)... ALL TESTS PASSED!

Sounds good :-)

Comment:

Running both regex against eswiki-20100926-pages-meta-history.xml.7z (36942737 
revisions)

CPU time with the old one: 342m45s
CPU time with this one: 401m33s

This change is quite slower.

I suspect the results would be worse with a Chinese or Korean wiki.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93343]: New comment added

[MediaWiki Mail]

User "Platonides" posted a comment on MediaWiki.r93343.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93343#c20302
Commit summary:

make sure sockets are enabled

Comment:

Shouldn't it log that it was configured to profile but it was not able to?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93520]: New comment added

[MediaWiki Mail]

User "Nikerabbit" posted a comment on MediaWiki.r93520.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93520#c20301
Commit summary:

:facepalm: Installer checked for magic_quotes_runtime instead of 
register_globals

Comment:

"The check for register_globals in installer was erroneously checking for 
magic_quotes_runtime instead."

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93520]: New comment added

[MediaWiki Mail]

User "MaxSem" posted a comment on MediaWiki.r93520.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93520#c20300
Commit summary:

:facepalm: Installer checked for magic_quotes_runtime instead of 
register_globals

Comment:

Where do they say that it doesn't check for magic_quotes_runtime anymore? :P

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93520]: New comment added

[MediaWiki Mail]

User "Nikerabbit" posted a comment on MediaWiki.r93520.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93520#c20299
Commit summary:

:facepalm: Installer checked for magic_quotes_runtime instead of 
register_globals

Comment:

Release notes are misleading (a bit), it still checks for magic_quotes_runtime.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93515]: New comment added

[MediaWiki Mail]

User "Dantman" posted a comment on MediaWiki.r93515.

Full URL: 
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/93515#c20298
Commit summary:

mediawiki.js request() caching deep level object member access.
- Instead of requesting index 0 of dependancies-argument, and the value of that 
of the registry, and the dependancies object in that of which we read the 
length property is very deep. Even worse when doing that both in the head and 
in the body of a for()-loop.
- Instead caching reference access to dependancies object of the registry item.
- Plus a simple by-value of the length property

Comment:

...and what happened to the standard arr.push(); Same for the other line, the 
more readable way to do this would be:

for ( var n = 0, regItemDepLen = regItemDeps.length; n < regItemDepLen; n++ ) {
  dependencies.push(regItemDeps[n]);
}


..though frankly, you could do this with either of these:

dependencies.push.apply(dependencies, regItemDeps); // efficient but perhaps a 
little advanced to read; I like to create an .append() method to make it 
readable.
dependencies = dependencies.concat(regItemDeps); // less efficient, more 
readable, may have side effects if the dependencies array is mentioned 
elsewhere.


Maybe something like mw.util.Array.append?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r93515]: New comment added

[MediaWiki Mail]

User "Nikerabbit" posted a comment on MediaWiki.r93515.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93515#c20297
Commit summary:

mediawiki.js request() caching deep level object member access.
- Instead of requesting index 0 of dependancies-argument, and the value of that 
of the registry, and the dependancies object in that of which we read the 
length property is very deep. Even worse when doing that both in the head and 
in the body of a for()-loop.
- Instead caching reference access to dependancies object of the registry item.
- Plus a simple by-value of the length property

Comment:

Why no ''var'' for regItemsDepLen?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r92112]: New comment added, and revision status changed

[MediaWiki Mail]

User "Krinkle" changed the status of MediaWiki.r92112.

Old Status: fixme
New Status: ok

User "Krinkle" also posted a comment on MediaWiki.r92112.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92112#c20296
Commit summary:

Rewrite ajaxCategories for ResourceLoader. Add some missing functionality (edit 
categories and more). Move styles from shared.css into own stylesheet. Fix 
regex bugs

Comment:

Addressed points related to the original script and the changes made here and 
in the follow-ups in r93351. Marking OK.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview