apertium-tagger needs -x sometimes about apertium-init HOT 8 CLOSED

How does one check that? (and if it's possible programmatically, shouldn't apertium-tagger do it?)

from apertium-init.

I think we just need a new CLI flag...

from apertium-init.

Using the -x option with a non-perceptron .prob file throws an exception right away:

apertium-eng$ echo "hello world" | apertium -d . eng-morph | apertium-tagger -g -x eng.hmm.prob
terminate called after throwing an instance of 'DeserialisationException'
  what():  can't deserialise 1 byte integer type: can't deserialise byte
Aborted

Not using the -x option with a perceptron .prob file leads to a segfault, just as mentioned.

apertium-eng$ echo "hello world" | apertium -d . eng-morph | apertium-tagger -g eng.prob
^C

Not too sure whether this is useful, but might be.

from apertium-init.

But I have seen a different kind of error too:

apertium-tur$ echo "Bir kitap okudum" | apertium -d . tur-morph  | apertium-tagger -g -x tur.prob 
apertium-tagger: Unimplemented opcode:  at global #0 address #0
Try 'apertium-tagger --help' for more information.

from apertium-init.

I just thought of this recurring problem, maybe we can start to solve this in a more low-tech way by just having different filename suffixes for different models and have humans deal with the selecting right options when needed?

from apertium-init.

The really low-tech way to solve this is to just default to adding -x if the language is eng, since I think that's currently the only language that uses perceptron.

from apertium-init.

For init, that sounds like the best thing to do, since no one will have time to implement the Right solution while dealing with the overwhelming deluge of issues opened due to lack of -x in new pairs … only slightly exaggerating :)

from apertium-init.

Fixed in apertium/apertium@5c5edd9

from apertium-init.