* Gregory Maxwell [Wed, 1 Jul 2009 02:17:24 -0400]:
>
> Juniper Networks (my day job) uses XSLT as the primary scripting
> language on their routing devices, and chose to do so primarily
> because of sandboxing and the ease of XML tree manipulation with xpath
> (JunOS configuration has a complete
On Wed, Jul 1, 2009 at 1:42 AM, Dmitriy Sintsov wrote:
> XSLT itself is a way too much locked down - even simple things like
> substrings manipulation and loops aren't so easy to perform. Well, maybe
> I am too stupid for XSLT but from my experience bringing tag syntax in
> programming language mak
> 1 - XSLT
>
> Since the syntax is XML (like the extensions tags) and XPath
(vaguely
> similar to template syntax, although it's XML that calls XPath, the
> opposite of what we have) It would be reasonably consistent with
> current
> syntax. It also should also already be fairly well lock
On Tue, Jun 30, 2009 at 11:46 PM, Tim Starling wrote:
[snip]
> SpiderMonkey and Python both lack control over memory usage. Python
> lacks a sandbox mode, the rexec module has been removed. SpiderMonkey
> isn't embedded in any useful kind of standalone, so you'd have to
> start with a C development
On Tue, Jun 30, 2009 at 12:16 PM, Brion Vibber wrote:
> As many folks have noted, our current templating system works ok for
> simple things, but doesn't scale well -- even moderately complex
> conditionals or text-munging will quickly turn your template source into
> what appears to be line noise.
2009/7/1 Michael Daly :
> Why not switch the template syntax for articles to match the syntax for
> tags (which in turn is based on XML or whatever syntax that comes from
> ultimately)?
What is wrong with the current syntax for calling templates? At least,
what is wrong with it that would be impro
Robert Rohde wrote:
> Makes it awfully ugly to pass the result of one template to another
> template if your syntax is:
>
> " var2="bar"/>
Eww! - hadn't thought of that one. Back to the other style:
var1= val="May 24";;
var2=bar;
or unnamed:
val="May 24";;
bar;
Recursive template proce
Brion Vibber wrote:
> There's been talk of Lua as an embedded templating language for a while,
> and there's even an extension implementation.
>
> One advantage of Lua over other languages is that its implementation is
> optimized for use as an embedded language, and it looks kind of pretty.
>
On Tue, Jun 30, 2009 at 10:45 PM, Sergey
Chernyshev wrote:
> I don't know about scripting languages for the templating, it might be an
> overkill.
People are using ParserFunctions as a scripting language already.
That's not feasibly going to be removed at this point. So the only
way to go is to r
http://techblog.wikimedia.org/wp-comments-post.php says:
Your location has been identified as part of a reported spam network.
Comments have been disabled to prevent spam.
$ whois 122.127.35.74
...country: TW
What should I do, upgrade my country?
___
I don't know about scripting languages for the templating, it might be an
overkill.
When I was picking lower language for MediaWiki Widgets extension, I looked
at popular PHP templating systems and ended up picking Smarty (
http://smarty.net/) - it can be security locked, it has a few useful
featu
On Tue, Jun 30, 2009 at 7:27 PM, Michael Daly wrote:
> Chad wrote:
>
>> Unless we plan on trying to mass-convert not only years of old revisions
>> but change years-old behavior that millions of users have come to expect?
>> I would expect _any_ change to keep {{sometemplate}} always working,
>> ev
Chad wrote:
> Unless we plan on trying to mass-convert not only years of old revisions
> but change years-old behavior that millions of users have come to expect?
> I would expect _any_ change to keep {{sometemplate}} always working,
> even if the mechanics behind it change.
Why not switch the te
Thomas Dalton wrote:
>> Thus the first line of a template would
>> be the example of its use:
>>
>> Template:foobar
>> --
>> {{Foobar|$var1|$var2|$andAnotherVar}}
>> ...(implementation)...
>> ---
On Tue, Jun 30, 2009 at 6:08 PM, Robert Rohde wrote:
> In addition to resource limits, any scheme better make sure what's
> passed into the programming language and what's passed out makes
> sense. For example, you shouldn't have it generating raw HTML and
> probably shouldn't let it mess with str
http://jtemplates.tpython.com/ ? :)
Trevor Parscal wrote:
> Seems like JSON syntax is pretty simple and could be a big improvement
> to how templates are currently invoked.
>
> Bottom line, a well defined syntax like JavaScript is going to be more
> user friendly than a syntax which is only de
> I logged in to zh.wikipedia.org and it says I am $1.
> 您現在以「$1」的身分登入維基百科。
Not bad. It's me "Dollar One". MC Dollar One. OK, filed
https://bugzilla.wikimedia.org/show_bug.cgi?id=19454
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://li
Seems like JSON syntax is pretty simple and could be a big improvement
to how templates are currently invoked.
Bottom line, a well defined syntax like JavaScript is going to be more
user friendly than a syntax which is only defined by the behavior of a
parser with standardization at all.
-
On Tue, Jun 30, 2009 at 6:43 PM, Thomas Dalton wrote:
> There is no proposal to replace wikitext with PHP (it wouldn't even
> work, PHP isn't a markup language, ditto Javascript, Python, etc.),
> the proposal is to replace the template code, ie. the code on the
> template pages.
The OP does not sa
2009/7/1 Brian :
> On Tue, Jun 30, 2009 at 6:34 PM, Thomas Dalton wrote:
>> What would you replace them with? The wikitext used by regular editors
>> should be as simple as possible, we don't want to require PHP or
>> Javascript to be used by anyone wanting to add an infobox to an
>> article.
>
> T
On Tue, Jun 30, 2009 at 6:34 PM, Thomas Dalton wrote:
> What would you replace them with? The wikitext used by regular editors
> should be as simple as possible, we don't want to require PHP or
> Javascript to be used by anyone wanting to add an infobox to an
> article.
There is nothing in the OP
Andrew Garrett wrote:
> On 30/06/2009, at 9:42 PM, Aryeh Gregor wrote:
>
>> On Tue, Jun 30, 2009 at 4:25 PM, Brion Vibber
>> wrote:
>>> IMO by the time you've implemented your whitelisting parser you
>>> might as
>>> well just interpret it rather than eval()ing.
>> I don't think so. You'd onl
On Tue, Jun 30, 2009 at 8:28 PM, Brian wrote:
> On Tue, Jun 30, 2009 at 6:09 PM, Robert Rohde wrote:
>> In other words, I assume things like "{{fact}}" and "{{msg | foo is
>> bar }}" will be be basically unchanged on the article side but
>> rewritten on the implementation side in Template: space.
2009/7/1 Brian :
> On Tue, Jun 30, 2009 at 6:09 PM, Robert Rohde wrote:
>> In other words, I assume things like "{{fact}}" and "{{msg | foo is
>> bar }}" will be be basically unchanged on the article side but
>> rewritten on the implementation side in Template: space. If that is
>> correct, it wou
Aryeh Gregor wrote:
> On Tue, Jun 30, 2009 at 4:25 PM, Brion Vibber wrote:
>> It's not about "Wikipedia content", but about being able to grab things
>> you see on another wiki and use or adapt them to your own needs. We get
>> lots of questions from people trying to grab some particular template
>
On Tue, Jun 30, 2009 at 6:09 PM, Robert Rohde wrote:
> In other words, I assume things like "{{fact}}" and "{{msg | foo is
> bar }}" will be be basically unchanged on the article side but
> rewritten on the implementation side in Template: space. If that is
> correct, it would be more useful to si
On Tue, Jun 30, 2009 at 4:01 PM, Brian wrote:
> On Tue, Jun 30, 2009 at 11:20 AM, Robert Rohde wrote:
>>
>> However,
>> given the nastiness of template syntax, I would expect no end of wiki
>> authors willing to help convert the commonly used stuff.
>>
>> -Robert Rohde
>
> I was curious just how t
Dan Collins wrote:
> Apparently, for whatever reason, the master database server for enwiki
> got overloaded. This was following a few updates, which may have (I
> don't think they're sure yet) caused the problem. What actually
> happened was the database server had a large number of queries stuck
I personally agree entirely. Now we just need to revive J4P5
(http://j4p5.sourceforge.net) :)
- Trevor
On 6/30/09 4:24 PM, Hay (Husky) wrote:
> I would opt for Javascript.
>
> PHP and Python are intended for large and complex applications and
> come with a huge standard library people probably e
On Tue, Jun 30, 2009 at 7:17 PM, The Cunctator wrote:
> Was that planned downtime?
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
No.
Apparently, for whatever reason, the mast
I would opt for Javascript.
PHP and Python are intended for large and complex applications and
come with a huge standard library people probably expect to be
available. Security concerns are a problem too, so a subset would
probably be necessary So, in essence you get a crippled-down language
that
I logged in to zh.wikipedia.org and it says I am $1. en.wikipedia.org
didn't have that problem.
您現在以「$1」的身分登入維基百科。
如果您對維基百科有任何問題的話，請參看幫助頁。
您已登入其他的維基媒體計劃：
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/li
Was that planned downtime?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 30/06/2009, at 9:42 PM, Aryeh Gregor wrote:
> On Tue, Jun 30, 2009 at 4:25 PM, Brion Vibber
> wrote:
>> IMO by the time you've implemented your whitelisting parser you
>> might as
>> well just interpret it rather than eval()ing.
>
> I don't think so. You'd only have to do the whitelisting
On Tue, Jun 30, 2009 at 11:20 AM, Robert Rohde wrote:
>
> However,
> given the nastiness of template syntax, I would expect no end of wiki
> authors willing to help convert the commonly used stuff.
>
> -Robert Rohde
I was curious just how terrible of a task conversion can be expected
to be. This
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
> Aryeh Gregor
> Sent: 30 June 2009 22:16
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] On templates and programming languages
>
> On Tue, Jun 30
On Tue, Jun 30, 2009 at 12:56 PM, Aryeh
Gregor wrote:
> On Tue, Jun 30, 2009 at 12:16 PM, Brion Vibber wrote:
>> * PHP
>>
>> Advantage: Lots of webbish people have some experience with PHP or can
>> easily find references.
>>
>> Advantage: we're pretty much guaranteed to have a PHP interpreter
>> a
2009/6/30 Steve Sanbeg :
> On Tue, 30 Jun 2009 21:38:07 +0100, Thomas Dalton wrote:
>
>> 2009/6/30 Michael Daly :
>
>> How does that work with anonymous variables? Are all $[NUMBER] style
>> names count as auto-declared?
>>
>
> They're not anonymous, they're just named sequentially.
They are anony
On Tue, 30 Jun 2009 21:38:07 +0100, Thomas Dalton wrote:
> 2009/6/30 Michael Daly :
> How does that work with anonymous variables? Are all $[NUMBER] style
> names count as auto-declared?
>
They're not anonymous, they're just named sequentially. Most languages
should have some method of accessi
On Tue, Jun 30, 2009 at 5:11 PM, Marco
Schuster wrote:
> How do statically compiled programs for x86 platforms behave on x64, btw?
I'm pretty sure they work fine. Someone with more knowledge of Linux
binaries needs to comment on how we could best do this, though.
> And what about more "exotic" p
On Tue, Jun 30, 2009 at 4:52 PM, Jared
Williams wrote:
> Pity there is not a method of locking down code execution to a single
> namespace, (think ahead with php5.3)
This is implausible, but even if it happened it wouldn't stop trivial
DOSes like while (true);. We'd still need to validate the cod
On Tue, Jun 30, 2009 at 10:45 PM, Aryeh Gregor <
simetrical+wikil...@gmail.com > wrote:
> Alternatively, is the libc ABI stable enough that we could dynamically
> link libc, and statically link everything else? The other libraries
> required are very small.
I wouldn't count on this... at least w
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
> Aryeh Gregor
> Sent: 30 June 2009 20:56
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] On templates and programming languages
>
> On Tue, Jun 30
On Tue, Jun 30, 2009 at 4:33 PM, Marco
Schuster wrote:
> Static compiling the stuff? How would this affect the binary size?
Hopefully not too badly if you use the right options. libc is huge,
but the linker should be able to throw out most of it if statically
linking, since Lua likely doesn't use
On Tue, Jun 30, 2009 at 4:25 PM, Brion Vibber wrote:
> IMO by the time you've implemented your whitelisting parser you might as
> well just interpret it rather than eval()ing.
I don't think so. You'd only have to do the whitelisting once, on
page save. After that you could just execute with no e
2009/6/30 Michael Daly :
> Brion Vibber wrote:
> > Any thoughts? Does anybody happen to have a PHP implementation of a
> > Lua or JavaScript interpreter?
>
> Rather than reinventing the wheel, why not look at fixing the existing
> template syntax?
I would support that. We really don't need a Tur
On Tue, Jun 30, 2009 at 10:25 PM, Brion Vibber wrote:
> Aryeh Gregor wrote:
> > Our
> > current tarballs are 10 MB; we could easily just chuck in Lua binaries
> > for Linux x86-32 and Windows without even noticing the size increase,
> > and allow users to enable it with one line in LocalSettings.
Aryeh Gregor wrote:
> On Tue, Jun 30, 2009 at 12:16 PM, Brion Vibber wrote:
>> * PHP
>>
>> Advantage: Lots of webbish people have some experience with PHP or can
>> easily find references.
>>
>> Advantage: we're pretty much guaranteed to have a PHP interpreter
>> available. :)
>>
>> Disadvantage: P
2009/6/30 Brion Vibber :
> Skins might want/need to be able to override certain names, too... and
> we might consider about needs for localized images -- whether RTL/LTR
> only or actually making translations available.
Like http://laxstrom.name/blag/2008/07/05/localisation-of-images/ ?
Or was the
Brion Vibber wrote:
> Any thoughts? Does anybody happen to have a PHP implementation of a
> Lua or JavaScript interpreter?
Rather than reinventing the wheel, why not look at fixing the existing
template syntax?
The biggest problem that I see is the excessive dependence on the
parentheses { an
On Tue, Jun 30, 2009 at 12:16 PM, Brion Vibber wrote:
> * PHP
>
> Advantage: Lots of webbish people have some experience with PHP or can
> easily find references.
>
> Advantage: we're pretty much guaranteed to have a PHP interpreter
> available. :)
>
> Disadvantage: PHP is difficult to lock down fo
On Tue, Jun 30, 2009 at 2:36 PM, Gerard
Meijssen wrote:
> Hoi,
> The operational word is replace not remove.
> Thanks,
> Gerard
>
> 2009/6/30 Gerard Meijssen
>
>> Hoi.
>> At the Open Translation Tools conference last week we talked about pictures
>> and icons in a user interface. I learned th
Hoi,
The operational word is replace not remove.
Thanks,
Gerard
2009/6/30 Gerard Meijssen
> Hoi.
> At the Open Translation Tools conference last week we talked about pictures
> and icons in a user interface. I learned that some of the "obvious" symbols
> like a magnifying glass are not app
Hoi.
At the Open Translation Tools conference last week we talked about pictures
and icons in a user interface. I learned that some of the "obvious" symbols
like a magnifying glass are not appropriate in other cultures. So I am
completely in favour of integrating images in the UI but PLEASE allow f
On Tue, Jun 30, 2009 at 2:09 PM, Brion Vibber wrote:
> Just shooting out a quick thought before I forget again -- it would be
> helpful in a number of places to be able to reference "internal"
> software-provided images from wikitext.
>
> A primary example is for help pages and inline explanatory t
Just shooting out a quick thought before I forget again -- it would be
helpful in a number of places to be able to reference "internal"
software-provided images from wikitext.
A primary example is for help pages and inline explanatory text in parts
of the UI which we want to be able to customiz
On Tue, 30 Jun 2009 09:16:41 -0700, Brion Vibber wrote:
> As many folks have noted, our current templating system works ok for
> simple things, but doesn't scale well -- even moderately complex
> conditionals or text-munging will quickly turn your template source into
> what appears to be line
On Tue, Jun 30, 2009 at 10:45 AM, Amir E. Aharoni wrote:
> On Tue, Jun 30, 2009 at 20:42, Robert Rohde wrote:
>> On Tue, Jun 30, 2009 at 10:22 AM, Bryan Tong
>>> Also for Python you really will want an editor that supports
>>> indenting. Web browsers are not suitable for programming Python.
>>
>> T
On Tue, Jun 30, 2009 at 20:42, Robert Rohde wrote:
> On Tue, Jun 30, 2009 at 10:22 AM, Bryan Tong
>> Also for Python you really will want an editor that supports
>> indenting. Web browsers are not suitable for programming Python.
>
> Though indenting is mandatory for Python, the use or reasonable
>
On Tue, Jun 30, 2009 at 10:22 AM, Bryan Tong
Minh wrote:
> On Tue, Jun 30, 2009 at 6:16 PM, Brion Vibber wrote:
>
>> * Python
>>
>> Advantage: A Python interpreter will be present on most web servers,
>> though not necessarily all. (Windows-based servers especially.)
>>
>> Wash: Python is probably
On Tue, Jun 30, 2009 at 11:20 AM, Robert Rohde wrote:
> You couldn't ever turn template syntax off without making old
> revisions unrenderable. The best one could likely do is encourage
> people to upgrade and provide tools to make that easier. However,
> given the nastiness of template syntax,
On Tue, Jun 30, 2009 at 6:16 PM, Brion Vibber wrote:
> * Python
>
> Advantage: A Python interpreter will be present on most web servers,
> though not necessarily all. (Windows-based servers especially.)
>
> Wash: Python is probably better known than Lua, but not as well as PHP
> or JS.
>
> Disadva
On Tue, Jun 30, 2009 at 10:15 AM, Brian wrote:
> So far my favorite idea is to use a restricted subset of PHP.
>
> I would like to broach an important topic however: How can we convert all of
> the existing ParserFunctions and difficult-to-read template code to this new
> language automatically? Ar
So far my favorite idea is to use a restricted subset of PHP.
I would like to broach an important topic however: How can we convert all of
the existing ParserFunctions and difficult-to-read template code to this new
language automatically? Are we really talking about the dream of getting rid
of te
Brion Vibber wrote:
> Victor Vasiliev wrote:
>
>> I'm working on rewriting abuse filter parser so it's suitable for
>> embedding in wikitext. It's half-done and will be ready soon.
>>
>
> Eh, I'd rather replace the AbuseFilter scripting with
> JS/Lua/Python/whatever too. :)
>
> -- brion
>
On Tue, Jun 30, 2009 at 10:03 AM, Trevor Parscal wrote:
> On 6/30/09 9:16 AM, Brion Vibber wrote:
>> Any thoughts? Does anybody happen to have a PHP implementation of a Lua
>> or JavaScript interpreter? ;)
>>
>> -- brion
>>
>>
> GPL, Alpha software, seems to be abandoned in 2005
> http://j4p5.sourc
On 6/30/09 9:16 AM, Brion Vibber wrote:
> Any thoughts? Does anybody happen to have a PHP implementation of a Lua
> or JavaScript interpreter? ;)
>
> -- brion
>
>
GPL, Alpha software, seems to be abandoned in 2005
http://j4p5.sourceforge.net/
Perhaps this could be tested, considered, brought b
Robert Rohde wrote:
> In the Lua Bugzilla thread (#19298), there was some extended
> discussion about using the AbuseFilter parser as the basis for a
> Mediawiki scripting language. From your comment should I assume we
> are taking that option off the table?
>
> There are advantages to that appro
Robert Rohde wrote:
> On Tue, Jun 30, 2009 at 9:27 AM, Chad wrote:
>> I haven't tried it, but there seems to be a Lua Pecl extension.
>
> The Lua Pecl says:
>
> "We should emphasize that is still under development and is completely
> experimental."
>
> That was nearly two years ago and there doe
Victor Vasiliev wrote:
> I'm working on rewriting abuse filter parser so it's suitable for
> embedding in wikitext. It's half-done and will be ready soon.
Eh, I'd rather replace the AbuseFilter scripting with
JS/Lua/Python/whatever too. :)
-- brion
_
On Tue, Jun 30, 2009 at 9:16 AM, Brion Vibber wrote:
> There are perhaps three primary alternative contenders that don't
> involve making up our own scripting language (something I'd dearly like
> to avoid):
In the Lua Bugzilla thread (#19298), there was some extended
discussion about using th
Brion Vibber wrote:
> As many folks have noted, our current templating system works ok for
> simple things, but doesn't scale well -- even moderately complex
> conditionals or text-munging will quickly turn your template source into
> what appears to be line noise.
>
> And we all thought Perl wa
On Tue, Jun 30, 2009 at 9:27 AM, Chad wrote:
> I haven't tried it, but there seems to be a Lua Pecl extension.
The Lua Pecl says:
"We should emphasize that is still under development and is completely
experimental."
That was nearly two years ago and there doesn't appear to have been
any real wor
On Tue, Jun 30, 2009 at 19:16, Brion Vibber wrote:
> As many folks have noted, our current templating system works ok for
> simple things, but doesn't scale well -- even moderately complex
> conditionals or text-munging will quickly turn your template source into
> what appears to be line noise.
>
On Tue, Jun 30, 2009 at 12:16 PM, Brion Vibber wrote:
> As many folks have noted, our current templating system works ok for
> simple things, but doesn't scale well -- even moderately complex
> conditionals or text-munging will quickly turn your template source into
> what appears to be line noise.
As many folks have noted, our current templating system works ok for
simple things, but doesn't scale well -- even moderately complex
conditionals or text-munging will quickly turn your template source into
what appears to be line noise.
And we all thought Perl was bad! ;)
There's been talk of
On Tue, Jun 30, 2009 at 11:20 AM, Roan Kattouw wrote:
> 2009/6/30 Magnus Manske :
>> The good folks at Mozilla are working on what they call "Content
>> Security Policy" [1], basically a whitelist for JavaScript
>> cross-domain access.
>>
>> I'm just flagging this up here because of the potential b
2009/6/30 Magnus Manske :
> The good folks at Mozilla are working on what they call "Content
> Security Policy" [1], basically a whitelist for JavaScript
> cross-domain access.
>
> I'm just flagging this up here because of the potential benefits from
> querying toolserver tools from wiki(p|m)edia s
The good folks at Mozilla are working on what they call "Content
Security Policy" [1], basically a whitelist for JavaScript
cross-domain access.
I'm just flagging this up here because of the potential benefits from
querying toolserver tools from wiki(p|m)edia sites. (and yes, there's
JSON, but it'
79 matches
Mail list logo
