Hi,
during the last year the math extension achieved a goal defined back
in 2003. Support of MathML. In addition there is SVG support for
MathML disabled browsers. (See http://arxiv.org/abs/1404.6179 for the
details)
I would like to give Wikipedia users a chance to test this new long
awaited feature.
Therefore we would need a mathoid instance that is accessible from the
production cluster. Greg Grossmeier already created the required table
in the database. (Sorry for the "friction" connected with this
process)
Currently the MathJax team is working on a phantom.js less method to
render texvc to mathml and svg. Some days ago I have tested that it,
and it works quite well. I would appreciate a discussion with ops that
to figure out how this can be can go to production. The original idea
was to use jenkins to build the mathoid debian package. Even though
the debian package builds without any issues in the launchpad ppa repo
jenkins can not build the package. If there is a reference project
that uses jenkins to build debian packages that go to production this
would really help to figure out what is different for mathoid and why
the package building does not work even though it works on launchpad.
Best
Physikerwelt
PS: I was informed that there is a related RT that I can not access
https://rt.wikimedia.org/Ticket/Display.html?id=6077
--
Mit freundlichen Grüßen
Moritz Schubotz
Apologies if this ends up being a duplicate, forwarding it along on Pine's
request because he's been having mail issues and is concerned this one is
also not getting through. It is also, of course, possible that my email
will get stuck too and they will all appear later down the road together.
So far I'm not seeing a huge pile of queued messages on ganglia (though
there was a bit of a bump earlier).
James Alexander
Legal and Community Advocacy
Wikimedia Foundation
(415) 839-6885 x6716 @jamesofur
---------- Forwarded message ----------
From: Pine W <wiki.pine(a)gmail.com>
Date: Tue, Jul 15, 2014 at 1:02 AM
Subject: Strange mailing list behavior
To: "wikitech-l(a)lists.wikimedia.org" <wikitech-l(a)lists.wikimedia.org>
So this evening, besides my one email to Wikimedia-l that got through, 2
others disappeared into thin air. Also, I just received an email in my
Google account that was sent 11 hours ago. Can someone check for gremlins
in the mail system? The problem might be on Google's end or in the mail
system, I can't tell, but I suspect the mail system because mail sent to
non-list addresses seems to get through ok.
Thanks,
Pine
Hi all. I came across a strange issue with regards to Lua 5.1 and Lua 5.2
this weekend. The defect was caused by a change in behavior for "tonumber"
between 5.1 and 5.2. I detail more below for anyone interested.
With that in mind, I wanted to ask a few questions to the group:
* Will Scribunto support Lua 5.2 in the future? According to this comment,
it may:
https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/master/Scr…
* If so, what is the best approach to ensure forward compatibility of
Module code for 5.2? Note that code that is valid for 5.1 may "break" in
5.2. (Again, see below for details)
** Should there be a reference page on MediaWiki or in the enwiki Wikipedia
Namespace that details these breaking issues for other Module writers?
** Or should 5.1 vs 5.2 issues be corrected on a case-by-case basis for
each Module?
** Or should they be left as is, as any future-proofing may be unnecessary
and / or premature?
* Lastly, is there a general purpose mailing list for Scribunto issues?
I've had a few technical questions in the past that have been painful to
sort out on my own. I'd like to think that there might be other Module
writers who would also be interested in a mailing list as well.
Detail on the "tonumber" issue follows below.
----
== In brief ==
* For a call of "tonumber(213.5616, 10)"
** 5.1 will return back 213.5616
** 5.2 will return back NIL
== In detail ==
* Template:Weather_box uses Module:WeatherBox which eventually calls
Module:BaseConvert
* Module:WeatherBox often calls Module:BaseConvert with decimal values. For
example, here is a sample call:
{{#invoke:BaseConvert|convert|n=213.5615|base = 16|width = 2|precision
= 0}}
* Module:BaseConvert has the following lines
from = from or 10
local num = tonumber(n, from)
* Note that if no {{{from}}} is passed, the default is 10. In general, most
callers do not specify a {{{from}}} (as seen above)
* Lua 5.1 has code that specifically says if tonumber is called with no
base or a base of 10, convert it as a number
// http://www.lua.org/source/5.1/lbaselib.c.html
static int luaB_tonumber (lua_State *L) {
int base = luaL_optint(L, 2, 10);
if (base == 10) { /* standard conversion */
* In contrast, Lua 5.2 has code that only cares if a base is not specified.
// http://www.lua.org/source/5.2/lbaselib.c.html
static int luaB_tonumber (lua_State *L) {
if (lua_isnoneornil(L, 2)) { /* standard conversion */
** If a base is specified, Lua 5.2 will not do the standard conversion, and
instead try to parse the number
** This parse code only accepts alpha-numeric characters. The dot is
considered invalid, and any decimal number is converted to NIL
* As a result, for a call of "tonumber(213.5616, 10)"
** 5.1 will return back 213.5616
** 5.2 will return back NIL
* The NIL removes the background (and sometimes text colors) in weather
boxes.
For those curious, I discovered this in XOWA which uses Luaj -- a Java port
of Lua 5.2. I had to backport the 5.1 behavior to get the Weather box to
show the right colors again.
A proposed fix that would be forward compatible with 5.2 would be as
follows:
local num = 0;
-- {{{from}}} is specified, and {{{from}}} is not base 10
if (from && from <> 10) then
-- call overload that will always do parsing
num = tonumber(n, from )
-- {{{from}}} is not specified or {{{from}}} is base 10
else
-- call overload that will always convert to number
num = tonumber(n)
from = from or 10
Finally, I've come across a related issue with the varargs operator
("..."). This operator is valid in 5.1, but not in 5.2. I've seen some
Modules use this varargs operator, that will presumably just break in 5.2.
See https://en.wikipedia.org/wiki/Module:Horizontal_timeline and "function
getNotNilValue(...)"
On Fri, Jul 11, 2014 at 8:45 AM, Luca Martinelli
<martinelliluca(a)gmail.com> wrote:
> so the Book Creator will still be active, maybe under another name,
> maybe with another engine, but still active?
Same name and functionality, just the "Order a printed book" feature
will disappear.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Forwarding to the list in case anyone else is interested in seeing the
screenshot. Please note the comments below.
Risker
---------- Forwarded message ----------
From: Risker <risker.wp(a)gmail.com>
Date: 14 July 2014 09:03
Subject: Screenshot of Winter on Win7/IE9
To: bharris(a)wikimedia.org
Hi Brandon - attaching this for you, feel free to upload, I release this
screenprint under the GDFL and CC-BY-SA.
The screenprint is a tiny bit worse than the actual screen - the letters
are more broken up in the screenshot. Otherwise, the colour, the spacing
and the overlaps are the same.
Risker/Anne
http://cfp.madisonphpconference.com/
If you've never presented at a conference before, sometimes a smaller
regional conference is an easier way to get started. Madison PHP is one day
(Saturday, September 13th, 2014) and seeks talks for attendees at all skill
levels. And their speaker compensation package includes complimentary
airfare/travel and hotel.
I suggest you submit talks:
* on MediaWiki extension development, like
http://opensourcebridge.org/wiki/2014/Extension_Development_with_Mediawiki
(slides available)
* on HipHop and HHVM
* on coding conventions
https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP
* on how you do code review
The proposal deadline is Monday, July 21.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
The linux.conf.au conference, which I have presented to and love going
to, just opened up its call for talks: http://linux.conf.au/cfp . They
want talks about all kinds of open source programming stuff, not just
Linux: Trevor and I presented about ResourceLoader in 2012, and James
and I presented about VisualEditor in 2014.
LCA 2015 will be 12-16 January in Auckland, New Zealand. That's summer
in the Southern Hemisphere, and the climate there is very moderate,
so no sweltering heat like in Australia :)
LCA provides travel funding to some speakers, and Wikimedia funds TPS
grants for people going to conferences to talk about
Wikimedia-related things: https://meta.wikimedia.org/wiki/Grants:TPS .
So you could even get to go for free.
LCA is basically my favorite conference - the talks are great and of
high quality, they treat speakers well, and their audience gets what
we're doing. This is a fun chance to show off your project. I
encourage you to suggest a talk, or tell someone else that they should
talk about their project.
Roan
P.S.: Thanks to Sumana for writing most of this email, and for talking
me into proposing a talk for LCA in the first place back in 2011
I've started experimenting with embedding my ogv.js media player into
TimedMediaHandler to provide Ogg playback in Safari and Internet Explorer:
https://gerrit.wikimedia.org/r/#/c/145756/
This involves on-demand loading of a fairly large chunk of mostly
machine-generated, dense, pre-minified JavaScript that weighs in around a
megabyte (gzips to 250k or so).
Initially I tried tossing it in with the ResourceLoader modules and loading
it with mw.loader.using(), but in some configurations the automatic JS
minification in ResourceLoader was taking too long to process the file. (On
MediaWiki-Vagrant with Zend PHP and Xdebug enabled, it actually hit the
30-second execution limit. Ouch!)
I couldn't find a way to disable minification for a particular module; it
looks like it's applied as a filter step after modules are bundled
together, so I'm not sure it's really possible.
Currently I'm loading the ogv.js payload as a separate file with
$.ajax({dataType:'script'}); this totally bypasses ResourceLoader and thus
the minifier, but gzipping is dependent on the web server configuration.
(MediaWiki-Vagrant's Apache configuration auto-gzips .js files, so yay!)
I also lose other ResourceLoader features like automatic cache
invalidation; for now I'm appending a version parameter on the URL to
ensure that the file is re-cached when updated, but it has to be manually
updated along with the JS payload file.
Any recommendations for making ResourceLoader and large, pre-minified JS
sources fit together better? Or is what I'm doing pretty much the best
practice for now? :)
I'm considering a 'stub' ResourceLoaderModule subclass that generates the
$.ajax() loader call including an automatic version timestamp URL parameter
from the file's last-modification time...
-- brion