headers
Aryeh Gregor | 1 Feb 2009 02:03
Picon

Re: war on Cite/{{cite}}

On Sat, Jan 31, 2009 at 8:03 AM, Domas Mituzas <midom.lists <at> gmail.com> wrote:
> [  ] - Implement proper scripting engine like Lua for metatemplates (http://pecl.php.net/package/lua
>  - another can of worms, though yet again, can be managed via trusted
> set of people, on top20 wikis or so).

This seems like it's the only solution from your list that would be
generally applicable to similar future scenarios.  I don't think the
users would have to be particularly trusted -- just make sure that the
runtime of the programs is limited, and that it's properly sandboxed
(is the Lua PECL extension sandboxed?).

Another thought that occurs to me is to cache the output of templates
as a function of their parameters and any appropriate variables they
use (like {{PAGENAME}} or {{CURRENTDAY}}).  Then a reparse of a
template-heavy page will generally only have to reparse templates if
the parameters to the template have changed.  This will save a lot on
Cite, infoboxes, etc.
Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 1 Feb 2009 02:04
Picon

Re: ordered lists starting at a certain number

On Sat, Jan 31, 2009 at 4:23 PM,  <jidanni <at> jidanni.org> wrote:
> Gentlemen, In wikitext I want to do <ol start="6101">
>  <li>a
>  <li>b
> </ol>
> but http://www.w3.org/TR/html401/struct/lists.html says that is
> deprecated.

It's been un-deprecated in HTML5, for what that's worth.  I don't know
whether XHTML2 has done so as well.
Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 1 Feb 2009 02:10
Picon

Re: – Fixing {val}

On Sat, Jan 31, 2009 at 7:12 PM, Platonides <Platonides <at> gmail.com> wrote:
> {{val}} is just a presentational template. It's trivial to create an
> equivalent, fixed, parserfunction.

We do not want to create a new parser function for every
presentational template people come up with.
Permalink | Reply | 0 comments |
headers
Andrew Garrett | 1 Feb 2009 02:18

Re: – Fixing {val}

On Sat, Jan 31, 2009 at 2:27 PM, Greg L <greg_l_at_wikipedia <at> comcast.net> wrote:
> This is the product of the buggy math-based parser functions it must
> use. To date, notwithstanding that Jimbo is solidly behind this, and
> that Erik supports the production of the required parser function, no
> volunteer developer has stepped up to the plate with a parser function
> that can character-counting parser function.

Jimmy has absolutely no authority or expertise on technical matters
such as this. His opinion on the best way to implement such
presentational templates is, with respect, not necessarily informed
and not binding in any way, as he does not deal with site operations
or software development at this time.

While Erik may have authority over technical matters (he is Brion's
boss), I would imagine that, like in any organisation, he delegates
final decisions on matters such as this to Brion, who is, after all,
CTO.

