Peter Danenberg wrote in part:
>See the documentation at http://69.44.153.14/wikitex_doc.htm for
>current blacklists; we'll continue to publish, as appropriate,
>module-specific blacklists.
I hope that you don't regard this list as complete,
even for the current <rend> classes.
For example, try the following input in the test page:
----
<p>This properly is not accepted:</p>
<p><rend class="math">
\input null
If you see this, then WikiTeX just inputted a file!
</rend></p>
<p>But this should not be accepted either!:</p>
<p><rend class="math">
\catcode `\| 0
|input null
If you see this, then WikiTeX just inputted a file!
</rend></p>
<p>The solution (overkill, but simple):
Add \catcode to the blacklist.</p>
----
(Luckily, the standard TeX file <null.tex> is completely empty,
except for some lines that begin with the comment character.
But for more fun, insert the line "\catcode `\% 12" as well! ^_^)
Besides checking with PlanetMath.org and arXiv.org
to catch anything that we didn't happen to think of,
somebody really should go through the proposed (La)TeX packages
with a fine-toothed comb to ensure that nothing has been missed.
If you're at the point where you're ready to develop
a complete blacklist for any or all <rend> classes,
then I will do this (assuming that you use only
standard packages whose source is available at CTAN).
Just let me know what (La)TeX code you use in the file,
other than the material between the <rend> tags.
(Possible example:)
----
\documentclass {article}
\begin {document}
\begin {equation*}
%s
\end {equation*}
\end {document}
----
(Although you're probably doing something a bit more sophisticated.)
Although if you want me to do that /right now/,
then you'll probably have to wait until 2004,
due to holiday effects on my schedule and Internet access.
^_^
-- Toby
Do we need to add the traditional GPL notification at the beginning of
source files?
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
This page currently dies with the error :
Fatal error: Call to a member function on a non-object in
/usr/local/apache/common/php/Article.php on line 141
--
Gareth Owen
"It's not a human or civic right to edit wikipedia."
-- kq cuts to the core of the banning debate
...to pop into the current debate about the tags, lets prefer
<music>Yeah</music> as well as <math> and <chem> (am I up-to-date or has
something been already decided?) for intuition reasons...
Mark Krüger
Fichardstrasse 50
60322 Frankfurt am Main
T: 069/95530009
E: mark(a)kruegerbrothers.com
I've been trying to get mediawiki-1.1.0 to work. This time make math did
work and I get some math functions, but incomplete ones, see:
http://dev.internet-encyclopedia.org/wiki/wiki.phtml?title=Trigonometry
By logging in and selecting HTML preferences you can get that part of it to
work but not PNG or the modern browsers selection.
These are the LocalSettings.php I have made on math.
$wgMathPath = "{$wgServer}/math";
$wgMathDirectory = "/public/html/colorado/math";
Any ideas?
Fred
I have written a proposal on handling messages and templates on
http://meta.wikipedia.org/wiki/MediaWiki_feature_request_and_bug_report_disc
ussion, but nobody seems to read that page. It's wikified, so I don't want
to repost it here.
Please read and comment. Some of it may be unclear, so feel free to ask.
zocky
>> Possible performance drawbacks when dealing with huge MySQL tables?
>The revisions table would be about the size of the present old table.
>It would have some more rows, but would no longer have the overhead of
>duplicate title information. Meanwhile, some functions that deal with
>page titles but don't care about their contents (whatlinkshere,
>allpages, orphans, etc) may well be faster by having a smaller page
>table instead of the text-bloated cur.
Surely most of the current queries done on the database are on cur: logged in and non-logged in users viewing and editing the most recent version of pages. Relatively few queries access old: mostly viewing old versions of pages. I don't know what the exact split is but it is probably 90/10 or something.
By merging cur and old, won't that mean that most of the queries will now access the much larger revisions table? So a relatively small number of queries will get faster, but most will get slower?
Isn't this the original reason for the split of all the page data into the cur and old tables?
I don't know the exact impact combining them back will have to response times. Presumably most of the accesses to revisions will use unique indexes, and will scale well, so maybe the cleaner code is worth it if the access times do not degrade much.
Do any of the developers have a feel for how much slower the queries on revisions would be compared to cur? Just viewing an old revision seems to take about the same time as viewing the current revision, but that is just one piece of code that queries the cur table among many.
-- Michael Richards (Nanobug)
Various wikimedia.* domains seem to have been bought up by unknown
third parties. Do we care?
wikimedia.net, wikimedia.biz, wikimedia.us seem to be the standard
domain reseller scum.
wikimedia.com brings up a generic 'under construction' page (in
German); the owner is a Daniela Rohrer at paracelsuspraxis.ch.
wikimedia.de is actually some sort of wiki (in German): "wikimedia ist
eine nichtkommerzielle unpolitische vereinigung zur foerderung des
InternetWieEsEinmalGedachtWar in form von wikis." I'm not quite sure
what's up with this; it's a TWiki and I can't figure out how to
navigate to anything usefully. (Well, and it's in German.)
-- brion vibber (brion @ pobox.com)
*sigh* I'm a wiki newbie trying to setup MediaWiki 1.10.
My problem is none of the links work. Whenever I click on them it stays on the main page.
After reading through the pages it was noted that this problem could occur due to not
setting register_globals = On in php.ini. The variable had already been set correctly so
this couldn't be the problem.
My sql version is 3.23.58
Apache version Apache/1.3.27
PHP 4.3.4
http://www.adverserealms.com/wiki/wiki.phtml
Here are the steps I took
mysqladmin -u root password 'mynewpassword'
started mysql
mysql> GRANT ALL PRIVILEGES ON *.* TO emeraldwiki@localhost
-> IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
Then I set my sql part of my LocalSettings file to the following
$wgDBserver = "localhost";
$wgDBuser = "emeraldwiki";
$wgDBname = "mywiki";
$wgDBpassword = "apassword";
$wgDBsqlpassword = "anotherpassword";
$wgDBminWordLen = 3; # Match this to your MySQL fulltext
$wgDBtransactions = false; # Set to true if using InnoDB tables
The install.php script seemed to run fine without any problems.
Any pointers would be appreciated. I believe I laid out all the steps I took. I can try
to be more clear if needed.
Thanks,
Joshua
I've snuck some quick statistics calls into Article.php to count the
relative frequency of cache hits in page views.
In a few minutes on en:
** en **
Page views: 5420
Cache hits: 3322 (61%)
Cache misses: 98 (1%)
Client-side: 522 (9%)
Uncacheable: 1478 (27%)
Not half bad. Cache hits here are where it's able to pull a complete
pre-rendered page from the file cache and send it out. Cache misses are
where it can do caching, but has to (re)render the page this time.
Client-side caching is where the wiki is able to send a '304 Not
modified' response and the client uses a copy it's previously cached
locally. Uncacheable hits are old revision views, diffs, redirects, and
views by logged-in users that aren't client-side cached.
These figures won't include anything but page views (special pages,
editing, logins, etc).
I'll let it run and see if the ratios hold up during the day and with
the various languages.
-- brion vibber (brion @ pobox.com)