On 22 November 2013 14:22, Mikel L. Forcada <[email protected]> wrote:
> Dear Sergio, dear list,
>
> Aida and I think we have found a bug in the t1x processor and we have chased
> it down to a single file containing only the definitions necessary and a
> single rule. Unfortunately, it has to be tested by installing
> apertium-eng-kaz (following the steps here:
> http://wiki.apertium.org/wiki/English_and_Kazakh (hfst and all!, sorry).

That shouldn't be necessary.

>
> How to test the (possible) bug: install apertium-eng-kaz, then replace
> apertium-eng-kaz.kaz-eng.t1x with the file with the same name in the dev/
> directory, compile, and run this test:
>
> echo "жазғанмын" | apertium -d. kaz-eng-transfer
>
> The output should be:
>
> apertium-transfer: Rule 1 жаз<v><tv><past><p1><sg>/
> write<vblex><past><p1><sg>/record<vblex><past><p1><sg>
> ^+++ HELLO, I AM THE WRONG RULE! +++ The following should be <ND> or
> <zzz>:<sg>$^default<default>{^.<sent>$}

'zzz', not '<zzz>' - the assignment is '<lit>', not '<lit-tag>' (and
to assign a tag, it would have to be declared in the relevant
def-attr).

>
> If you look at the rule, first the value <ND> to the number clip is assigned
> and then there is a <choose> block that tests for 1st person and assigns
> <zzz> to the number clip. None of these two values are printed; instead, the
> value extracted from жаз<v><tv><past><p1><sg> is printed, namely <sg>.
>
> We also saw some other strange behavior, but this was the easiest to
> reproduce.
>
> Basically, assignments to clips are overriden and the values obtained in
> previous assignments seem to prevail.
>
> We would appreciate it very much if someone could look into this bug.

You're trying to change 'sl'; apertium-transfer wasn't designed with
that in mind. I'm dimly aware that there was support added for input
lt-proc -b , I was not aware that the source would be preserved even
with that. Víctor wrote a while back about a bug in that support, that
involved a variable that was not used - are you using a version with
Víctor's patch applied? Similarly, it could be that sl output (if
there is any!) is coming straight from the input buffer.

But more fundamentally, do you actually intend to change sl?

>
> All the best
>
> Mikel
>
> P.S. Another behaviour we observed is that under some circumstances you
> cannot assign values to clips outside their definition range, but we haven't
> been able to isolate the problem.

You can only assign, using <lit-tag>, values that are included in the
part's <def-attr>. You can get around this with <lit> if you need to.

-- 
<Sefam> Are any of the mentors around?
<jimregan> yes, they're the ones trolling you

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to