Wikitech-l May 2005

wikitech-l@lists.wikimedia.org

136 participants
194 discussions

RE: [Wikitech-l] Crazy idea (was:Longterm software strategy)
by Domas Mituzas 14 May '05

14 May '05

> knowing any of those languages, I really think you should. > I'd love to see such a thing, and would happily learn it, > especially if it means people will stop trying to convince > me to learn Python. Hey Chad, you should learn Python some day! :) Domas

1 0

RE: [Wikitech-l] Crazy idea (was:Longterm software strategy)
by Domas Mituzas 14 May '05

14 May '05

Hey, > But, what about some "Über-language"? A rather abstract code that > can be automatically converted to C++, PHP, Python, Java and-what-not. I'm not sure of such language, but combined with Wikidata (you know, free-form database, which would have any database in it, built on top of any database), it would make ultimate software. Domas

2 1

Re:[Wikitech-l] Re: Proposal for deprecation of syntax features for 1.5
by Nicolas Weeger 14 May '05

14 May '05

> * Current syntax: '''italic''plain => '<i>italic</i>plain > * Proposed syntax: '''italic''plain => <b>italic<i>plain</i></b> > * Previous behaviour with new syntax: <nowiki>'</nowiki>''italic''plain For the record, I shall say that I fully expect riots on w:fr: if this new behaviour becomes mandatory :) Some versions, months ago, did require the <nowiki> tag, and it was really afwul to manage. And we'd also need to *fix* all pages with this syntax, and we can't really fix automatically, need to check on a case-by-case basis. Nicolas Weeger Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)

7 14

my favorite nightmare...
by Anthere 13 May '05

13 May '05

OTRS Right. When I want to forward or send back a mail on OTRS (infoen queue, since Sannse is not there right now, the queue keeps growing...), I get an error Software error: Wide character in subroutine entry at /opt/otrs/Kernel/cpan-lib/MIME/Decoder/QuotedPrint.pm line 74. For help, please send mail to the webmaster (noc(a)wikimedia.org), giving this error message and the time and date of the error ------ So, it is not possible anymore to forward mails. Idea ? Thanks Anthere

2 1

grant wiki
by Anthere 13 May '05

13 May '05

Hi I know it is a minor preoccupation basically, but it is important for us to have a private wiki on which we can prepare some paper stuff. We sometimes do so on the grant wiki, but this one is half broken. For 10 edits you make on it, 9 result in a 404. This has been going on for a long time now. I would really really really appreciate if someone could have a look one day and fix it. It would really be helpful. Thanks Ant

2 2

Parsers
by Andrew Rodland 13 May '05

13 May '05

