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

2011-04-11 Thread Alex Brollo
2011/4/11 Daniel Friesen li...@nadir-seen-fire.com


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


Simply,  {{Foo/{{{1}}}|...}} links to different pages, while
{{Foo|{{{1}}}|...}} points to the same page. I had been frustrated when I
tried to use Labeled Section Transclusion to build template libraries :-),
that would be an excellent way to build collection of objects into a wiki
page, both of  methods and attributes... ... but #lst doesn't parse raw
wiki code from scratch. If it would (t.i.: if #lst would read wiki code
as it is,  before any parsing of it, ignoring at all the code outside
labelled section: t.i. ignoring noinclude, html comment tags... anything)
interesting scenarios would raise.

But, if there's no performance gain with {{Foo|{{{1}}}|...}} trick, I'll use
{{Foo/{{{1}}}|...}} for sure. KISS is always a good guide line. :-)

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-11 Thread Daniel Friesen
On 11-04-11 12:05 AM, Alex Brollo wrote:
 2011/4/11 Daniel Friesenli...@nadir-seen-fire.com

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

 Simply,  {{Foo/{{{1}}}|...}} links to different pages, while
 {{Foo|{{{1}}}|...}} points to the same page. I had been frustrated when I
 tried to use Labeled Section Transclusion to build template libraries :-),
 that would be an excellent way to build collection of objects into a wiki
 page, both of  methods and attributes... ... but #lst doesn't parse raw
 wiki code from scratch. If it would (t.i.: if #lst would read wiki code
 as it is,  before any parsing of it, ignoring at all the code outside
 labelled section: t.i. ignoring noinclude, html comment tags... anything)
 interesting scenarios would raise.

 But, if there's no performance gain with {{Foo|{{{1}}}|...}} trick, I'll use
 {{Foo/{{{1}}}|...}} for sure. KISS is always a good guide line. :-)

 Alex
Pointing to different pages is essentially the point of the trick.
[[Template:Library]] = 
{{#ifexist:Library/{{{1}}}|{{Library/{{{1}}}|...}}|There is no library 
function by the name {{{1}}}.}}
[[Template:Library/a]] = Do a
[[Template:Library/b]] = Do b

{{library|a}} = Do a
{{library|b}} = Do b

It essentially works the same as:
[[Template:Library]] = {{#switch:{{{1}}}|a=Do a|b=Do b|There is no 
library function by the name {{{1}}}.}}

Except you don't create an obscenely large preprocessed hierarchy which 
is cloned in it's entirety to multiple places and expanded multiple 
times just to get access to multiple pieces of the library.


Though, when we're talking about stuff this complex... that line about 
using a REAL programming language comes into play...
Would be nice if there was some implemented-in-php language script 
language we could use that would work on any wiki. I had a project 
playing around with that idea but it's dead.

~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


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

2011-04-11 Thread Alex Brollo
2011/4/11 Daniel Friesen li...@nadir-seen-fire.com



 Though, when we're talking about stuff this complex... that line about
 using a REAL programming language comes into play...
 Would be nice if there was some implemented-in-php language script
 language we could use that would work on any wiki. I had a project
 playing around with that idea but it's dead.

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


Are you a wikisource contributor? If you are, I guess that you considered
too this syntax, pointing to what I wrote into my last message:
{{#section:Foo|{{{1} but... it refuses to run, if section {{{1}}} of
page Foo is a method (while its runs obviuosly if section is an
attribute). :-)

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-11 Thread Neil Harris
On 11/04/11 02:51, Daniel Friesen wrote:
 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]


I would have thought this could be done automatically, by designating 
templates as being pure or impure (in the sense of pure and impure 
functions) -- something which could be done recursively all the way down 
to basic parser functions, magic words, etc., which would have to be 
designated pure or impure by hand as part of the software implementation.

-- Neil


___
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