Timwi wrote:
> The performance (as in, speed) is very good.
>
> The implementation is not. It strips away all apostrophes. It is
> therefore impossible to use categories that contain an apostrophe in
> their name, e.g. [[Category:Children's literature]]. I am finding it
> hard to imagine this as an accident; you must have written code
> explicitly to remove apohstrophes instead of escaping them properly. Why
> didn't this ring an alarm bell in you? :-p
>
>
Thanks Timwi, for taking a look. Sorry, I've got to admit that the
implementation was rather hacked together in a hurry. I did indeed write my
input cleanup to strip out a lot of characters, cutting with a sword instead
of a scalpel. But my main goal was to get the basic functionality out
there.
I've also just added a logging routine to collect statistics on it's
performance. I'm getting the query, the time to run the query with a limit
of 30, and the total number of results available (to look for correlations
to large datasets). Any other ideas?
(http://aerik.com/wikintersections.php for anyone that missed it earlier -
it runs off a copy of the relevant tables from November.)
Best Regards,
Aerik
Hi All,
I was really hoping get some feedback on the performance of my proof of
concept intersections page at http://aerik.com/wikintersections.php -
anybody?
This is using the MyISAM table with categories stored as words in one row
per page, fulltext indexed. It was a bit faster and much more consistent on
my local machine, but I'd really like anybody interested in intersections to
throw queries at it and beat it up - see if this might be an efficient
enough solution for prime time.
Of course, some difficult to anticipate factors are that if category
intersections are adopted and become popular, we will likely see a movement
towards more implied categories ("Americans" and "Actors" instead of
"American Actors") and fewer deep categories. I can imagine the effect this
will have on the index (fewer keywords with each having more entries). I
think this works okay as "+Living_people
+Articles_with_unsourced_statements" (two very large catgories) performs
well.
Thanks,
Aerik
P.S. I've been testing this by clicking the links, then picking some other
existant article from the wikipedia entry at the previous intersection. I
have a lot of noise in my result time, so in a pure form, I think the
approach is good with results often coming in in less than .5 seconds, but
sometimes the same query, or a query of similar complexity will come in at 2
seconds. I don't know how to extrapolate this to a theory of how it would
perform on the live servers.
I switched our memcached server to another server and now I'm seeing alot of
"Error parsing memcached response" errors, probably because the new cache
doesn't have the items the old cache had, for both images and message cache.
How can I reset the status in Mediawiki of the memcached server?
Thanks,
Travis
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19329).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
19 still FAILING test(s) :(
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Parsing optional HTML elements (Bug 6171)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
* TODO: Don't fall for the self-closing div
* TODO: Always escape literal '>' in output, not just after '<'
Passed 484 of 503 tests (96.22%)... FAILED!
I need this extension:
http://meta.wikimedia.org/wiki/Chr2syl
installed on the Cherokee Wikipedia. Is there a page somewhere on meta
for this purpose to request Brion to install the
extension for editing in Sequoyah Syllabary? I did not see a page for
requesting extensions installed. I know when I install
extensions, I have to do it from the unix login and its not normally
possible to install them from the web interface.
Any assistance would be appreciated.
Thanks
Jeff
Hi,
I was reading about MySQL's Falcon engine (which appears to have reached an
alpha branch), and was wondering if anyone had tried it with Mediawiki, and
for that matter the whole Wikipedia dataset. Curious to know how it behaves,
and how much efficiency the compressed storage engine gets...
Alex
Well, you might not understand the text but the sense:
This is what you can create with JavaScript:
http://www.mrbbc.org/files/de/cloudlevels.htm
Simply imagine the graphic above at this place:
http://de.wikipedia.org/wiki/Wolke#Internationales_System
Should we include such JavaScript features and graphics and animations
into MediaWiki ?
Unlike Flash or SVG this solution should work for most visitors. This
state of JavaScript is directly supported from all current browsers
since above 4 years or more. - SVG isn't far enough yet. You can view
static vector graphics, but animations AFAIK only with special plugins.
---
My technical recommendation would be to implement an additional
parameter for links that is filled into the onmouseover- and onmouseout
attribute of the created HTML elements, i.e. the <a> and <area> tags,
see http://www.mediawiki.org/wiki/Extension:ImageMap
Further you should include a JS file with standard functions that could
be used for interactive graphics. And last but not least you may have to
add some HTML elements and CSS formatting into every Wiki page.
---
* TOOLTIPS
There should be several kinds of tooltips. First the most simple one
only containing text, second text and graphic like mine, and third only
a graphic, maybe without this tooltip border stuff.
Let us name them e.g. tt1, tt2 and tt3 or better ttt(ext),
ttt(ext_and)i(mage) and tti(mage), maybe also ttit when the image should
be on the left side... So in the JS file you've get functions named
tttshow(content), tttishow(content, image) and so on, further of course
ttthide(), tttihide() or simply (and more safe) tthide() which hides all
tooltip boxes.
- Or maybe the only one (or both) when you make a flexible tooltip,
where you change the whole parameters of the inner table. (the second
tooltip box might be the one that only contains an image and therefore
needs not to be changed except of the shown image)
The size of the images should be further fixed - e.g. 120x90, which
might be adapted for ridiculuted displays by using maybe CSS. On the
other hand... someone who can afford a 12 inch display with 1680 by 1050
pixels should also have enough money for a magnifying glass...
---
A Wiki link with tooltip will for example look like this:
[[Cirrus||Tooltip:Cirrus (Ci), auch:
Federwolke#Image:Cirrus_over_Warsaw%2C_June_26%2C_2005.jpg]]
(I assume the third column of a Wiki link is not yet used; an empty
column will be ignored, i.e. if the link would be written out, the
content of the first column will be used instead)
- You might also put such scripts into the description column, but then
you can't put a tooltip above the text of a link (although this might
not be sensible anyway).
The HTML generator can be intelligent enough to determine which tooltip
function is to be called, i.e. what to fill in the onmouseover and
onmouseout attributes...
I made my first hypertext experiences with ST Guide; there you could not
only define full articles (called node) but also small descriptions
(called p(opup)node), that popped up in a small box when you clicked
them. Maybe you might define in a Wikipedia article also small
explanations for the respective term that are then inserted as a tooltip
above any link in other articles linking to that term...
I.e. for example when you move your mouse cursor above the word
"atavism" a tooltip pops up e.g. with the text "evolutional throwback to
older forms". So you won't have to click the link when you only need to
know what a term means to understand the statement. - Just a suggestion.
I know that this increases the server load (everytime when the Wiki
syntaxis is translated into HTML).
---
* ANIMATIONS
That's too much for me now. I think of course you may make something
like with the ImageMap extension:
http://www.mediawiki.org/wiki/Extension:ImageMap
where you write down in principle a list of movable pictures their
positions and movement...
There are only two types of animations to support: silhouette animations
and slide shows. For videos the only sensible way is a video file format
like MPEG. But maybe you might also draw lines and simple geometric
forms inside this animations...
First draft:
<animation>
Image:Foo.jpg|640px|picture of a foo
#0
show 1 0 0 Image:bar.png|32px
hide 2 0 0 Image:bar2.png|32px
#1 2
move 1 32 0
desc A bar goes its way...
pause 60
desc
wait
</animation>
First line is the main picture/background and description of the animation.
#0 introduces the base animation frame. Maybe there you've got to
specify all used images
show/hide are specifing movable images; "1" and "2" are for adressing,
"0 0" are their initial coordinates in pixel relatively to the
background image.
#1 is the second animation frame that appears when you run the animation
the second number is the time in deciseconds that all images moved
inside this frame will need to reach their destination coordinates
move moves an image; the first number/letter etc. addresses the image,
the following numbers are destination coordinates where the image will
move linearly...
desc displays a text in the description block of an animation; a single
desc in the line will clear the description block, it does not reset
simply with the next frame. Along with desc you might also play a wave
file that "reads" the same text.
pause waits for the next frame n deciseconds, wait stops the "animation"
until the user hits the mouse button or a key.
END OF LINE
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19290).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
19 still FAILING test(s) :(
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Parsing optional HTML elements (Bug 6171)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
* TODO: Don't fall for the self-closing div
* TODO: Always escape literal '>' in output, not just after '<'
Passed 484 of 503 tests (96.22%)... FAILED!
On 15/01/07, ivanlanin(a)svn.wikimedia.org <ivanlanin(a)svn.wikimedia.org> wrote:
> Note: Please revert if this breaks the backward compatibility of this extension.
Ack! Sorry if my earlier mini-rant scared you off - it doesn't
actually break anything, it just looks a bit peculiar in MediaWiki <
1.9.0.
You'll typically know if you make a breaking change to some of my code
because I'll get even more sarcastic and hideous than usual and
probably revert you with something snide.
Rob Church