(moving thread to tech list)
Jens Frank wrote:
> it starts happening again. Server performance is
> very slow, saving edits result in "No data"
> error popups but the page is saved.
>
> And now it says:
>
> Could not select database wikidb
>
> Commands out of sync; You can't run this command now
Well, this should hopefully start to narrow it down. Thanks for the report!
in DatabaseFunctions.php::wfGetDB():
if ( ! $wgDBconnection ) {
$wgDBconnection = mysql_pconnect( $wgDBserver, wgDBuser,
$wgDBpassword ) or die( ..... );
mysql_select_db( $wgDBname, $wgDBconnection ) or die( .... );
}
The error message comes up on the mysql_select_db, and is the first
thing we do after opening a connection; but since we're using persistent
connections, it could be left in an odd state after the last process...?
-- brion vibber (brion @ pobox.com)
The error report is as follows:
-----------------------------------------------------------------------
Could not select database wikidb
Commands out of sync; You can't run this command now
If this error persists after reloading and clearing your browser cache,
please notify the Wikipedia developers.
Hi there.
I've got a bright idea (imho) about a user interface for a table of
contents system in the wikipedia. I'm sure there's been a ton of
discussion of this subject before, I just don't know where. So please
forgive me if this is a commonly dismissed concept:
Each page could have a list of attributes that describe a location in a
unified hierarchy. There could be an interface for browsing this
unified hierarchy from the top down.
If these two (work intensive, perhaps) changes were made, the result
would be:
My entry on prince charles would state that it is located in two places
on the hierarchy:
/humans/royalty/european/british/
/humans/facial features/big ears/
My entry on orangutans would state that it is located in one place on
the hierarchy:
/animals/primates/apes/
Does anyone feel like discussion of this set of features is worth
while? Other methods for achieving a top-down hierarchy of entries
leap to mind. Feel free to email me privately about this if you do not
feel that it belongs on the list.
Thanks for your time,
Ben
Can someone help Branko with this? We'll just need a quick addition
to the apache conf.
----- Forwarded message from Branko Collin <collin(a)xs4all.nl> -----
From: "Branko Collin" <collin(a)xs4all.nl>
Date: Mon, 21 Oct 2002 22:39:04 +0200
To: Jimmy Wales <jwales(a)bomis.com>
Subject: registered www.wikipedia.nl
Hello Jimmy,
Are you the one I should talk to? I just registered www.wikipedia.nl
so that it can point to the Dutch Wikipedia.
I will sit on this domain for two years, then expect somebody else to
take it off my hands. If I understand correctly, the person or
company holding a .nl domain must be based in the Netherlands (see
the rules at <http://www.nic.nl> if you're interested). After this
period I will let the domain run out or transfer it to one of the
other nl.wikipedia.com regulars. (Or before that, if you so request,
and of course at cost price.)
Would it be possible to point this address to nl.wikipedia.com, or
possibly to a page disambiguating between the Dutch and the Frisian
Wikipedia? I can change entries in the zonefile (or make new ones). I
don't know too much about how this works, here's how it looks like
currently:
wikipedia.nl. A 217.115.192.15
mail A 217.115.192.22
* A 217.115.192.15
With kind regards,
--
branko collin
collin(a)xs4all.nl
----- End forwarded message -----
Hi list!
This message popped up as a result of investigation
why the new suite for Polish Wikipedia has so unpredictable
search results when words with non latin1 chars are searched.
But this is valid for Meta as well - which is UTF-8
as well (right?). Japanese, Korean, etc Wikipedias
are endagered as well, but havent' tested that.
I focused on three letter words, what is theoretically legal.
Three letter words (3LW) with one Polish language
specific letter (PLSL) can be searched,
although many silly matches are found.
3LW with two PLSL search fails with the prompt
"Badly formed search query"
3LW with three PLSL - the same as with one PLSL (strange!).
Exactly the same happens when I put Chinese ideograms
instead of PLSL.
It seems that word lengths aren't recognized correctly
("Badly formed..." message is shown when I enter 1-letter word!)
and/or words containing PLSL (or ideograms) are split somehow
in a strange way.
Based on search results my impression is:
non-latin1 letters are treated sometimes as separators
and sometimes as wildcards.
I guess that other bugs in searching non-latin1 words
can be reduced to this.
It would be nice for Polish users to have it fixed before
upgrade to Phase III. Other non-latin1 users would be
perhaps happier too :-)
User:Youandme
----------------------------------------------------------------------
Najlepsi nie maja watpliwosci... >>> http://link.interia.pl/f1667
Hi list!
To avoid confusion in cross-posting, forgetting about that,
splitted discussions among 3 different mailing lists, breading
new lists (see Anthere's lengthy post beneath),
I've got a proposition:
Let's make _only one_ mailing list called
of course wikipedia-l(a)wikipedia.org
Every message to be sent would be tagged by supplying
the header [Wikitech-l] and/or [Intlwiki-l] or other
in the first line of the post or in the subject field.
Daemon at the mailing list server would decide
(is it possible?) to who sent the fresh post it has just
received. It would be based on information which every
subscriber would enter during subscription process,
like marking check-boxes
"Please deliver me technical issues",
that is current [Wikitech-l]
"Please inform me about international issues",
that is [Intlwiki-l]
"Please inform me about xx language Wikipedia issues",
that is eg. [xxwiki-l]
You might ask, what to do with those who forget to enter
desired [...] tags (especially unexperienced users will do
this permanently).
One could be asked during subscription process
on what Wikipedia he/she spends the most of his/her time.
Then the daemon would sent his/her untagged message
like it was sent with respective tag
(as it would be the most probable target).
What to do when you forget to put one more extra [] tag?
Sent a blank message with only one line:
repost-last [tag1] [tag2] etc. Daemon would send to the respective
remaining subscribers - that way only once to every address!
(developers, does it sound too stupid?)
The remaining question is: how can I be informed about important
issues when I'm not subscribed to receive them?
(Sounds like more general question of communication issues, eh?)
Maybe through subscribing to messages containing selected
words or regexs + tagging messages with those keywords
like [Spanish], [Main_Page], [unification] etc. Don't know.
But definitely the proposed solution would be a step
to make the process of communication less upsetting
for multi-subscribers and towards unification of Wikipedias.
BTW, please, cross-post it to the Wikipedia-l ;-)
I conscioussly decided to receive less messages
than others do.
User:Youandme
On 17 Oct 2002 at 3:41, Anthere wrote:
>
> Hi everybody,
> I dunno about you all, but I am getting overly confused between all the different points discussed
> at the same time, url adresses, contents of a page we have not agreed to exist, common
> recentchanges, common servers or not, auto-redirection or not, cookies or not, common meta ...
> It's nice that so many ideas are proposed, but it's really getting confusing. Maybe even more to
> non-english speaking, and certainly for those not following all lists thoroughly.
> Another thing adding to the confusion is that *mailing list(s) matter*. I think that could be a point
> to start with, and one on which we could maybe easily agree on, which would be nice for a
> change.
> I already stated a couple of time, there was a problem with the definition of the mainlist and the
> interlist.
> 1)The main list is both used for internal english matters AND integrated wikipedia matters
> 2 The inter list was initially set up to take care of matters dealing with creating and organising
> inter wiki
> A side effect of 1) is that some en.wiki editors tend to generalize typical english matters to the
> rest of the wikipedias.
> A side effect of 1) is that all inter that want to be involved in the decision process have to register
> the main list. Thus making the inter list useless.
> A side effect of 2) is that new inter comers tend to believe they can post messages to the inter
> list, and trust the information there is complete. Both points being clearly untrue (especially since
> we sometimes forget to double post, on one, or on the other list)
> Other side effects are multiple cross posting between the two lists, implying
> - additional posting time (specially when we forget the cc)
> - additional reading time to check the message is the same
> - additional time for deletion
> - cluttering of the mail box
> - incomplete information for those who are not registered at *both* lists
> My belief is that we need to set up that issue.
> Ideally, I think there should be:
> 1) A "main" list, dealing with integrated issues (I don't know the best word to say that, I don't want
> to mean integration, I want to say issues important to the enlarged community)
> 2) Plenty of language-specific lists, among which the english list, to deal with naming
> conventions and majuscule/minuscule typo conventions. Lists only to be set up if there is a need
> and a demand of course.
> In concrete terms, for example
> Option1: either a new list (a "metalist") is created, and the mainlist deals with english matters
> (the inconvenience of that option will be that most people would continue nevertheless to post
> everything at the main list)
> Option2: the interlist really becomes the integrated list and the mainlist stays only for en.issues
> (that option could maybe be accompanied by an automatic registering process for english not yet
> on the interlist; but again, I fear lazyness will prevent this process, and posting will stay on the
> main list anyway; also, this might become a diplomatic issue to some)
> Option3: the main list becomes the main list (metalist), and a new en.list is created for english
> issues (is that possible that all users of the main list are automatically registered to that en.list,
> and an automatic message send for easy unsuscribing for those not interested to stay on it? it
> would make the switching process less labourious...)
> The 3rd process could be nearly transparent for english users, as most of the time, people reply
> to messages, so it won't change habits much. They will be registered to two lists, but ain't that
> the case of many already ?
> This option would help avoiding cross posting and information loss. It would save time. It would
> avoid mailbox cluttering. It will also make clearer that setting up an integrated encyclopedia is a
> one of the goals; not helping side projects to develop.
>
> A conceptual point is also bothering me, but I admit I have no idea to prevent that right now.
> That is the word "international" to be opposed to the english-speaking_main_wikipedia.
> It is just the same than the words "importation" and "exportation"; just depends on your own
> position.
> International has a smell of countries. While english versus non-english just have a smell of
> language. I like that option better.
> Just my thoughts. Sorry if it was too long and laborious task to read. But I think it important that
> somehow, one day, this mailing list issues are dealt with.
> Anthere
----------------------------------------------------------------------
Nie tylko dla bogaczy... pogoda! >>> http://link.interia.pl/f166e
On wikipedia-l, Andre Engels wrote:
> > The talk page for "Jehovah's witnesses" had 909 accesses just now.
> > Is that a record for a talk page?
>
> No, it's not. I did a query, and it was at 1090 in the meantime, but
> Talk:Main_Page, Talk:Julius:Caesar and Talk:List_of_famous_Canadians had
> more.
>
> The top 20 of most-read talk pages:
> Talk:Main Page 3508
> Talk:Julius Caesar 3479
When did these access counters start at zero? Are they ever reset
again, or will they just permanently grow?
I have similar counters in susning.nu, introduced on August 3, 2002,
and so far they have never been reset. I guess there could be cases
where a monthly or yearly average is more useful, emphasizing the last
month. But so far I haven't figured out how I want to do this, and
there might be a point in using the same method as someone else.
Technically, the implementation is not difficult. Counters could be
reset at the 1st of each month, or a sliding window can be used with a
bucket accumulator for each day where the 30th bucket is subtracted
from the sum once each day, or a decaying average can be inflated by a
computed percentage at regular intervals. The only difficult decision
is to choose which method to use. Is there a standard?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik
Teknikringen 1e, SE-583 30 Linuxköping, Sweden
tel +46-70-7891609
http://aronsson.se/http://elektrosmog.nu/http://susning.nu/
What would everyone think if I were to move all of the current UseMod
wikis to the new server? This might be a performance concern... I
just wanted to get an idea of what you all think...
--
"Jason C. Richey" <jasonr(a)bomis.com>
> Aside from my general distaste of the double-encoding, it doesn't
> handle the case of manual input: someone who types
> http://www.wikipedia.com/wiki/AT&T into their URL bar shouldn't
> end up at [[AT]].
If you ask me, they should. People who don't care about the
details of HTML/HTTP/etc. will either follow links or type "AT&T"
into the search box, and all is well. If they want to type in
URLs, then they have already committed themselves to knowing
about the quirks of URLs. One of those quirks is that the URL
http://...AT&T is badly formed, and the browser is allowed to
interpret it in more than one way. It might choose to interpret it
as "fetch the page http://...AT" and pass it the query string "T".
URLs are code--URLs are not user interface elements. If people who
choose to use URLs have to contend with their nuances as code,
that's OK.
Now, all that said, I understand that the web rose so fast that
we never had a chance to replace URLs with something usable, so
many users are forced to use them when they never should have been.
So I'm not opposed to making them easier sometimes. Let's make
them as simple as possible /but no simpler/. If we have to muck
with ampersands a bit just as we convert spaces to underscores,
then that's what we'll have to do.
> Err, make that "RewriteMap urlencode int:ampescape".
> BTW, the code for rewrite_mapfunc_ampescape() is mainly ripped
> out of the URI-encoding function ap_os_escape_path() in main/util.c
BTW, would you mind putting source like that on the server
in /usr/local/src? That's where I've got all the post-install
stuff including Apache, MySQL, etc.