Hi Bert,
Unfortunately, that solution does not work It just gives the same character in
the output as in the input.
The manual says the following about the % sign:
% (percent sign)
the name of a class defined by the class opcode (see
class)
or the name of a swap set defined by the swap opcodes (see
Swap Opcodes).
Names may contain only letters. The letters may be upper or lower-case. The
case matters. Class names may be used in test parts only. Swap names are valid
everywhere.
I would have thought it pretty obvious to use the swap opcodes in exactly this
way: to replace items from a swap group in the test part with corresponding
items from the group in the action part.
Also, how can you use a swap name in the action part if you haven’t already
tested for it in the test part?
Bue
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] På vegne af Bert Frees
Sendt: 10. januar 2017 12:42
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] Re: are the swap opcodes broken?
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
<mailto: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
