VrrtepCLI

[Tirea Aean]

Correct. That is Windows CMD hating UTF-8. That's outside my jurisdiction as I don't know exactly how to fix that issue on Win..

Thanks for the info on Softpedia.

[Swoka Ikran]

Correct. That is Windows CMD hating UTF-8. That's outside my jurisdiction as I don't know exactly how to fix that issue on Win..

Actually, I think this issue is a broken dictionary. "Language" is the only word affected.

You need to check the dictionary entries for "language" and "lì'fya"...trying other words with ', ì, and ä gives no issue at all. I tested with "only", "here", and "chat".

Also, using standard USA English Windows, 1.94 dies with that error when doing vrrtepcli -l language, eliminating a locale issue.

[Tirea Aean]

I think you can be calm, ma Tirea.
Vrrtep is listed under Windows category, and version 1.93 is last Windows version of vrrtep (as Swoka ikran said already).
What is interesting, they didn't add it also under Linux category. Your developer page at softpedia links back to google code, it is not mirro or something like this, if I see well.
The only bad thing is that they did ask you for agreement. I see softpedia first time, so i have no idea how it works - maybe it provides only free software?

BTW, while playing with vrrtep, i found this:

Code Select Expand

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

vrrtep:> language
Query matches:
n. Traceback (most recent call last):
  File "vrrtepcli.py", line 349, in <module>
  File "vrrtepcli.py", line 317, in main
  File "encodings\cp437.pyc", line 12, in encode
UnicodeEncodeError: 'charmap' codec can't encode character u'\xcc' in position 1
: character maps to <undefined>
I expect it is because Czech locale (using Win 7 english, Czech locale installed, but default locale for nonunicode progs is english )

Code Select Expand

[corey@fedora ~]$ vrrtepcli -v
Vrrtep CLI v1.94
Dictionary Version:
12.322


Commandline args:

Code Select Expand

[corey@fedora ~]$ vrrtepcli -l language
Query matches:
n. 'Ìnglìsì
n. lì'fya
n. lì'fyavi
n. lì'fyaolo'
adj. lelì'fya


Interactive:

Code Select Expand

[corey@fedora ~]$ vrrtepcli -l
vrrtep:> language
Query matches:
n. 'Ìnglìsì
n. lì'fya
n. lì'fyavi
n. lì'fyaolo'
adj. lelì'fya


ten bucks says it's the Ì character. 'Ìnglìsì is the ONLY word with Ì (capital grave i)

for a test, try running

vrrtepcli -l English

then try editing metaWords.txt such that it has a lowercase instead of uppercase grave i.

Then try what you tried to do in the first place. if that fixes it, it's because your locale or cmd or something hates that character.

[THIS POST HAS BEEN EDITED A LOT OF TIMES.]

[Swoka Ikran]

Ì is not in CP437 and is not supported. Removing Ì from metawords does fix the problem. For some reason, I thought we fixed this bug a while back...

Also, why does "language" even return "'Ìnglìsì"? IMO, it does not fit well with the other, more general, terms it lists for "language".

[Tirea Aean]

Ì is not in CP437 and is not supported. Removing Ì from metawords does fix the problem. For some reason, I thought we fixed this bug a while back...

Also, why does "language" even return "'Ìnglìsì"? IMO, it does not fit well with the other, more general, terms it lists for "language".

I think I fixed it by replacing Ì with ì. but I updated the dictionaries and forgot to do that. 'Ìnglìsì comes up for -l language because:


[corey@fedora ~]$ vrrtepcli -l language
Query matches:
n. 'Ìnglìsì
n. lì'fya
n. lì'fyavi
n. lì'fyaolo'
adj. lelì'fya

[corey@fedora ~]$ vrrtepcli \'Ìnglìsì
n. english language

[corey@fedora ~]$ vrrtepcli lì\'fya
n. language

[corey@fedora ~]$ vrrtepcli lì\'fyavi
n. expression, bit of language

[corey@fedora ~]$ vrrtepcli lì\'fyaolo\'
n. language group, language users

