Hi Bue,
I have not much experience with swap opcodes. There are not many tables
that use them either.
At first sight these look like bugs to me too. However I'm not 100% sure
the swap classes are meant to be used this way (same class in both test and
action parts). I've done something similar (with swapcd) in
no-no-chardefs6.uti, and that seemed to work. Your second example (with
swapcc) also seems to work, apart from the last character problem.
The swap opcodes are mostly used in tables for math. In all of these rules
there is a swap class only in either the test part or the action part,
never in both. So my feeling is that is how it is supposed to be used.
So what happens if in your example you use the following rule instead?
pass2 %AddSeven *
Thanks,
Bert
2016-12-14 15:12 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:
Hi guys,
In an attempt to fix the problem with contracted 8 dots that I described
yesterday, I found out that the swap opcodes are apparently also broken. It
may of course just be me who is doing something stupidly wrong, but if so,
I would be happy if someone would put me on the right track.
I added the following two lines to a plain 8 dots computer Braille table,
e.g. da-dk-g08.ctb:
swapdd AddSeven 1,12,14,145,15,124,1245,125,24,245
17,127,147,1457,157,1247,12457,1257,247,2457
pass2 [%AddSeven] %AddSeven
Using lou_trace: when I input a, I get B back. When I input b, I get D as
the result. Typing abc gives BDF etc. It looks like something is being
incremented twice instead of once.
Just for the fun of it, I deleted the previous lines and added the
following two lines:
swapcc LowUp abcdefghij ABCDEFGHIJ
correct [%LowUp] %LowUp
This does not work for the last character in the string. Again using
lou_trace, if I type a, I get nothing. Typing apex gives Apex, but typing
zebra gives zebr.
It beats me why this hasn’t been caught by one of the tests. But, get to
think of it, probably not that many tables use the swap opcodes.
Has anyone had similar experience with these opcodes?
Bue