Hello, all. I'm posting here at the suggestion of Ævar Bjarmason, who let me know about the recent discussion here about the parser. Recently I've been working on parsing wikitext for some projects of my own, and because I think that a general-purpose parser is just a good thing to have. In any case, I've made significant progress on a Perl implementation. I'll link to the code below, but what I think is more interesting is the english. As far as I can tell, it is possible to parse wikitext in a "single pass" fashion, and it's possible to do it quickly (more on that once I finish the last few features I need to enable benchmarking). In fact, I believe that if one is willing to forgo the TOC at the top, it's possible to parse and render incrementally (though for various reasons that's probably not such a great idea). With regard to http://www.usemod.com/cgi-bin/mb.pl?ConsumeParseRenderVsMatchTransform my code is of the "consume/parse/render" variety. Anyway, I'll stop rambling on about it, and get to the point. At this point, I doubt that my code is clean enough or useful enough for anyone else to make use of it, but I'm mentioning it in case it provides any insight or grounds for discussion, or in case anyone would like to base work off of it or make suggestions. The code is part of BerliOS project "wikioncd"; svn is at svn://svn.berlios.de/wikioncd/trunk/wikioncd (the parser, with a temporary driver, is in parser.pl); the ViewCVS for same is at http://svn.berlios.de/viewcvs/wikioncd/trunk/wikioncd/ . Cheers Andrew

4 3

Watchlist: Making parts invisible
by Karl Eichwalder 13 May '05

13 May '05

On my Watchlist, I'd like to make some more part invisible using CSS; unfortunately, IDs are missing or other attributes are missing, not to mention the lack of proper block elements ;-( "<body>" has class="ns--1" - is this reserved for Watchlist pages only? This is a part I don't need to see every time: <h1 class="firstHeading">My watchlist</h1> <div id="bodyContent"> <h3 id="siteSub">From Wikipedia</h3> <div id="contentSub">(for user "Keichwa")</div>  <i>(1498 pages watched not counting talk pages; 3333.33333333 total pages edited since cutoff; checking watched pages for recent edits... <a href='/w/index.php?title=Spezial:Watchlist&magic=yes'>show and edit complete list</a>.)</i><br /> <hr /> ---- The amount of "total pages" is always a little bit strange. "3333.3333 total pages"?!? -- http://www.gnu.franken.de/ke/ | ,__o | _-\_<, | (*)/'(*) Key fingerprint = F138 B28F B7ED E0AC 1AB4 AA7F C90A 35C3 E9D0 5D1C

2 2

Paris servers: underpowered
by David Monniaux 13 May '05

13 May '05

I've run a number of tests on the Paris servers (following from complaints from a British ISP complaining of slower access times from Paris than from Florida). They show that: * We have no connectivity/bandwidth problems (we shoot up to 100 megabits/s to major French ISPs, which is the limitation brought by our Ethernet uplink; not so long ago the same was true of the Florida cluster). * Under light loads, the machines give pages 3x faster than the Florida cluster (.24s vs .67s; that's to be expected, there's a 100ms RTT to Florida that cannot be avoided, for instance) * The machines are WAY TOO SLOW under heavy load. They are Celeron 600s, slower than my old laptop! So essentially, there's no problem with the hosting and networking. It's just that the machines don't follow the load. -- DM Tests under light load: * PARIS SERVERS / 20 SIMULTANEOUS CLIENTS $ siege -c 20 http://fr.wikipedia.org/wiki/Accueil ** siege 2.62 ** Preparing 20 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 638 hits Availability: 100.00 % Elapsed time: 23.52 secs Data transferred: 37.13 MB Response time: 0.24 secs Transaction rate: 27.13 trans/sec Throughput: 1.58 MB/sec Concurrency: 6.50 Successful transactions: 638 Failed transactions: 0 Longest transaction: 3.20 Shortest transaction: 0.07 * FLORIDA SERVERS / 20 SIMULTANEOUS CLIENTS $ siege -c 20 http://de.wikipedia.org/wiki/Hauptseite ** siege 2.62 ** Preparing 20 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 918 hits Availability: 100.00 % Elapsed time: 54.11 secs Data transferred: 28.94 MB Response time: 0.67 secs Transaction rate: 16.97 trans/sec Throughput: 0.53 MB/sec Concurrency: 11.29 Successful transactions: 918 Failed transactions: 0 Longest transaction: 3.68 Shortest transaction: 0.57 So it's 3x faster to fetch a page from a not much loaded Paris cluster than from Florida, which is probably nice for French users. Tests under higher load: * PARIS SERVERS [chloe] / 100 SIMULTANEOUS CLIENTS $ siege -c 100 http://fr.wikipedia.org/wiki/Accueil ** siege 2.62 ** Preparing 100 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 6163 hits Availability: 100.00 % Elapsed time: 87.62 secs Data transferred: 360.31 MB Response time: 0.90 secs Transaction rate: 70.34 trans/sec Throughput: 4.11 MB/sec Concurrency: 63.09 Successful transactions: 6163 Failed transactions: 0 Longest transaction: 9.80 Shortest transaction: 0.12 Note the sharp increase in response time. CPU is 80-95% on chloe under such tests. $ siege -c 200 http://fr.wikipedia.org/wiki/Accueil ** siege 2.62 ** Preparing 200 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 5257 hits Availability: 100.00 % Elapsed time: 60.64 secs Data transferred: 307.35 MB Response time: 1.74 secs Transaction rate: 86.69 trans/sec Throughput: 5.07 MB/sec Concurrency: 150.46 Successful transactions: 5257 Failed transactions: 0 Longest transaction: 34.87 Shortest transaction: 0.24 * FLORIDA [www11], HIGH LOAD $ siege -c 200 http://de.wikipedia.org/wiki/Hauptseite ** siege 2.62 ** Preparing 200 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 7111 hits Availability: 100.00 % Elapsed time: 47.08 secs Data transferred: 222.15 MB Response time: 0.81 secs Transaction rate: 151.04 trans/sec Throughput: 4.72 MB/sec Concurrency: 122.22 Successful transactions: 7111 Failed transactions: 0 Longest transaction: 10.71 Shortest transaction: 0.57 * FLORIDA, EVEN HIGHER LOAD $ siege -c 500 http://de.wikipedia.org/wiki/Hauptseite ** siege 2.62 ** Preparing 500 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 12160 hits Availability: 100.00 % Elapsed time: 45.41 secs Data transferred: 379.88 MB Response time: 1.33 secs Transaction rate: 267.78 trans/sec Throughput: 8.37 MB/sec Concurrency: 354.86 Successful transactions: 12160 Failed transactions: 0 Longest transaction: 15.02 Shortest transaction: 0.68 * FLORIDA, EVEN HIGHER LOAD $ siege -c 600 http://de.wikipedia.org/wiki/Hauptseite ** siege 2.62 ** Preparing 600 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 9504 hits Availability: 100.00 % Elapsed time: 38.13 secs Data transferred: 296.91 MB Response time: 1.79 secs Transaction rate: 249.25 trans/sec Throughput: 7.79 MB/sec Concurrency: 445.22 Successful transactions: 9504 Failed transactions: 0 Longest transaction: 15.89 Shortest transaction: 0.71

1 0

benchmarking ielo.net
by David Monniaux 13 May '05

13 May '05

I wanted to know whether we had bottlenecks for the small Paris cluster, so Mederic and I ran a "siege" experiment (using the fr welcome page: it is so frequently accessed it's bound to be in RAM) on the Paris squids. We came from two networks: - Renater (French academic network) - ProXad (free.fr, major French ADSL provider; Med has a 16 Mbits/s connection there) It all went well; we simply reached about 8.2 megabytes per second (measured as something like 100 megabits/s), which means we saturated the fast ethernet link and switch between our machines and the Lost Oasis router. -- DM

1 3

request for block of website
by Walter Vermeir 13 May '05

13 May '05

http://encyclopedie.izynews.be/fr/lexw.aspx?doc=Special%3aRecentchanges http://lexikon.izynews.de/de/dir/default_fr.aspx?u=http%3a%2f% 2flexikon.izynews.de%2fde%2flexw.aspx%3fdoc%3dSpezial%253aRecentchanges http://lexicon.izynews.be/nl/lexw.aspx?doc=Speciaal:Recentchanges The are running a live copy of Wikipedia at the expence of the Wikimedia foundation. Can the be blocked? Greetings, [[w:nl:gebruiker:Walter]]

2 1

← Newer
1
...
10
11
12
13
14
15
16
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2005