[corey@fedora ~]$ vrrtepcli lelì\'fya
adj. concerning language, regarding language

[Swoka Ikran]

Ì is not in CP437 and is not supported. Removing Ì from metawords does fix the problem. For some reason, I thought we fixed this bug a while back...

Also, why does "language" even return "'Ìnglìsì"? IMO, it does not fit well with the other, more general, terms it lists for "language".

I think I fixed it by replacing Ì with ì. but I updated the dictionaries and forgot to do that. 'Ìnglìsì comes up for -l language because:


[corey@fedora ~]$ vrrtepcli -l language
Query matches:
n. 'Ìnglìsì
n. lì'fya
n. lì'fyavi
n. lì'fyaolo'
adj. lelì'fya

[corey@fedora ~]$ vrrtepcli \'Ìnglìsì
n. english language

We're gonna have to fix this with every update...there's got to be a better way than manually editing dictionaries. Maybe add code to correct it in the dict builder scripts?

[Blue Elf]

Yes, I remember that problem with 'Ì' was discussed here... I think it was "solved" by changing word in main dictionary but it was reverted back then.
I think correct solution is to check for 'Ì' before displaying the result and change it to 'ì' to avoid error

[Swoka Ikran]

Yes, I remember that problem with 'Ì' was discussed here... I think it was "solved" by changing word in main dictionary but it was reverted back then.
I think correct solution is to check for 'Ì' before displaying the result and change it to 'ì' to avoid error

So it was fixed before...then unfixed by accident.