The approach we want to take isn't exactly clear at this time -- this
discussion is being had in multiple places, and it basically boils
down to a wide expansion of parser functionality (i.e. inline LUA), or
the greater use of in-built parser functions for the *end* *result*,
rather than for the intermediate steps required. The current approach
of providing "building block" functions has been known to be
reasonably untenable for some time, for performance and usability
reasons (see a few threads up, Domas' rant about Cite).

--

-- 
Andrew Garrett
(Continue reading)

Permalink | Reply | 0 comments |
headers
Asheesh Laroia | 1 Feb 2009 02:26

Fixing text encoding corruption

Just as an FYI, wiki.freeculture.org has mis-encoded UTF-8 for the better 
part of the past four years. This is because we used the old Latin 1 
schemas.

Now we don't have these problems anymore. I wrote up my notes at 
http://wiki.freeculture.org/Fixing_text_encoding_corruption , but here 
they are for y'all's convenience:

    1.  freeze writes to the main wiki
    2. Dump freecult_wikidb to dump.sql
    3. Create a fresh MW install (just for the table schemas) in 
freecult_wikidb2
    4. Create a temporary empty DB, and import dump.sql to it
    5. In the temporary DB, ALTER TABLE on the text table so it has the 
same columns as freecult_wikidb2's text table
    6. Dump wikidb3 and have certainty that the column names will line up 
(but don't copy the sucky old schema)
           * mysqldump --no-create-info --add-locks --complete-insert 
freecult_wikidb3 > sql
    7. Import that into freecult_wikidb2, skipping the tables that are 
missing
           * mysql -f freecult_wikidb2 < sql
           * WATCH for errors other than "skipping missing table"
    8. php maintenance/rebuildall.php
           * If this fails with key errors, just drop the recentchanges 
table and recreate it with the wikidb2 schema

I've poured enough of my life into this issue, but if someone else wants 
to take this up and document it better, by all means go ahead!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 1 Feb 2009 02:29
Picon

Re: war on Cite/{{cite}}

On Sat, Jan 31, 2009 at 8:19 PM, Platonides <Platonides <at> gmail.com> wrote:
> That would be like adding a dependancy on Lua extension for reusers, as
> the core templates will be implemented in Lua.

Yes, that would be the major disadvantage I can see.  In practice,
nobody can reuse large chunks of Wikipedia content on shared hosting
anyway, since it's way too big, but it would be a serious obstacle for
people who want to reuse only parts of Wikipedia.
Permalink | Reply | 5 comments |
headers
Robert Rohde | 1 Feb 2009 02:33
Picon

Re: – Fixing {val}

This discussion is getting side tracked.

The real complaint here is that

{{#expr:(0.00007 * 1000 * 1000) mod 1000}} is giving 69 when it should give 70.

This is NOT a formatting issue, but rather it is bug in the #expr
parser function, presumably caused by some kind of round-off error.

-Robert Rohde

On Sat, Jan 31, 2009 at 2:27 PM, Greg L <greg_l_at_wikipedia <at> comcast.net> wrote:
> Yes, {val} is a tool for making attractive and convenient scientific
> notation. The look of {{tl|val}} was discussed at length on both
> WT:MOSNUM and WT:MOS and achieved broad support for how it works and
> renders numbers. It delimits numbers with narrow spaces that aren't
> really "spaces"; they use CSS <span> tags to move characters. Thus,
> the significands can be copied and pasted into Excel where they will
> be treated as real numbers without the need to first hand-delete spaces.
>
> The problem with it {val} is outlined here at…
>
> http://en.wikipedia.org/w/index.php?title=User_talk:Jimbo_Wales&oldid=260819871
>  -
> Developer_support_for_parser_function
>
> In a nutshell, about 5 to 10% of the time, {val} gives rounding
> errors. For instance, the expression  {{val|0.55007|e=6}} will return
> a significand of 0.550069.
>
(Continue reading)

Permalink | Reply | 30 comments |
headers
Aryeh Gregor | 1 Feb 2009 02:43
Picon

Re: – Fixing {val}

On Sat, Jan 31, 2009 at 8:33 PM, Robert Rohde <rarohde <at> gmail.com> wrote:
> This discussion is getting side tracked.
>
> The real complaint here is that
>
> {{#expr:(0.00007 * 1000 * 1000) mod 1000}} is giving 69 when it should give 70.
>
> This is NOT a formatting issue, but rather it is bug in the #expr
> parser function, presumably caused by some kind of round-off error.

$ php -r 'echo (0.00007 * 1000 * 1000) % 1000 . "\n";'
69
$ php -r 'echo (int)(0.00007 * 10000000) . "\n";'
699

The issue is bog-standard floating-point error.  If PHP has a decent
library for exact-precision arithmetic, we could probably use that.
Otherwise, template programmers will have to learn how floating-point
numbers work just like all other programmers in the universe.
Permalink | Reply | 11 comments |
headers
greg_l_at_wikipedia | 1 Feb 2009 02:53
Picon

Re: -- Fixing {val}

Aryeh, this reaction of “We do not want to create a new parser  
function for every presentational template people come up with” is  
understandable. However, I understand that a character-counting parser  
function in another form has been in the works for a long time but  
hasn’t proven to be reliable enough to be released into the wild.

If someone could finally develop a bullet-proof character-counting  
parser function, I’m quite certain that a number of valuable uses  
could be found for it. That is why I encourage the writing of a parser  
function over the effort of writing a developer’s version of a  
template that doesn’t work very well. The only reason {val} doesn’t  
work well is because it must rely upon math-based parser functions  
that produce rounding errors. Having said that…

The MOS and MOSNUM community has waited seven months for a version of  
{val} that works well for all numbers—even ones that are really big.  
Any developer who is willing to tackle this issue, regardless of  
whether it is a parser function or a revised version of {val}, would  
be most welcome. However, both Jimbo Wales (in particular) as well as  
Erik seemed to think the best way to leverage developer effort would  
be to produce the character-counting parser function as this would  
enable the production of template tools we haven’t even conceived of  
yet.

On Jan 31, 2009, at 5:30 PM, Platonides wrote:

Aryeh Gregor wrote:
> On Sat, Jan 31, 2009 at 7:12 PM, Platonides wrote:
>> {{val}} is just a presentational template. It's trivial to create an
>> equivalent, fixed, parserfunction.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aryeh Gregor | 1 Feb 2009 03:09
Picon

Re: -- Fixing {val}

On Sat, Jan 31, 2009 at 8:53 PM, greg_l_at_wikipedia
<greg_l_at_wikipedia <at> comcast.net> wrote:
> Aryeh, this reaction of "We do not want to create a new parser
> function for every presentational template people come up with" is
> understandable. However, I understand that a character-counting parser
> function in another form has been in the works for a long time but
> hasn't proven to be reliable enough to be released into the wild.

It would be trivial to write up such a function, and in fact plenty of
people have.  I could add it right now in five minutes.  The question
is whether it's desirable to make templates into more of a
full-fledged programming language than they already are.  There's been
reluctance on many people's part to do that.  Personally, I think
they're close enough anyway so that you may as well give them some
basic string functions like {{#len:}}, if the Lua proposal isn't
accepted.

> The only reason {val} doesn't
> work well is because it must rely upon math-based parser functions
> that produce rounding errors.

As I said in my other response, the exact same errors occur in PHP,
and the same type of error occurs in all programming languages.  If
you aren't familiar with floating-point calculations, see:

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

In a real programming language, of course, there would be workarounds
like defining new data types, whereas in template programming that
would be tricky.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane