That's yet another instance of the broader problem that the library
our compilers use for processing XML doesn't actually store line
numbers correctly.

Probably the better approach in this case would be to print the rule
number and maybe its name and leave it to apertium-lint to give actual
positions.

Daniel

On Wed, Jun 28, 2023 at 12:19 PM Hèctor Alòs i Font
<hectora...@gmail.com> wrote:
>
> The improvement is huge. The compile time is now a looot faster! Many thanks, 
> Daniel!!
> As for the warnings, in principle it is OK. The problem is that the line 
> codes are not working, just as they didn't previously. If I "touch *t1x" and 
> recompile apertium-oci-fra, I get (after one or two seconds!) :
>
> $ touch *t1x
> $ make
> apertium-validate-transfer oci-fra.t1x
> apertium-preprocess-transfer oci-fra.t1x oci-fra.t1x.bin
> Warning at line 12933, column 15: Rule 97 has the same pattern as rule 4. 
> Skipping.
> Warning at line 15492, column 9: Rule 140 has the same pattern as rule 139. 
> Skipping.
> apertium-validate-transfer oci@gascon-fra.t1x
> apertium-preprocess-transfer oci@gascon-fra.t1x o...@gascon-fra.t1x.bin
> Warning at line 12983, column 32: Rule 98 has the same pattern as rule 4. 
> Skipping.
> Warning at line 15542, column 20: Rule 141 has the same pattern as rule 140. 
> Skipping.
> apertium-validate-transfer fra-oci.t1x
> apertium-preprocess-transfer fra-oci.t1x fra-oci.t1x.bin
> apertium-validate-transfer fra-oci@gascon.t1x
> apertium-preprocess-transfer fra-oci@gascon.t1x fra-...@gascon.t1x.bin
> Warning at line 12983, column 32: Rule 98 has the same pattern as rule 4. 
> Skipping.
> Warning at line 15542, column 20: Rule 141 has the same pattern as rule 140. 
> Skipping.
> apertium-validate-transfer fra-oci.t1x
> apertium-preprocess-transfer fra-oci.t1x fra-oci.t1x.bin
> apertium-validate-transfer fra-oci@gascon.t1x
> apertium-preprocess-transfer fra-oci@gascon.t1x fra-...@gascon.t1x.bin
>
> So, for instance, there isn't any rule in oci-fra.t1x which begins at line 
> 12933 or 15492. In addition, preprocessing often removes comments from rule 
> headers, so that even if you have the right line, it is not easy to find the 
> rule in the source code. I should put this as issues, but I have always been 
> lazy.
>
> Hèctor
>
>
> Missatge de Daniel Swanson <awesomeevildu...@gmail.com> del dia dl., 26 de 
> juny 2023 a les 23:01:
>>
>> Greetings Apertiumers!
>>
>> I recently identified a way that apertium-preprocess-transfer was
>> being rather inefficient and today I fixed it, so tomorrow you all
>> should be able to update to apertium 3.9.4 and see some improved
>> compile times for any pairs not using apertium-recursive, with
>> speedups between 10x and 7000x faster on the files I tested.
>>
>> I'm writing this email to let you know that in the process
>> apertium-preprocess-transfer lost the ability to report partial
>> overlaps like the following:
>>
>> Warning at line 6867, column 4: Paths to rule 27 blocked by rule 24.
>>
>> And I just wanted to let you all know, in case someone was depending
>> on those. To compensate, I added a check to apertium-lint which can
>> report roughly the same information:
>>
>> Warning (overlapping-paths) on line 6852: The sequence [preadv
>> vblex.pp n.*] matches both this rule and the rule on line 6628.
>>
>> Daniel, who is trying to get better at not doing things that
>> potentially break people's workflows without telling them
>>
>>
>> _______________________________________________
>> Apertium-stuff mailing list
>> Apertium-stuff@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>
> _______________________________________________
> Apertium-stuff mailing list
> Apertium-stuff@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/apertium-stuff


_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to