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

2011-04-10 Thread MediaWiki Mail
User Nikerabbit posted a comment on MediaWiki.r85558.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85558#c15831

Comment:

Why are you using php-cgi? cgi is not meant for command line scripts.

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


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

2011-04-10 Thread MediaWiki Mail
User Bryan changed the status of MediaWiki.r85756.

Old Status: new
New Status: fixme

User Bryan also posted a comment on MediaWiki.r85756.

Full URL: 
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85756#c15834

Comment:

Forgot to commit ApiImport.php?

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


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

2011-04-10 Thread MediaWiki Mail
User Reedy posted a comment on MediaWiki.r85756.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85756#c15835

Comment:

Nope, Brion already did it in r85585, but added no RELEASE-NOTES, so I just did 
it in the same commit, rather than a seperate one

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


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

2011-04-10 Thread MediaWiki Mail
User Platonides changed the status of MediaWiki.r85654.

Old Status: new
New Status: fixme

User Platonides also posted a comment on MediaWiki.r85654.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85654#c15836

Comment:

You forgot moving the global annotations:

Problems in phase3/tests/phpunit/includes/api/RandomImageGenerator.php:
 Unused global $wgUseImageMagick in function __construct line 38
 Unused global $wgImageMagickConvertCommand in function __construct line 38
 $wgUseImageMagick is used as local variable in line 88, function 
getImageWriteMethod
 $wgImageMagickConvertCommand is used as local variable in line 88, function 
getImageWriteMethod
 $wgImageMagickConvertCommand is used as local variable in line 88, function 
getImageWriteMethod

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


Re: [Wikitech-l] Actions and Special Pages

2011-04-10 Thread Martijn Hoekstra
Come to think of it, it is probably even cleaner not to have any
default action. action=view is pretty clean IMO, cleaner than having
view as the only special case where no action or special page is
needed. Conceptually it is just another action.

On Sat, Apr 9, 2011 at 1:36 AM, Platonides platoni...@gmail.com wrote:
 I also think it's cleaner to make move an action than edit a Special page.


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


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


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

2011-04-10 Thread MediaWiki Mail
User Platonides posted a comment on MediaWiki.r85432.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85432#c15837

Comment:

