VrrtepCLI

[Tirea Aean]

Interesting. When I did it by hand, it was always pretty much guaranteed to be the correct version because by the time I manually dumped the files and uploaded them to skxawng.lu, it was days after the dictionary PDF updated. So each time you downloaded it was almost without a doubt the correct version.

[Tsyalatun te Eyktan Txuratu'itan]

So, what this means is there is no sane way to ensure that the vrrtep data files are correctly versioned.  I'm going to modify the scripts so that it pulls the entire SQL data every hour and regenerates the vrrtep dictionary data if the SHA1 sum of the SQL file changes.  This will mean the "dictversion.txt" file will be useless for telling what version of the data you have.

Okay, the "fix" which I've just put in place is as follows:
1. The script will run at 5 minutes past the hour.
2. If there is any change in the NaviDictionary PDF or the base data, a new version of the vrrtep dictionaries will be published.
3. The version data is now made up of two things - the PDF version and an 8 hex digit "hash" of the base data.

What this means is that if you see the dictionary version update, and the hash number does not change, that means that the vrrtepcli dictionary data has not changed - either there was no change to the base data, or the base data has not updated yet.

So, what you will find is at the time of writing, the vrrtepcli dictionary version is: "12.893-5ab707e7" - "12.893" is the PDF version, and "5ab707e7" is the truncated hash of the base data.

Again, anyone spots any problems, please let me know.

[Tsyalatun te Eyktan Txuratu'itan]

Interesting. When I did it by hand, it was always pretty much guaranteed to be the correct version because by the time I manually dumped the files and uploaded them to skxawng.lu, it was days after the dictionary PDF updated. So each time you downloaded it was almost without a doubt the correct version.

I'll be able to tell as further updates happen - I've arranged for the script to tell me the modification times of the dictionary and SQL data whenever there's a change.

At the moment, the two SQL data files that I have seem to indicate that the SQL data gets updated once a day at around 0900 UTC.  Within the last 36 hours, we've had three updates to the PDF, so even if the script was run manually, it would have retrieved the 0900 UTC data (which did have the tìftang si change) but none of the others.

If my suspicions are true, and assuming that the cronjob on eanaeltu is independent of daylight savings, running the script at around 0930 UTC each day should result in correct and consistent version/data generation, because Mark is unlikely to update the dictionary data at that time (over in the US, in theory you're all asleep at that time!)

[Tsyalatun te Eyktan Txuratu'itan]

Kaltxì ma frapo!

Apart from an outage last week caused by the power supply in the machine breaking  (and everything that could go wrong going wrong with getting that fixed - long saga  ) it looks like everything is again good, and the updates are working correctly - for example, as of 0600UTC today, you have postì.  However, if anyone does spot an error which is not in the main Na'vi to English dictionary, please post here.

Irayo!

[Blue Elf]

Today vrrtepcli seems to stop working....
I upgraded my office PC from old good Windows XP to newer bad Windows7. I installed vrrtepcli (standalone version for windows). Today after installing tons of windows updates, vrrtepcli crashes when searching for any Na'vi word:

Code Select Expand

C:\Windows>vrrtepcli skxawng
Vrrtep CLI v1.94.2 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

Traceback (most recent call last):
 File "vrrtepcli.py", line 407, in <module>
 File "vrrtepcli.py", line 403, in main
 File "vrrtepcli.py", line 123, in transnav
ValueError: substring not found
any idea what goes wrong? Datafiles are up to date (ver. 12.96), but when I try to search by English word, nothing is found.
I'm not sure if it worked before applying updates, but on my home PC with Windows7 all works well (but I do to install any updates...)

Ignore this message - I found newer version of vrrtepcli (1.95) in Google project and it works. In fact, I used 1.95 on Windows XP too, and I believe I use at home too. I didn't notice I installed the old one....
It's Monday, my brain doesn't work so early

[Swoka Ikran]

I found newer version of vrrtepcli (1.95) in Google project and it works. In fact, I used 1.95 on Windows XP too, and I believe I use at home too. I didn't notice I installed the old one....
It's Monday, my brain doesn't work so early

As you discovered, the message is due to using an old version. It's caused by the new format dictionaries.

As for it being Monday...I know that feeling.

[Blue Elf]

BTW - can be download page at Google project updated with version containing correct updater so one do not need replace update script by version from the first post on this page?

[Swoka Ikran]

BTW - can be download page at Google project updated with version containing correct updater so one do not need replace update script by version from the first post on this page?

Done

[Blue Elf]

Data error found:

Code Select Expand

C:\Windows\System32>vrrtepcli -l -i admit
Vrrtep CLI v1.95.0 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

Query matches:
vin. pllngay pllng<1><2><3>ay
But correct infixes are p<1><2><3>llngay

[Tirea Aean]

Data error found:

Code Select Expand

C:\Windows\System32>vrrtepcli -l -i admit
Vrrtep CLI v1.95.0 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

Query matches:
vin. pllngay pllng<1><2><3>ay
But correct infixes are p<1><2><3>llngay

Nice catch! I've updated server-side script. You just have to run vrrtepcli -u soon.

[Tsyalatun te Eyktan Txuratu'itan]

Data error found:

Code Select Expand

C:\Windows\System32>vrrtepcli -l -i admit
Vrrtep CLI v1.95.0 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

Query matches:
vin. pllngay pllng<1><2><3>ay
But correct infixes are p<1><2><3>llngay

Nice catch! I've updated server-side script. You just have to run vrrtepcli -u soon.

Is there a reason these fixes aren't propagated into the main SQL data dump from eanaeltu?  The status of them (copied from the SQL) is:

emr<1><2><3>ey (appears corrected, yay!)
yemst<1><2><3>okx (still needs your fixup)
'awn<1><2><3>ìm (still needs your fixup)
newom<1><2><3>um (still needs your fixup)
pllng<1><2><3>ay (the new one needing fixup)

[Tirea Aean]

Data error found:

Code Select Expand

C:\Windows\System32>vrrtepcli -l -i admit
Vrrtep CLI v1.95.0 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

Query matches:
vin. pllngay pllng<1><2><3>ay
But correct infixes are p<1><2><3>llngay

Nice catch! I've updated server-side script. You just have to run vrrtepcli -u soon.

Is there a reason these fixes aren't propagated into the main SQL data dump from eanaeltu?  The status of them (copied from the SQL) is:

emr<1><2><3>ey (appears corrected, yay!)
yemst<1><2><3>okx (still needs your fixup)
'awn<1><2><3>ìm (still needs your fixup)
newom<1><2><3>um (still needs your fixup)
pllng<1><2><3>ay (the new one needing fixup)

Because I have no control over the official Eana Eltu Database. I have no LearnNa'vi.org shell access. Mark would have to know how to edit the Perl scripts to hack in these fixes. From what I saw from the Perl code, it guesses these infixes by using the normal infixing rules, and having no consideration for compound words.

If I had LN shell access I would have done it that way rather than updating our serverside vCLI update scripts.

[Tsyalatun te Eyktan Txuratu'itan]

Is there a reason these fixes aren't propagated into the main SQL data dump from eanaeltu?  The status of them (copied from the SQL) is:

emr<1><2><3>ey (appears corrected, yay!)
yemst<1><2><3>okx (still needs your fixup)
'awn<1><2><3>ìm (still needs your fixup)
newom<1><2><3>um (still needs your fixup)
pllng<1><2><3>ay (the new one needing fixup)

Because I have no control over the official Eana Eltu Database. I have no LearnNa'vi.org shell access. Mark would have to know how to edit the Perl scripts to hack in these fixes. From what I saw from the Perl code, it guesses these infixes by using the normal infixing rules, and having no consideration for compound words.

If I had LN shell access I would have done it that way rather than updating our serverside vCLI update scripts.

I notice Tuiq's removed the code off his github, so we can't even look at the code anymore.

[Tirea Aean]

Oops. Should have checked out a local copy of the code when I had the chance.

[Tìtstewan]

Kaltxì ma Tirea,

I try to run this vrrtepcli on win x64... I've installed the Python v3.3.2
Well, how I run it?

[Tirea Aean]

Kaltxì ma Tirea,

I try to run this vrrtepcli on win x64... I've installed the Python v3.3.2
Well, how I run it?

THat's your problem. This will NOT run on Python 3.x because of the HUGE changes they did in Python from 2 to 3. The README.txt says to install 2.6 or 2.7

[Tìtstewan]

Meeehhh.... pelun. I'm going to search for a 2.7 version...

[Tirea Aean]

Meeehhh.... pelun. I'm going to search for a 2.7 version...

Because in 2011, at the time I did this, I was running Ubuntu, which shipped with Python 2.6 (It tested well on 2.7 Windows Python version) And much of the world was still using 2.6 and 2.7 and 3.0 was gonna be a massive program-breaking update. I guess now it's finally come out to be the current standard.

Did they finally take it down from their website? Python.org

If so, I will certainly consider rewriting a version of this to work well for Python 3.x

[Tìtstewan]

They have this:
Python 2.7.5 Windows X86-64 Installer

[Tirea Aean]

They have this:
Python 2.7.5 Windows X86-64 Installer

that will work nicely