Hello,
if one (hypothetically :-) wanted to help in finding bugs, should one start with the version of the software on sourceforge, in CVS, or is there a newer version? Also, if one (hypothetically) would fix a bug, should one just submit it to CVS or send it directly to Magnus/Jimbo?
On another note: somebody wrote a suggestion on the website that the slow response might be caused by one of the special features that have been added. Maybe that could be tested, by running the site for a while without watchlists, orphans, most wanted, page counters etc. When we had response problems with the old perl script, I remember it was due to too many RecentChanges accesses.
Axel
I think the latest version is on sourceforge. We may soon move the "canonical test version" to CVS here. I'm a little shaky on the details of how to do that, but Jason can help me, and presumably other people, too.
there a newer version? Also, if one (hypothetically) would fix a bug, should one just submit it to CVS or send it directly to Magnus/Jimbo?
For now, the best thing is to send patches to Magnus. He sends me patches every couple of days, and I install them when I can.
On another note: somebody wrote a suggestion on the website that the slow response might be caused by one of the special features that have been added. Maybe that could be tested, by running the site for a while without watchlists, orphans, most wanted, page counters etc. When we had response problems with the old perl script, I remember it was due to too many RecentChanges accesses.
Today, if I get time, or else tomorrow, I'm going to install the latest versions of PHP, Apache, and probably upgrade the kernel on the machine, too. Also, I bought memory, and I'll be boosting the memory in the machine today for sure.
I'm also looking into 'apc', which is a php caching thingy, which (it is alleged by the creators) gives a 50%-400% performance boost in real-world applications. We'll see about that.
I'm also thinking that we might want to think about caching the html output, rather than generating every page on the fly from the database all the time. Basically, when a page is simply read, it can be stored and also shown to the next person who reads it. Only when a file is edited does it need to be regenerated from scratch.
--Jimbo
Jimmy Wales jwales@bomis.com writes:
[...]
I'm also thinking that we might want to think about caching the html output, rather than generating every page on the fly from the database all the time. Basically, when a page is simply read, it can be stored and also shown to the next person who reads it. Only when a file is edited does it need to be regenerated from scratch.
Or when any previously nonexistant page it links to is created. It's my understanding that these links are saved in the database, so noticing this shouldn't be very hard.
From: "Jimmy Wales" jwales@bomis.com
I think the latest version is on sourceforge. We may soon move the "canonical test version" to CVS here. I'm a little shaky on the details of how to do that, but Jason can help me, and presumably other people, too.
I've downloaded the script file from CVS but it looks very old and the parser looks very rudimentary and very different from what is now running. Or is there also a script in the big zip file? I'd really like to chase some formatting bugs this weekend. So what I would like to get from somewhere is the latest script and some additional script that creates the necessary tables with enough contents to start running, without having to download the big zip file from sourceforge. Couldn't that be placed on Wikipedia somewhere?
Pretty please? :-)
-- Jan Hidders
I've downloaded the script file from CVS but it looks very old and the parser looks very rudimentary and very different from what is now running. Or is there also a script in the big zip file? I'd really like to chase some formatting bugs this weekend. So what I would like to get from somewhere is the latest script and some additional script that creates the necessary tables with enough contents to start running, without having to download the big zip file from sourceforge. Couldn't that be placed on Wikipedia somewhere?
I just uploaded the very, very latest version to SourceForge CVS. This is even more up-to date than the version I sent Jimbo yesterday, and certainly more up-to-date than the one that is currently running, which is about 4 days old :(
It has many bugfixes and some very minor "feature requests".
The CVSROOT is cvs.wikipedia.sourceforge.net:/cvsroot/wikipedia The package is phpwiki. THe code you want is in the fpw subdirectory.
Maybe someone should put this up on the wiki somewhere...
NOTE: This is *not* the code that currently runs on the sourceforge test site! It is the current bomis version!
I agree it would be best to have the CVS at bomis as well, like it was done for Nupedia.
Magnus
Magnus Manske wrote:
I just uploaded the very, very latest version to SourceForge CVS. This is even more up-to date than the version I sent Jimbo yesterday, and certainly more up-to-date than the one that is currently running, which is about 4 days old :(
This should be fixed by the end of today.
In other news, we upgraded the kernel on the machine and fiddled with some settings so that the machine now recognizes all 1 gig of memory.
I'll be upgrading the PHP and Apache today, if all goes well, and also installing Magnus's latest code.
The last two pages I tried to look at were full of gibberish, followed by boldface and underlined gibberish, and then MySQL error messages. See http://www.wikipedia.com/wiki.phtml?title=Sojourner_Truth The other page I tried to look at was Physical anthropology. Both links from "Recent changes."
We have a problem here.
On Thu, 31 Jan 2002, Axel Boldt wrote:
On another note: somebody wrote a suggestion on the website that the slow response might be caused by one of the special features that have been added. Maybe that could be tested, by running the site for a while without watchlists, orphans, most wanted, page counters etc. When we had response problems with the old perl script, I remember it was due to too many RecentChanges accesses.
I think this is a really good idea, on first glance.
Larry
wikipedia-l@lists.wikimedia.org