Wikipedia vom 27.Juli 2007 für Tome Raider

All: thanks for feedback. I will generate new text-only files in coming days. Actually I almost had them ready and uploaded till Elch33 reported serious bugs.

Elch33: I fixed both issues. I never saw links to the same page before. Too bad TR3 does not support links to a section within a page. (#... links)

Itsme:
Tables for small cities will now be rendered better but not completely correct. I fixed some minor bugs, but the underlying issue is more far-reaching and will become more of an issue in the future.

Mediawiki introduced the current set of parser functions about a year ago. It is kind of a macro language.

http://meta.wikimedia.org/wiki/ParserFunctions

I added support for most of these functions, but not yet for #expr and #ifexpr, both handle possibly very complex calculations. Up till recently these functions were hardly used, but now more hacks in templates uses calculations.

Mediawiki parser function hacks are generally considered very ugly code, very inefficient, and hardly maintainable. I expect they will be replaced again (this is already a complete rewrite from earlier attempts) by something completely different. So I am not putting more effort it this anytime soon.

This means that code using #expr and #ifexpr can break the rendering.
So far this happens only on a few templates. Still 99% of all templates are parsed correctly. But these few exceptions are all templates that are often used (only then was it worthwhile to add such complicated code). For these cases as far as I could find them I provided some workarounds (sometimes stripping, sometimes replacing part of the template).

An example of clever but ugly code is: putting a dot on a map of Germany based on longitude an latitude coordinates. In other extreme cases nested longitude and latitude calculations can invoke up to 300 parser functions just to get one result. The same guy designed the UI-wise utterly hopeless and inconsistent wiki-table syntax, which almost everyone dislikes now. Of course that is no excuse for lack of support in my parser, time constraints are an issue though.

Example for Koblenz:
http://de.wikipedia.org/w/inde…n_Deutschland&action=edit
which invokes
http://de.wikipedia.org/w/inde…lage:Lageplan&action=edit

Quote

Original von ErikZachte
Elch33: I fixed both issues. I never saw links to the same page before. Too bad TR3 does not support links to a section within a page. (#... links)

Sounds great. And so quickly !!! But do I understand it right that you even fixed the second bug with the internal links or is there no way of amending it in TR3 ?

Best regards

Björn

The missing texts are shown, but not as links, just plain texts. At least the article is readable again.

Hi Erik

Do you think, that the performance will be better in the next release of the text-only-version? On my Treo 680 it really takes some time to type in the searched word...

Thanks again for your effort!!

Marco

I removed aliasses for the next release to see if that helps. If not, it is beyond my capacity to do somethings about it.

There is one other thing, possibly related (?) : in the newest Tomeraider release one can open a search edit box while an article is still being displayed. The normal procedure was to switch to index view and then type a search entry. My impression is that search while displaying the index is faster, than search while displaying an article. Possibly because in both modes the display is refreshed while one types, and refreshing for an index is of course much faster than switching to an new article.

Quote

Original von ErikZachte
I removed aliasses for the next release to see if that helps. If not, it is beyond my capacity to do somethings about it.

There is one other thing, possibly related (?) : in the newest Tomeraider release one can open a search edit box while an article is still being displayed. The normal procedure was to switch to index view and then type a search entry. My impression is that search while displaying the index is faster, than search while displaying an article. Possibly because in both modes the display is refreshed while one types, and refreshing for an index is of course much faster than switching to an new article.

Great that you solved the bug connected with displaying the internally linked words. I think it will do that the links don´t work, but the word itself is shown.

As to the quote above: I really appreaciate a lot to have all the aliasses in it and NOT OUT, because it gives you an enormous help when looking something up. So as I am one of those who will certainly buy the German image version once published, I would much request you to put all Alliasses in it again. I would of course also prefer that in the text-only version.

With regard to speed: in fact when searching the way you discribed above (e.g. in the display mode and not the index mode) this is a really cumbersome way of searching, cause every letter typed would open the relevant article which is currently in the search box. It is actualy much better to use the index search, and that should solve the velocity problem. Again, I would rather prefer alliases in the file, because I cannot really see why that should so much slow down the index search mode.

Best regards

Björn

... this is a really cumbersome way of searching ...

That is exactly my point, I hope people who complain about speed can check whether this has been the cause.

For now I am generating text-only versions without aliasses. So that people can compare speed. Let us wait for feedback to see what is best for image version.

Hi Erik

I was searching in "index-mode" and typing-in the characters was pretty slow. I'm curious about how it works without the aliasses.

Thanks again for your work
Marco

Hi Erik,

I am also searching in the Index-Mode, and it is as quickly and as comfortable as ever. No slowing down at all. Please, please put the Aliasses in at time or even produce two versions (with and without), if the speed problem with some other users really turns out to be the Aliasses. Again, I do not see any slowing down with the new script version.

For now I will finish the job as started, otherwise I'll keep restarting when someone finds something to fix. As said, people can then test if it makes any difference. Then we know for sure. For later editions and the image version we can see again, if there is still consensus to leave aliasses in.

Quote

Original von ErikZachte
For now I will finish the job as started, ...

Do you already know when you will have the new version available for download ?

Quote

Original von agruener

2. Search is always slow in your version on my Treo 650, also in index-search. Old version works fast and fine.

I reckon that this is a matter of TR3 on Palm versus TR3 on PPC. May be the Palm unfortunately works slower with the new script.

Kind regards

New editions are online.
Changes:
1 Bug fixes and some workarounds as discussed earlier
2 No aliasses
3 Input sorted by TR3 during compilation.

Make sure to refresh the page (F5), you should see a version with and without aliasses, both for PPC and Palm.

http://www.infodisiac.com/Wikipedia/DownloadFiles.html

Please comment on differences in index lookup for editions with and without aliasses, both for PPC and Palm.

Also please comment on the reported index lookup error on Palm, where some pages could not be found. I'm pretty sure the sort by my script is actually correct, but who knows what TR3 does while sorting the index again (apart from spending extra time).

Quote

Original von ErikZachte

Please comment on differences in index lookup for editions with and without aliasses, both for PPC and Palm.

Also please comment on the reported index lookup error on Palm, where some pages could not be found. I'm pretty sure the sort by my script is actually correct, but who knows what TR3 does while sorting the index again (apart from spending extra time).

Hi Erik,

i started testing the Palm-Version with Aliases on my T3:

a) Performance absolutly no problem.
I like the alias-version.
b) Most Town-Tables still missing, but your explanation in this post let me
understand the problem. Hard job...
c) Still errors opening articles between part of "M" and "O"
(for example "Montabaur"). The index seems to be ok,
but opening an article shows he correct headline, an then parts of
other articles.

