El dv 23 de 04 de 2010 a les 17:25 +0200, en/na Jacob Nordfalk va escriure: > > > 2010/4/23 Francis Tyers <[email protected]> > El dv 23 de 04 de 2010 a les 16:38 +0200, en/na Jacob Nordfalk > va > escriure: > > > > > > > 2010/4/23 Francis Tyers <[email protected]> > > El dv 23 de 04 de 2010 a les 16:24 +0200, en/na > Kevin Brubeck > > Unhammer > > va escriure: > > > Hi, > > > > > > I thought I should mention this bug (or, these > bugs?) > > > > > > > > > http://bugs.apertium.org/cgi-bin/bugzilla/show_bug.cgi?id=104 > > > > > > on the mailing list since it can introduce a hang > in > > lt-proc. > > > > > > > > > I came across it while messing around with an XSLT > to remove > > certain > > > <e>'s from pardefs. > > > > > > The first issue reported there is odd but not > critical; you > > can get > > > spurious analyses if you have a pardef calling two > pardefs, > > where the > > > last one has only a single, empty <e>. > > > > > > The second issue, however, can lead to hangs. > Neither > > lt-proc nor > > > lt-comp nor validation reports anything here (so > watch out > > if you have > > > empty elements like this). > > > > > > > > > It's worth noting that this happens with both > lttoolbox and > > lttoolbox-java. > > > > > > Of course. The Java version is 100% compatible. > > > > > > BTW Jim and I found out that just adding a flag (-client) > speeds up > > the Java version considerably. Its now generally twice as > slow as the > > C++ version. > > > > > > > > Should I have a look or will Sergio do it? > > > > > Could you take a look at the Java version to see where the bug > is ? > > > > The bug is that lt-comp have made a node with an epsilon transiton > which points to the node itself. > > > This gives an infilite loop when we try to expand the set of states to > include those reachable without input: > > > private void epsilonClosure() { > for (int i = 0; i != state.size(); i++) { > TNodeState state_i = state.get(i); > // get the transitions consuming θ (the empty input > symbol) > Transition epsilonTransition = > state_i.where.transitions.get(0); > { > TNodeState tn = new > TNodeState(state_i.sequence.size()+1); > tn.where = epsilonTransition.dest; > ... > state.add(tn); > } > } > } > > > The question is whether lt-proc during load should check for such > things, to avoid hangs, or whether lt-comp should be checking for such > things.
Which is easier? And can they be automatically removed ? Fran ------------------------------------------------------------------------------ _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