It'd actually be easiest to permanently fix this the dictionary build script. One character and the whole app is fixed. I don't know what language the dict build script is in or what the build code looks like (it's not on the SVN for some reason), but this fix could be as simple as one line of code.

If you do it in the program, it has to be checked every time a Na'vi word is read from the dictionary. The read code is not shared between different modules, so it'd have to be fixed in several places. That means more work when porting new versions, more potential for bugs, etc.

[Tirea Aean]

Yes, I remember that problem with 'Ì' was discussed here... I think it was "solved" by changing word in main dictionary but it was reverted back then.
I think correct solution is to check for 'Ì' before displaying the result and change it to 'ì' to avoid error

So it was fixed before...then unfixed by accident.

It'd actually be easiest to permanently fix this the dictionary build script. One character and the whole app is fixed. I don't know what language the dict build script is in or what the build code looks like (it's not on the SVN for some reason), but this fix could be as simple as one line of code.

If you do it in the program, it has to be checked every time a Na'vi word is read from the dictionary. The read code is not shared between different modules, so it'd have to be fixed in several places. That means more work when porting new versions, more potential for bugs, etc.

I have the scripts. I actually have "hax" script that actually edits the metaWords.txt file before uploading to the update server. I can just add the "change Ì to ì" line in there and boom. done. I have all the code for updating the dictionary files on me. (Which reminds me, a new version is due, but I cant do it at this moment, I'll get to it soon) I did tihs so that the user does not have to worry about anything except running vrrtepcli -u which just downloads updated files off the server and moves them to the install dir.

[Swoka Ikran]

Glad that bug is fixed.

I'm in the middle of porting Lin1.94 to Windows...so much of the code in vrrtepcli.py is different now that I can no longer just copy the linux file and redo the unicode support. I have to manually update it by looking at diffs.

When it's finished, I'll probably release it as "1.94.1" so the version numbers for the Linux and Windows versions still match. There will be no "1.94.0" release for Windows.

Also, the linux version has a bug in it. Run vrrtepcli -s -n and it crashes because wordin is undefined when -s or -q is specified. You need to move the navid = getnavid(wordin) below the exclusivity checks. I ended up with the below for the Windows version.

Spoiler: Code

Code (Python) Select Expand


if '-n' in params:
        if '-s' in params and '-n' in params:
            print "-n argument is incompatible with Scramble game.\n"
            sys.exit()
        elif '-q' in params and '-n' in params:
            print "-n argument is incompatible with Quiz game.\n"
            sys.exit()
       
        # Put this here because another IF makes wordin undefined when -s or -q is set.
        navid = getnavid(wordin)
        if '-ipa' in params and '-l' not in params and '-i' not in params:


EDIT: Fixed code.

[Tirea Aean]

my version had an elif on [line 11 on your pic]

I inserted [lines 09 and 10 in your pic] into my  source code. <-- That actually broke it, so I reverted back. I will try to update dicts then commit my source. I think you're goin off an old vrrtepcli.py

also, my source does not need any unicode(blah,'utf-8') like yours does. You will need to insert those on your own where they go. (I'll comment them out on mine) Having those there are actually more bad tahn good on the linux version.

[Swoka Ikran]

my version had an elif on [line 11 on your pic]

I inserted [lines 09 and 10 in your pic] into my  source code. <-- That actually broke it, so I reverted back. I will try to update dicts then commit my source. I think you're goin off an old vrrtepcli.py

My base was r28, which was the Windows version of r23. I patched in the r29 and r30 changes.

The ELIF on line 11 was changed to IF as part of the fix for the -s -n crash.

Spoiler: The -s -n Crash in Linux 1.94 release

C:\Documents and Settings\Owner\Desktop\vcli\lin_release>python vrrtepcli.py -s -n
Traceback (most recent call last):
  File "vrrtepcli.py", line 345, in <module>
    main()
  File "vrrtepcli.py", line 285, in main
    navid = getnavid(wordin)
UnboundLocalError: local variable 'wordin' referenced before assignment

C:\Documents and Settings\Owner\Desktop\vcli\lin_release>

The code block from my last post is the fix for the above crash. I deleted the navid = getnavid(wordin) beneath if '-n' in params:. Then I inserted lines 9 and 10 and changed the ELIF on line 11 to an IF.

also, my source does not need any unicode(blah,'utf-8') like yours does. You will need to insert those on your own where they go. (I'll comment them out on mine) Having those there are actually more bad tahn good on the linux version.

OK.

Changes in Windows 1.94.1 so far:

• Support for infix positions with Na'vi words (r29/r30 features)
• Score saving for games
• -ipa option now shows a friendly error message instead of garbage or a crash dump.
• Bugfix for -s -n issue
• Program updater

The app needs testing, so I'll play with it some more before I commit it

[Tirea Aean]

ah okay, I'll make those changes.

EDIT: Changes made, it is all good. Good call.

DOUBLE EDIT: ALso, the dictionaries got updated. Might commit my code some time soon after some playing around.

[Swoka Ikran]

I've committed r31 (v1.94.1). That includes the above fix and the r29/r30 feature set.

I'll post zip files later tonight.

[Tirea Aean]

commit up.

added another try/except (bug fix), look out for it.

[Swoka Ikran]

commit up.

added another try/except (bug fix), look out for it.

I'll add that later tonight before I publish the zips. There's no point in posting a buggy release.

Look for r33.

EDIT: r33 committed. I also published zip archives of 1.94.2.

[Tirea Aean]

I havent zipped my latest either. I'll do it tomorrow.

EDIT: done. up for grabs.

[Tirea Aean]

[corey@fedora lin_release]$ vrrtepcli -n äpeykiyevängeyk
navid = ERROR
in for, inword = ;äpeykiyevängeyk;
ifERROR, navid = ERROR
antiprefixed wordin = äpeykiyevängeyk
outfixed wordin = eyk try for again
in for, inword = ;eyk;
navid = 304
vtr. lead | infixes: äp eyk iyev äng



mwahaha...

[Blue Elf]

Today I noticed (quiz game):

Word: sì

1 - no action or activity
2 - and (connects two things, can be attached as sì: for clauses use)
3 - satisfied, content, satiated, full

Seems data to be trimmed against those in dictionary:
sì: and (connects two things, can be attached as –sì: for clauses use ulte and)
No real problem, just reporting

[Tirea Aean]

thank you for reporting. as you may know, all dictionaries hav been updated as of last night. I will see about applying a hack to my update process to remove errors such as the one you reported.