Hèctor Alòs i Font <hectoralos-re5jqeeqqe8avxtiumw...@public.gmane.org> čálii:
> I have the following paradigm definition in a bidix > > <pardef n="sup_0_mf"> > <e><p><l></l><r></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="m"/><s n="sg"/></l><r><s n="mf"/><s > n="sg"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="f"/><s n="sg"/></l><r><s n="mf"/><s > n="sg"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="m"/><s n="pl"/></l><r><s n="mf"/><s > n="pl"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="f"/><s n="pl"/></l><r><s n="mf"/><s > n="pl"/></r></p></e> > </pardef> > > and the following translation > > <e r="RL"><p><l>elegant<s n="adj"/></l> <r>elegante<s n="adj"/></r></p><par > n="sup_0_mf"/></e> > > The compilations works fine and there is no problem translating from left to > right. But when translating anything from right to left I get: > > Error: Invalid dictionary (hint: the left side of an entry is empty) > > The problem is in the first line of the pardef. If I change it, putting > anything, it works: for instance, when doing: > > <pardef n="sup_0_mf"> > <e><p><l><s n="mf"/></l><r><s n="mf"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="m"/><s n="sg"/></l><r><s n="mf"/><s > n="sg"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="f"/><s n="sg"/></l><r><s n="mf"/><s > n="sg"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="m"/><s n="pl"/></l><r><s n="mf"/><s > n="pl"/></r></p></e> > <e r="LR"><p><l><s n="sup"/><s n="f"/><s n="pl"/></l><r><s n="mf"/><s > n="pl"/></r></p></e> > </pardef> > > There are several forms to avoid this kind of "empty" lines in the pardefs, > but, in any case, I think there is a bug and it'd be fine to have it > corrected. It's definitely a bug, already reported at https://sourceforge.net/p/apertium/tickets/65/ but now I added a simpler test case to https://sourceforge.net/p/apertium/tickets/65/#34b1 So when compiled *right to left*, all the LR's are "skipped" and the pardef becomes <pardef n="sup_0_mf"> <e><p><l></l><r></r></p></e> </pardef> I've typically worked around it with a line that is unlikely to match anything, e.g. <pardef n="sup_0_mf"> <e><p><l></l><r></r></p></e> <e><p><l>NO_EMPTY_PARDEFS_WORKAROUND</l><r>NO_EMPTY_PARDEFS_WORKAROUND</r></p></e> <e r="LR"><p><l><s n="sup"/><s n="m"/><s n="sg"/></l><r><s n="mf"/><s n="sg"/></r></p></e> <e r="LR"><p><l><s n="sup"/><s n="f"/><s n="sg"/></l><r><s n="mf"/><s n="sg"/></r></p></e> <e r="LR"><p><l><s n="sup"/><s n="m"/><s n="pl"/></l><r><s n="mf"/><s n="pl"/></r></p></e> <e r="LR"><p><l><s n="sup"/><s n="f"/><s n="pl"/></l><r><s n="mf"/><s n="pl"/></r></p></e> </pardef> which, when compiled RL, is interpreted as <pardef n="sup_0_mf"> <e><p><l></l><r></r></p></e> <e><p><l>NO_EMPTY_PARDEFS_WORKAROUND</l><r>NO_EMPTY_PARDEFS_WORKAROUND</r></p></e> </pardef> But we shouldn't have to. The fact that the binary of the simplified .dix prints to $ lt-print lr.bin 0 1 x x 1 0 <adj> <adj> 0 shows that lt-comp is doing something very weird here. Anyone have a clue what might be going on?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
