It only happens when I edit pages I am "watching"... if I uncheck the
"watch this page" checkbox, the edit succeeds. Then I have to re-watch
the page again. Aargh.
Jonathan
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: djw(a)reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2
I am running this command on the new server and piping it into a
publicly accessible file:
iostat -x -t 5 8640
It will give extended device I/O stats for each partition, plus CPU
stats. There will be a report added to the file every 5 seconds. A
total of 8640 reports will be written (that's 12 hours). I'm doing it
today because it's on my mind, but today is not ideal, since usage
will be different than normal with the Thanksgiving holiday. That's
why I'm only doing 12 hours.
The file is accessible as:
http://www.wikipedia.org/stats/io.txt
--
"Jason C. Richey" <jasonr(a)bomis.com>
I was just editing User:Clutch/mod_wiki and tried to save it, and got
the following error:
A database query syntax error has occurred. This could be because of an
illegal search query (see Searching Wikipedia), or it may indicate a bug
in the software. The last attempted database query was:
INSERT INTO watchlist (wl_user, wl_page) VALUES (2583,152410)
from within function "". MySQL returned error "1062: Duplicate entry
'2583-152410' for key 1".
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: djw(a)reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2
I managed to device a query for the watchlist that brought in both pages
and their talk pages (or, if you are watching only the talk page, the
associated subject page) from the cur_id, thanks to the magic of bitwise
or. Switching to the table format cuts generation of my 1000-entry
watchlist (with default limit of 125) almost in half, from ~9-10 seconds
to ~5-6. Hurrah!
One slight bug: if you're watching both a page *and* its talk page, they
show up twice in the watchlist.
I have so far installed it only on the English wiki. If anyone updates
User.php, Skin.php, SpecialWatchlist.php, SpecialRecentchanges.php,
SpecialRecentchangeslinked.php on the others before I get to it, put in
and run "upgradeWatchlist.php" out of the maintenance/ subdirectory
first; this will generate the table from the current user-table list.
-- brion vibber (brion @ pobox.com)
My idea is like this:
string render_math(string text)
{
tree parse_tree = parse_and_validate (text);
if (parse_tree != NULL)
{
string new_text = render_tex(parse_tree);
string hash = md5(new_text);
string file_name = file_prefix + hash;
if (file_exists(file_name))
return "<img ... alt=" + htmlattr_escape(text) + ">";
else
if (tex_render(new_text, file_name))
return "<img ... alt=" + htmlattr_escape(text) + ">";
else
return "<b>Warning: couldn't render: " + wiki_escape(text) + "</b>";
} else {
return text;
}
}
Where:
md5() - obvious
file_prefix - obvious
httmlattr_espace() - obvious
wiki_escape() - obvious
file_exists() - obvious
tex_render() - call external tex rendering program
parse_and_validate() - generated LALR parser which checks if TeX
is safe. If it doesn't understand it, then
it's NOT safe.
render_tex() - render TeX string from tree. Place to add
all extra features, alternative syntaxes etc.
In easiest version just copies first text.
What do you think ?
Anthere,
I believe that your idea about your watch list could be programmed very easily. Also, it will improve performance -- at least for you. Especially, if you are using a slow connection, like 5 KB / second.
Why should you have to wait 1 minute and 20 seconds, for something that could reach you in 10 seconds?
Brion, could we add a clause like this?
WHERE (today - timestamp) < 3 days? /* I know this is not correct syntax */
Ed Poor
-----Original Message-----
From: Anthere [mailto:anthere5@yahoo.com]
Sent: Tuesday, November 26, 2002 5:48 AM
To: wikitech-l(a)wikipedia.org
Subject: [Wikitech-l] Watch list and performance issues
Would it not be interesting to slightly change the way the watch list is working ?
That's a very important tool on the en.wiki
1) to follow-up articles one is interested in
It can hardly be done with recent changes now; too many articles modifications everyday.
But in the watch list feature, what is really interesting - imho - is the watch of the most recent articles modified.
2) to a lesser extent to find back some articles one want to go back one day
but this can also be done with the search, or by adding links on personal pages
My watch list is hideously big. Each time I click on watch list, my next move is to click on the *stop loading* button after a small bunch of seconds. Just display the last 3/7 days of watched articles. 99% of the time, that's *all* what is needed. Why should one wait for the whole watch list to be downloaded ? Why should one impose extra useless burden to the server ?
How much of server time does the watch list query take anyway ?
How much of the client time does it take to load 400 kb of data, when only 50k are really needed ?
Why should not a persistent and repetitive human habit be automated ?
I'd like to see at the top of the watch list something like
- display the articles I follow which were modified in the past 3 days
- display the articles I follow which were modified in the past 14 days
- display all the articles I follow
With a default at 3 days for example.
It is not that this is *really* needed by humans, though it would be nice. But could it help performance ?
_____
Do you Yahoo!?
Yahoo! Mail <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com> Plus - Powerful. Affordable. Sign up <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com> now
If it's not too much trouble, could we do the watchlist without string comparisons? I bet a table like this speed things up:
user_id article_id
------- ----------
284 298
284 1598
284 6503
284 1364
284 3305
Then, we could link the tables, like:
SELECT * FROM cur, watch
WHERE cur_id = watch_article_id AND watch_user_id = 284
(Again, I'm not sure of the syntax: I made up a non-existent table!)
Would this work?
How hard would it be to implement?
How much would it help?
Ed Poor
I'm still working on my long-term redesign of the Wiki software (planned
to be an Apache module written in C, with PostgreSQL as the backend).
I notice the two letter country codes, with a colon, prefix articles in
the wikipedias for other languages.
Are these namespaces, or are they parsed specially by the php to get
redirected to a different URL, which is a totally different wikipedia in
it's own right?
I guess that's another table to create:
CREATE TABLE wikipedias (
language_code byte(2),
url_prefix text
);
INSERT INTO wikipedias VALUES ("eo", "http://eo.wikipedia.org/wiki/");
Of course this table would be accessed only once, when the Apache module
gets initialized. Would make it easier to add web based editing too.
Jonathan
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: djw(a)reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2
Would it not be interesting to slightly change the way the watch list is working ?
That's a very important tool on the en.wiki
1) to follow-up articles one is interested in
It can hardly be done with recent changes now; too many articles modifications everyday.
But in the watch list feature, what is really interesting - imho - is the watch of the most recent articles modified.
2) to a lesser extent to find back some articles one want to go back one day
but this can also be done with the search, or by adding links on personal pages
My watch list is hideously big. Each time I click on watch list, my next move is to click on the *stop loading* button after a small bunch of seconds. Just display the last 3/7 days of watched articles. 99% of the time, that's *all* what is needed. Why should one wait for the whole watch list to be downloaded ? Why should one impose extra useless burden to the server ?
How much of server time does the watch list query take anyway ?
How much of the client time does it take to load 400 kb of data, when only 50k are really needed ?
Why should not a persistent and repetitive human habit be automated ?
I'd like to see at the top of the watch list something like
- display the articles I follow which were modified in the past 3 days
- display the articles I follow which were modified in the past 14 days
- display all the articles I follow
With a default at 3 days for example.
It is not that this is *really* needed by humans, though it would be nice. But could it help performance ?
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
I have just made some simple TeX validator and parser.
To make it any useful I need a list of all TeX constructs we support.
Everything that contains some other function will be considered
illegal.
Here is short list of obvious ones (classified by arity):
0 alpha beta gamma theta tau vartheta
0 pi upsilon varpi phi delta kappa
0 rho varphi epsilon lambda varrho chi
0 varepsilon mu sigma psi zeta nu
0 varsigma omega eta
0 Gamma Lambda Sigma Psi Delta Upsilon Omega Theta Pi Phi
1 sqrt
2 frac
Do you have some more complete list ?
Parser should have no problem with a couple thousands,
so don't hesitate.