Jimbo,
Helga Jonat (H. Jonat) uses 66.47.62.78 for her IP address.
See: http://www.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=66…
Any user with sysop rights ought to be able to block her IP from Recent Changes.
If that fails, I can run a query to block either:
(A) her IP
(B) her username, or
(C) both A & B
Ed Poor
-----Original Message-----
From: Jimmy Wales [mailto:jwales@bomis.com]
Sent: Tuesday, December 03, 2002 12:16 PM
To: wikitech-l(a)wikipedia.org
Subject: [Wikitech-l] Reinstating ban on Helga
So, what's the easy/correct way to do this? I can't ban her username, so I want
to ban her ip. How do I find out her ip easily?
--Jimbo
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikitech-l
I know you said to reply to the talk page, but I'm so happy about the new design I must gush right here, too!
----
Erik, I really like this redesign of the Recent Changes page. I would like it available as a "verbose" option. Could we have a checkbox on our Set User Preferences page to see recent changes as "regular" or "verbose"?
I would especially like the verbose mode when investigating vandalism reports.
Ed Poor
Here's a proposal with a GUI mockup of a more powerful, dynamic Recent
Changes page, as I suggested earlier:
http://meta.wikipedia.org/wiki/Recent_Changes_redesign
Please post comments on the Talk page.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
Thanks for rebooting the server, Brion. One of these days, I'll have to learn how to do it myself.
Ed Poor
-----Original Message-----
From: Brion Vibber [mailto:vibber@aludra.usc.edu]
Sent: Monday, November 25, 2002 5:46 PM
To: wikipedia-l(a)wikipedia.org
Subject: Re: [Wikipedia-l] Help accessing Wikipedia?
On Mon, 25 Nov 2002, Zoe wrote:
> The Wikipedia seems to be inaccessible right now. Anybody know what's
> wrong and if it's something that's going to be fixed any time soon?
Up again.
I tried upping the priority on the simple queries used for loading up and
displaying pages to see if it would improve interactive performance, but I
don't think it helped much.
-- brion vibber (brion @ pobox.com)
Nick,
Your idea assumes that the "lag" problem is due to overloading a single machine, which plays double roles: database backeand and web server. So, if we divide the work amoung 2 or more machines, you expect faster throughput. Right?
(I'm just repeating the obvious to make sure that what's obvious to me, is what you really meant!)
I guess if we all pitch in $50 each we can buy another machine. Where should I send my money?
Ed Poor
As per Mav's request, the "View article" link is now context-dependent
(code in CVS). "View Wikipedia page" for Wikipedia: pages was too long,
so I use "View meta page" instead. I know we already have meta.wiki, but
nobody suggested anything better (even though I asked), and technically,
these are meta pages (pages about the encyclopedia).
I have included a German translation, but this *will* break translations
in other Wikipedias (i.e. English text will be shown). To fix this, text
for articlepage, imagepage, wikipediapage, userpage needs to be included
in Language??.php instead of the text for subjectpage.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
I made texvc render nicely-fomatted HTML sums products and integrals,
using tables.
Such HTML code would be insane to write by hand.
Anybody has any idea how to render fractions in HTML ?
tables with <hr> work but aren't really nice.
Maybe if <hr> was made to produce simpler line ...
Have fun.
Here is first version of TeX rendering extension to Wikipedia.
It's not production code yet.
Please comment.
= How does it work =
New preference is introduced which says whether to:
* always render images as PNGs
* render them as HTML if they are simple enough, or as PNGs otherwise.
* leave them as pseudo-TeX (mainly for text browsers where neither PNG
nor HTML rendering would be visible)
ISSUE 1: While HTML reduces bandwidth, it is much uglier, so default is PNG-only.
ISSUE 2: PNGs are rendered with "a bit too big" font. That's on purpose.
A big too big works well in big and medium resolution, and is still readable
in small resolution. But "a bit too little" with big resolution would be very
hard to read.
Also new table is introduced:
CREATE TABLE math (
math_inputhash char(32) NOT NULL,
math_outputhash char(32) NOT NULL,
math_html text NOT NULL,
UNIQUE KEY math_inputhash (math_inputhash)
);
math_inputhash is MD5 of input markup, math_outputhash
is MD5 of output markup, math_html is HTML rendering or ""
if it's too difficult for HTML.
ISSUE 3: MD5 should be stored in binary in final version.
OutputPage.php calls renderMath() for every occurence of <math></math>
in code. If user decided he likes pseudo-TeX, then that's the end.
Otherwise it checks in database whether it is already rendered or not.
If it is, then it either takes HTML or generates link to image.
ISSUE 4: Directory for math images should be configurable and it should be
also known to texvc (command line ? compilation option ?).
It should not be upload directory.
ISSUE 5: Maybe it should use a/ab/ab*.png like other images. Or maybe
Wikipedia servershould move to reserfs.
ISSUE 6: Image should have ALT= tag
If image/html isn't generated yet, texvc is called. If it fails, message
is generated.
ISSUE 7: this message should be localized.
ISSUE 8: texvc shouldn't be in cgi-bin or care should be taken it can't
be called with any evil options.
Depending on return value of texvc results are generated and put into table
for caching.
ISSUE 9: failures are not cached. In final version they should be cached,
but cleaned on every upgrade of texvc (which may support more
TeX than previous version).
Now texvc takes input in first argument.
ISSUE 10: I'd rather use stdin but proc_open (popen2 for perl hackers) appears
only in PHP 4.3, but PHP 4.2 is still the standard
Then it LALR-parses it. What it parses is not real TeX. If HTML contains &foo;
and TeX doesn't, this preudo-TeX will contain \foo anyway. This ensures
that it's very easy to use.
Then it is standarized and md5 of standarized version computed.
ISSUE 11: race condition of 2 runs of texvc trying to generate the same PNG,
will have to be investigated
ISSUE 12: texvc should check here whether output PNG already exists (HTML is fast
to generate so it doesn't hurt to regenerate it). It may happen not only
in case of race condition, but also if it was generated from different
input markup (say from "x + y", and we do it from "x+y" now)
Then it prints md5 and HTML (if any) on stdout.
ISSUE 13: PHP should not wait for texvc to finish from this point. texvc should
probably fork() here.
Now latex, dvips and convert (which in turn uses ghostscript) are called.
ISSUE 14: Latex creates some temporary files. They should be created in some
tmp/ directory, not in current directory.