Shouldn't that be UT'''F'''-8 ?

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


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

2011-04-10 Thread MediaWiki Mail
User Nikerabbit posted a comment on MediaWiki.r85432.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85432#c15838

Comment:

Yes.

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


Re: [Wikitech-l] Aquestion about templates parsing and caching

2011-04-10 Thread Roan Kattouw
2011/4/9 Platonides platoni...@gmail.com:
 Yes. Calling a template twice will only fetch the text once, won't
 increase the 'used templates' counter...
 Preprocessing of wikitext over a threshold is cached serialized (it's
 easier to reprocess if it's too small).

To clarify: there's an in-process cache, like Brion said, so a
template that is used twice on the same page is only fetched and
preprocessed once. However, this only applies to templates called with
no parameters. If the template is passed parameters, this in-process
cache won't be used, even if the same set of parameters is used twice.

What we store in memcached is a serialized version of the preprocessor
XML tree, keyed on the MD5 hash of the wikitext input, unless it's too
small, like Platonides said. This means that if the exact same input
is fed to the preprocessor twice, it will do part of the work only one
and cache the intermediate result.

Roan Kattouw (Catrope)

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


Re: [Wikitech-l] Aquestion about templates parsing and caching

2011-04-10 Thread Platonides
Roan Kattouw wrote:
 2011/4/9 Platonides platoni...@gmail.com:
 Yes. Calling a template twice will only fetch the text once, won't
 increase the 'used templates' counter...
 Preprocessing of wikitext over a threshold is cached serialized (it's
 easier to reprocess if it's too small).

 To clarify: there's an in-process cache, like Brion said, so a
 template that is used twice on the same page is only fetched and
 preprocessed once. However, this only applies to templates called with
 no parameters. If the template is passed parameters, this in-process
 cache won't be used, even if the same set of parameters is used twice.

I don't think so. The preprocess-to-tree is always the same, regardless
of the parameters, and it is always used. It is the expansion where
parameter change. I don't see that cache for parameterless templates,
maybe it's the mTplExpandCache?


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


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

2011-04-10 Thread MediaWiki Mail
User NeilK posted a comment on MediaWiki.r85654.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85654#c15839

Comment:

Thanks for the catch. Fixed in r85774.

Is there a way I can be alerted if a change I have made is causing tests to 
fail?


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


Re: [Wikitech-l] Aquestion about templates parsing and caching

2011-04-10 Thread Andrew Garrett
On Mon, Apr 11, 2011 at 5:59 AM, Roan Kattouw roan.katt...@gmail.com wrote:
 What we store in memcached is a serialized version of the preprocessor
 XML tree, keyed on the MD5 hash of the wikitext input, unless it's too
 small, like Platonides said. This means that if the exact same input
 is fed to the preprocessor twice, it will do part of the work only one
 and cache the intermediate result.

Yes, I implemented this with Tim's help to try to cut down on the CPU
load caused by lots of Cite templates, IIRC. If I recall correctly,
the performance benefit was not particularly substantial.

-- 
Andrew Garrett
http://werdn.us/

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


Re: [Wikitech-l] Aquestion about templates parsing and caching

2011-04-10 Thread Alex Brollo
2011/4/11 Andrew Garrett agarr...@wikimedia.org

 On Mon, Apr 11, 2011 at 5:59 AM, Roan Kattouw roan.katt...@gmail.com
 wrote:
  What we store in memcached is a serialized version of the preprocessor
  XML tree, keyed on the MD5 hash of the wikitext input, unless it's too
  small, like Platonides said. This means that if the exact same input
  is fed to the preprocessor twice, it will do part of the work only one
  and cache the intermediate result.

 Yes, I implemented this with Tim's help to try to cut down on the CPU
 load caused by lots of Cite templates, IIRC. If I recall correctly,
 the performance benefit was not particularly substantial.


Ok, coming bac to my idea of building small libraries of  work-specific
templates into a unique template doesn't seems a particularly brilliant
one; something that can be done only if templates merged into one are
simple, and few, and only for contributor's comfort, if any. Thanks for your
interest!

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


Re: [Wikitech-l] A question about templates parsing and caching

2011-04-10 Thread Tim Starling
On 11/04/11 06:32, Platonides wrote:
 Roan Kattouw wrote:
 2011/4/9 Platonidesplatoni...@gmail.com:
 Yes. Calling a template twice will only fetch the text once, won't
 increase the 'used templates' counter...
 Preprocessing of wikitext over a threshold is cached serialized (it's
 easier to reprocess if it's too small).

 To clarify: there's an in-process cache, like Brion said, so a
 template that is used twice on the same page is only fetched and
 preprocessed once. However, this only applies to templates called with
 no parameters. If the template is passed parameters, this in-process
 cache won't be used, even if the same set of parameters is used twice.

 I don't think so. The preprocess-to-tree is always the same, regardless
 of the parameters, and it is always used. It is the expansion where
 parameter change. I don't see that cache for parameterless templates,
 maybe it's the mTplExpandCache?

The stages are basically preprocessToObj() - expand() - internalParse().

preprocessToObj() is the parsing stage of the preprocessor. It is fast 
and easily cachable. It produces an object-based representation of the 
parse tree of the text of single article or template. This object 
representation is stored in a cache ($wgParser-mTplDomCache) which 
exists for the duration of a single article parse operation. It 
depends only on a single input string, it does not expand templates.

There is a persistent cache which stores the result of 
preprocessToObj() across multiple requests, however this provides only 
a small benefit.

expand() is slow. Its function is to take the parse tree of an 
article, and to expand the template invocations and parser functions 
that it sees to produce preprocessed wikitext.

There is a cache of the expand() step which persists for the duration 
of a single parse operation ($wgParser-mTplExpandCache), but it only 
operates on template invocations with no arguments, like {{!}}. It's 
possible in theory to cache the expand() results for templates with 
arguments, but I didn't do it because it looked like it would be 
difficult to efficiently hash the parse tree of the arguments in order 
to retrieve the correct entry from the cache. This would be a good 
project for future development work.

I think it's fair to constrain parser functions to require that they 
return the same result for the same arguments, during a single parse 
operation. That's all you need to do to have an effective expand() cache.

However, the benefit would be limited due to the dominance of 
infoboxes and navboxes which appear only once in each article. It's 
not guaranteed that the result of expand() will be the same when done 
at different times or in different articles.

internalParse() takes preprocessed wikitext and produces HTML. The 
final output is cached by the parser cache.

-- Tim Starling


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


Re: [Wikitech-l] A question about templates parsing and caching

2011-04-10 Thread Daniel Friesen
On 11-04-10 06:13 PM, Tim Starling wrote:
 [...]
 I think it's fair to constrain parser functions to require that they
 return the same result for the same arguments, during a single parse
 operation. That's all you need to do to have an effective expand() cache.
 [...]
 -- Tim Starling
That /might/ work nicely for #ask.
However Counter, ArrayExtension, Variables, Random, etc... won't play 
nicely with that.

Perhaps a way for parser functions to opt-in or opt-out. So we can 
exclude functions that .

Side thought... why a #switch library? What happened to the old 
{{Foo/{{{1}}}|...}} trick?

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


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


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

2011-04-10 Thread MediaWiki Mail
User Peachey88 posted a comment on MediaWiki.r83554.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83554#c15840

Comment:

Should we be styling this by default? in the same sense that we don't stylize 
the redirects by default either.

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


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

2011-04-10 Thread MediaWiki Mail
User Aaron Schulz posted a comment on MediaWiki.r85776.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85776#c15841

Comment:

This needs some code comments.

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