At the moment im loading your file again without an download manager.
I dont think its the problem, just to be sure.
Because the MD5 shows me something not to be correct :-((

Something else you want us to look for in our tests?

And - btw - thanks for your work...

b) Most Town-Tables still missing, .........
c) Still errors opening articles ..........

Sorry if I was not clear about this. I only created new versions without aliasses, the ones with alliases are weeks old, with mentioned bugs, and only still available for comparisons. Please try the ones without aliasses for bugs fixed.

Hi Erik!
I've just downloaded the new version (without aliases) and it is working great for now . But is it possible that all articles which are starting with a german umlaut like ä,ö or ü are completely missing in the index?
For example, when searching for "Ärmelkanal" it jumps to 'A' instead of 'Ä'. I experienced the same behaviour when searching for "Überlingen". In addition I scrolled down the whole 'U'-section and couldn' find any entries beginning with 'Ü'.
Entries which have an umlaut as second letter are working fine..

Anyways, thank you for your great work!

Hi Erik,

I tested the non-allias version for PPC and, indeed, all reported bugs seem to be gone. Thanks a lot for that.

As to performance I do not note any difference, but - using a PPC and not a Palm - I hadn´t had any speed problems with the new script anyway. As "Men-at-Work" already suggested, the performance problem might only occur with Palms. (???) I do not know for sure, but I guess. So I am also strongly advocating for putting Alliasses back in for the next version. But let´s wait and see what others report. If the speed has now improved for Palm users and it becomes uninanimous consensus that for palms alliasses should kept out, you might want to produce the palm version without and the PPC version with alliasses. As I understand it, Palm users which want those alliases irrespective of the performance issue can also use the PPC version, right ?

Quote

Original von c-j-archer
Hi Erik!
I've just downloaded the new version (without aliases) and it is working great for now . But is it possible that all articles which are starting with a german umlaut like ä,ö or ü are completely missing in the index?
For example, when searching for "Ärmelkanal" it jumps to 'A' instead of 'Ä'. I experienced the same behaviour when searching for "Überlingen". In addition I scrolled down the whole 'U'-section and couldn' find any entries beginning with 'Ü'.
Entries which have an umlaut as second letter are working fine..

Anyways, thank you for your great work!

YOU have to write the Ä, Ö and Ü in capital letter, then it pops up in the index.

Best regards

Oh, yes. I only tried small letters. With capital letters it works :D.
Thank You!

Hi Erik

I just downloaded the actual version (without aliasses) for my Treo 680 and it's a lot faster than the previous version with aliasses! So there is no "waiting-time" anymore while typing in the searched word.

Now there are 2 possibilities:
- Faster because there are no aliasses anymore
- Faster because it was sorted already during compilation

What do you think?

Thanks a lot for your superb work
Marco