If you ask me: which of these three things do we need? I say: all three.
I'm not sure point 2 is a bug, but it should at least be looked at. It
should be easy to find the commit that broke it. Then we can decide what to
do next: whether it is indeed a bug, or whether it was a coincidence that
it used to work.
If you ask me: what is the best way to implement the dot 7? I say: solution
1 is the best, then 3, then 2.
Great that you're making more tests. Why would you get rid of the
dictionary tests? As far as I'm concerned your new tests and the old
dictionary tests can co-exist.
Bert
2017-01-12 22:49 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:
Hi Bert,
Ok. Perhaps then, if it were fixed, the
Pass2 addSeven addSeven
Would also work. I think it would make sense to do the actual test for
addSeven in the test part rather than the action part.
Unfortunately, this bug prevents me from trying to fix the problems with 8
dots grade 2 that has entered into the code at some time after version 3.0
in July. So, for now, Danish 8 dots, which is definitely the most widely
used with displays and note-takers, is rather broken.
I can see three ways to go from here. However, whatever I do, I would
definitely need the advise and help from either you or Christian:
1. The proper thing to do at this stage would probably be to
implement a “caps7” opcode. This opcode should specify that capsign is
achieved by adding dot 7 to the given cell, should set capsnocont to true,
and replace capsword by adding dot 7 to all affected cells. I understand,
however, that this will also be the hardest way to get around it.
2. If I could locate the commit in which the relevant change of
code has taken place, perhaps you or someone else could help me fix that
part of the code, so that I could still use my current “work-around”.
However, these changes were probably made for a reason, and perhaps it
would be difficult to make it totally backward compatible.
3. If the swap opcodes were fixed, I could try to use them to find
a new work-around using an invisible capsign, which is then being converted
to dot 7 in pass2, and using the reverse process for back-translation.
However, I feel this approach is rather shaky. So, even though the swap
opcodes should be fixed, I would rather not use this approach for making
contracted 8 dots.
As you can see, I am somewhat in doubt, and any advise you could give
would be greatly appreciated. Perhaps, with some proper guidance and
instruction, I can do some of the coding myself.
Whatever happens, I am currently making new yaml tests for all the Danish
tables to ensure that situations like this one will never show up again. I
expect it will be good to get rid of the rather lengthy dictionary tests,
anyway.
Best regards Bue
*Fra:* liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:
liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] *På vegne af *Bert Frees
*Sendt:* 12. januar 2017 13:02
*Til:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Emne:* [liblouis-liblouisxml] Re: SV: Re: are the swap opcodes broken?
Hi Bue,
You can use a swap name in the action part without having it in the test
part, that's no problem. All the matching dot patterns in the part within
brackets will still be swapped. For example, the following works:
pass2 $a %AddSeven
I thought it worked the other way around too (only in test part), but I
was wrong. So this doesn't work:
pass2 %AddSeven *
Anyway, it seems the problem you're having is not related to the swap name
being used in both the test and the action part, because my first example
(pass 2 $a %AddSeven) has exactly the same problem.
After some more messing around I see a lot of weird things happening with
the swapdd. I think we can conclude that it is indeed broken :(
2017-01-11 13:26 GMT+01:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:
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>:
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