VrrtepCLI

[Swoka Ikran]

I'm working on porting that test.cmd into a test.sh So far, it works, but the $LOG is rather ugly in some tests.

Ugly logs were an issue for me as well, although in my case it was (once again) unicode issues. Output of special chars was garbled

Windows Python has some strange behavioral issues with shoving data into the STDIN on the command line as well (one of my reasons for using SK.exe, the other being multiple repetitions within a single program instance). Does linux have issues with this?

[Tirea Aean]

Yeah, Mine cannot use the same instance, it keeps running the program several times.

The log is okay, even with utf8, until it gets to the interactive tests:

Running Test 7 of 14 (Interactive English-Na'vi):
vrrtep:>
vrrtep:> Query matches:
vin. pängkxo

Running Test 8 of 14 (Scramble output check):
^[[H^[[2J^[[H^[[2Jword: yt'e

vrrtep:> word: ettwi

vrrtep:>
^[[H^[[2J^[[H^[[2Jword: ontrtrx

vrrtep:>
Kehe. :\ score: 0 / 1 ( 0.0 % )
ans: trrtxon
word: xmtreä

ANd so, I might just rig my script to have me test those parts manually.

[Blue Elf]

^[[H^[[2J^[[H^[[2J seems to be ANSI Escape sequences. They're for actions like cursor movement etc.

[Swoka Ikran]

Yeah, Mine cannot use the same instance, it keeps running the program several times.

The log is okay, even with utf8, until it gets to the interactive tests:

Running Test 7 of 14 (Interactive English-Na'vi):
vrrtep:>
vrrtep:> Query matches:
vin. pängkxo

Running Test 8 of 14 (Scramble output check):
^[[H^[[2J^[[H^[[2Jword: yt'e

vrrtep:> word: ettwi

vrrtep:>
^[[H^[[2J^[[H^[[2Jword: ontrtrx

vrrtep:>
Kehe. :\ score: 0 / 1 ( 0.0 % )
ans: trrtxon
word: xmtreä

ANd so, I might just rig my script to have me test those parts manually.

Yuck. ANSI sequences in the output. Looks like manual testing is definitely a good idea here.

Off topic fact about the test code: The core code behind SK.exe wasn't even originally made for this purpose. It was part of a larger program I wrote in Feb. 2010 that was used by scripts for installing Windows at tech school. I just added a looping function and made it into a standalone.

[Swoka Ikran]

Just uploaded 1.93's Windows zip files.

[Blue Elf]

Today I tried this:

Code Select Expand

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

vrrtep:> close to
Query matches:
adp. lok

C:\WINDOWS>vrrtepcli lok
Vrrtep CLI v1.93 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

v. approach
I'd expect to find lok both as adposition and verb. Is it error or some limitation?
And another idea - is it possible to add wildcard search (like vrrtepcli le* to find all words starting with le) ?

[Tirea Aean]

Today I tried this:

Code Select Expand

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

vrrtep:> close to
Query matches:
adp. lok

C:\WINDOWS>vrrtepcli lok
Vrrtep CLI v1.93 by Tirea Aean
Windows version by Swoka Ikran
Standalone version

v. approach
I'd expect to find lok both as adposition and verb. Is it error or some limitation?
And another idea - is it possible to add wildcard search (like vrrtepcli le* to find all words starting with le) ?

I think it is a limitation. I will look into fixing that.

EDIT: I know why. it's because "close to" and "approach" are not the same, or similar.

Wildcard.. now THAT's an interesting idea... I think I can maybe find a way to implement wildcards... It might be a while though.. Thanks for the suggestion!

PS: New dictionary version today, I'm running the update procedure right now. (nothing huge, but just sayin)

[Tirea Aean]

So I talked with our good friend Talis today, who just started using the app. (Windows 7)

He is running into unicode trouble in both the German<-->Na'vi directions. The .cmd switches the codepage to 437, and he is using the Lucida Console font. Yet the problem still exists.

Despite that, he came up with a really nice easy way which is more familiar to Windows users to run the program: add a goto loop in the vrrtepcli.cmd, rename it, and make slightly altered copies of it with different arguments. that way, you can doubleclick it from the Explorer and it runs continually until you close it with the big red X.

Here is his .vrrtepcli folder, in a zip. http://tirea.skxawng.lu/.vrrtepcli.zip

ma Swoka Ikran, can you confirm this? Also, Go ahead and commit if you like the idea and agree that it would be beneficial to Windows users

[Swoka Ikran]

So I talked with our good friend Talis today, who just started using the app. (Windows 7)

He is running into unicode trouble in both the German<-->Na'vi directions. The .cmd switches the codepage to 437, and he is using the Lucida Console font. Yet the problem still exists.

I'll look into it. Unit tests don't cover the localization features, so I probably missed something. Is it just in the translator, or does it affect everything?

Despite that, he came up with a really nice easy way which is more familiar to Windows users to run the program: add a goto loop in the vrrtepcli.cmd, rename it, and make slightly altered copies of it with different arguments. that way, you can doubleclick it from the Explorer and it runs continually until you close it with the big red X.

The goto loop idea makes sense. I can definitely add a "vcli_shell.cmd" that implements it.

Including numerous CMDs for access to various features is update hell waiting to happen, so I'd prefer not to do this if possible. I could, however, have the app ask for the arguments/display a menu at startup when run from explorer. What do you think about this instead?

Alternatively, he can make shortcuts to vrrtepcli.cmd that do the exact same thing as the CMDs. Right-click vrrtepcli.cmd->Create shortcut. Open the shortcut's properties and add the arguments of your choosing to the end of the Target. Repeat for each feature you want, then use the shortcuts instead.

Here is his .vrrtepcli folder, in a zip. http://tirea.skxawng.lu/.vrrtepcli.zip

ma Swoka Ikran, can you confirm this? Also, Go ahead and commit if you like the idea and agree that it would be beneficial to Windows users

The zip file just contains a few CMD files. I understand what he means by having CMDs like this for use in explorer...but as I said above, it will get ugly when it comes to be update time. It'd be about 30 CMD files (~15 to cover all features, x2 since there's both Python and Standalone versions)...and they'd need to be updated with version info and any function changes at every update.

EDIT: Looked at the unicode issue...German language functions work fine on USA Windows XP It's something to do with his OS. If the codepage is indeed switching to 437 and LC font is being used, I'm not sure what else could be wrong. I don't have a German OS at my disposal to work with.

[Tirea Aean]

It wasn't a missing unicode(foo,utf8) ? I'm not sure. He did say that the quiz module handled everything wonderfully, no coding issues there. So strange.

I see you point with multiple .cmd files. Do with it how you please, I just like the idea of using explorer double-click on windows. It's more familiar for a windows user instead of opening a cmd.exe window.

[Swoka Ikran]

It wasn't a missing unicode(foo,utf8) ? I'm not sure. He did say that the quiz module handled everything wonderfully, no coding issues there. So strange.

Didn't see any, but I'll look again tomorrow when I'm not tired. It's almost 3am now...

I see you point with multiple .cmd files. Do with it how you please, I just like the idea of using explorer double-click on windows. It's more familiar for a windows user instead of opening a cmd.exe window.

I might do a text-based menu. That way its only one extra .CMD, but the user can still run it from explorer and have all the options. That way they don't need to use a command prompt if they don't want to.

The goto loop idea has been implemented. It'll go out whenever i commit next.

[Blue Elf]

It wasn't a missing unicode(foo,utf8) ? I'm not sure. He did say that the quiz module handled everything wonderfully, no coding issues there. So strange.

Maybe he hasn't set English as a default system locale (or how is it called in Win7)? In such case quiz and scramble games work still well, but problem is with searching words which contains accented chars (like ì, ä) - they aren't found.

I might do a text-based menu. That way its only one extra .CMD, but the user can still run it from explorer and have all the options. That way they don't need to use a command prompt if they don't want to.

Great idea! Although cmd prompt for me is good (as I'm old DOS user and also familiar with linux) - I don't know why colleagues laugh at me when using cmd prompt instead of some stupid win programs...

[Swoka Ikran]

Found a bug while working on the menu's command line builder...the argument parser doesn't like it when -n is set along with either -s or -q.

The -n option needs to be made mutually exclusive with respect to -s and -q.

Crash as seen when running vrrtepcli -s -n

Code Select Expand

C:\Documents and Settings\Owner\Desktop\vcli\Windows\vcli_win>vrrtepcli -s -n
Vrrtep CLI v1.93 by Tirea Aean
Windows version by Swoka Ikran
Python version

Traceback (most recent call last):
  File "vrrtepcli.py", line 349, in <module>
    main()
  File "vrrtepcli.py", line 290, in main
    navid = getnavid(wordin)
UnboundLocalError: local variable 'wordin' referenced before assignment

EDIT: And the Estonian language support is broken due to codepage limitations. Getting unicode errors because Estonian cannot be displayed on CP437...Estonian language requires CP1257, a special CP for Baltic regions (it provides support for Estonian, Latvian and Lithuanian languages). Na'vi cannot be shown on 1257.

It appears these 2 languages cannot coexist in the same program.

[Tirea Aean]

Found a bug while working on the menu's command line builder...the argument parser doesn't like it when -n is set along with either -s or -q.

The -n option needs to be made mutually exclusive with respect to -s and -q.

Crash as seen when running vrrtepcli -s -n

Code Select Expand

C:\Documents and Settings\Owner\Desktop\vcli\Windows\vcli_win>vrrtepcli -s -n
Vrrtep CLI v1.93 by Tirea Aean
Windows version by Swoka Ikran
Python version

Traceback (most recent call last):
  File "vrrtepcli.py", line 349, in <module>
    main()
  File "vrrtepcli.py", line 290, in main
    navid = getnavid(wordin)
UnboundLocalError: local variable 'wordin' referenced before assignment

EDIT: And the Estonian language support is broken due to codepage limitations. Getting unicode errors because Estonian cannot be displayed on CP437...Estonian language requires CP1257, a special CP for Baltic regions (it provides support for Estonian, Latvian and Lithuanian languages). Na'vi cannot be shown on 1257.

It appears these 2 languages cannot coexist in the same program.

Okay, so I made a new Vrrtepcli.py that handles unicode input and output, ridding terrible output once and for all (except IPA) I was testing on a fresh install of XP and it looked bad using German in one direction, so I fixed it up. and since you just said taht -n should be mutually exclusive, I have fixed that as well..

Here is the new vrrtepcli.py for Windows source:
http://tirea.skxawng.lu/source/vrrtepcli.py

EDIT: can't you just change the codepage based on a conditional instead of just changing it right off the bat?

DOUBLE EDIT: ALso, make sure that in rhyme.py that the file header looks like this

Code Select Expand


# -*- coding: utf-8 -*-
#!/usr/bin/python
#....


and not like this:

Code Select Expand


#!/usr/bin/python
# -*- coding: utf-8 -*-
#...


[Swoka Ikran]

Okay, so I made a new Vrrtepcli.py that handles unicode input and output, ridding terrible output once and for all (except IPA) I was testing on a fresh install of XP and it looked bad using German in one direction, so I fixed it up. and since you just said taht -n should be mutually exclusive, I have fixed that as well..

Here is the new vrrtepcli.py for Windows source:
http://tirea.skxawng.lu/source/vrrtepcli.py

Your IF '-n' in params is TRUE whenever -n is specified, so the elif '-s' in params and '-n' in params: is never reached. Same goes for -q. As a result, the program still crashes.

I've rearranged the IF statement so the incompatible argument checks are first. You might want to do the same in the Linux version.

Code Select Expand

         
## Fixes here to support unicode in interactive.
## You can't make Latin-1 from STDIN, so workaround used...
wordin = unicode(wordin,sys.stdin.encoding)
#wordin = wordin.encode("latin-1") // why not just go to utf8?
wordin = wordin.encode("utf-8")
## End fixes

Not sure why this was in there...it works fine going straight to UTF-8, so I'll leave it be. Getnavid() needed the 2 lines for Latin-1 -> UTF-8 conversion removed though.

EDIT: can't you just change the codepage based on a conditional instead of just changing it right off the bat?

The Baltic Rim 1257 codepage can't show Na'vi, so leaving the program in that codepage will cause the Na'vi to crash the program. If I switch out of it so I can show the Na'vi, the Estonian will crash it instead. Since neither CP is capable of both languages, a conditional won't help.

DOUBLE EDIT: ALso, make sure that in rhyme.py that the file header looks like this

Code Select Expand


# -*- coding: utf-8 -*-
#!/usr/bin/python
#....


and not like this:

Code Select Expand


#!/usr/bin/python
# -*- coding: utf-8 -*-
#...


Fixed.

Also, the new menu for Explorer users is finished http://swokaikran.skxawng.lu/temp/vclimenu.png You can guess why I chose blue for the text, but I can change that if it's too hard to read. What do you think?

[Tirea Aean]

Ah I see. that's lame...

Yeah I kinda just wrote that -n thing in like 30 seconds didn't really think much about it... Did you fix that?

in the current repo download win (python)version, the cmd does not handle argument looping correctly. upon further inspection, that cmd is not a direct translation of the sh counterpart, which might be why. I know I fixed arg looping in the sh

AWW that is sexy. can it still be somehow ran with args or is that the new face of the program each time you run it? how does it work? I wish I had a video but yah that is really cool.

[akiwiguy]

I think that blue is a bit hard to read, but that is still EPIC.

[Swoka Ikran]

Yeah I kinda just wrote that -n thing in like 30 seconds didn't really think much about it... Did you fix that?

Fixed as follows:

Code Select Expand

  if '-q' in params and '-n' in params:
        print "-n option unnecessary and incompatible with quiz.\n"
    elif '-s' in params and '-n' in params:
        print "-n option unnecessary and incompatible with Scramble.\n" 
    elif '-n' in params:

in the current repo download win (python)version, the cmd does not handle argument looping correctly. upon further inspection, that cmd is not a direct translation of the sh counterpart, which might be why. I know I fixed arg looping in the sh

The Windows console doesn't support most of the features that bash does, so a direct translation is impossible. Argument handling in Windows CMD is an ugly thing often done using SET, SHIFT, GOTO, and IF statements.

I'll look at it again, but getting it to work may be difficult.
Scratch that...appears fixed.

AWW that is sexy. can it still be somehow ran with args or is that the new face of the program each time you run it? how does it work? I wish I had a video but yah that is really cool.

The app works just like previous versions. Vrrtepcli <args> still runs it from the command line as it always has

The menu is an entirely separate CMD that automatically builds an argument list and passes it to vrrtepcli.cmd. It's made to be run from explorer.

You open it, then select options by pressing a key and ENTER. Leaving the prompt blank starts with the options selected. Playing with the menu options was how I discovered the -s -n bug  The user's local language is also saved so they don't need to choose every time.

I think that blue is a bit hard to read, but that is still EPIC.

That's what I was thinking...I'll use Cyan instead.

EDIT: And now I've got to figure out why words aren't found when ä and ì are passed in on the command line...something broke when I updated to the new vrrtepcli.py

EDIT2: Figured out the unicode issue...turns out that's why this strange code was in there:

Code Select Expand


## You can't make Latin-1 from STDIN, so workaround used...
wordin = unicode(wordin,sys.stdin.encoding)
wordin = wordin.encode("latin-1") # why not just go to utf8?

I'd forgotten what it was for, but a failed unit test answered it real quick. To answer the comment's question: Because the argument handler's unicode support breaks.

EDIT3: What version should this be? 1.94? I'll commit everything tomorrow afternoon if no more bugs crop up

[Tirea Aean]

I think you can call it 1.94.

Also, idk if yall noticed but in the lin/mac version, I stripped away the
"vrrtepcli v1.93 by Tirea Aean. Run vrrtepcli -h for usage
blahblah"

every time you run it. now it only says
vrrtepcli v1.93 | run vrrtepcli -h for usage
when run interactively. Idk if you wanted to do that with win or not, not a huge deal.


I see. so arg looping most likely will not be seen in win version? of course using the ever-looping cmd from explorer might just make that seem not a big deal. did you say you can switch up the args at any time while working with the menu? does it ask you to switch menu settings after every word? I think I'll just download it when you commit and try it out on my XP VM.

[akiwiguy]

I'll test it also, when you commit.
I'll update the KnownBugs wiki page to include the Estonian language bug, and say that it's not easily fixable.