Re: [RFC][PATCH] Add analyzed token readings to failed bad sentence test output
On 2014-08-11 10:01, Silvan Jegen wrote: > to this list? Maybe it would be best to automatically generate a mail > to > this dev list whenever a Github issue has been opened... I was thinking about this again: considering the traffic on this list and in the issue tracker, maybe it's better not to do that by default. I recommend everyone who's interested in LT implementation details to use the "watch" feature at github. With that, you'll get an email for all actions in our github issue tracker. Regards Daniel -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [RFC][PATCH] Add analyzed token readings to failed bad sentence test output
Am 2014-08-11 10:18, schrieb Daniel Naber: > On 2014-08-11 09:01, Silvan Jegen wrote: >> Maybe it would be best to automatically generate a mail to >> this dev list whenever a Github issue has been opened... > > I agree. Do you know an easy way to set that up, or do we need to > create > a fake user that watches the issues? I searched on the web for an easy solution but I think there is only one way to achieve this. Configure either a new user to be notified or create a new organisation and do the same[1]. Maybe someone knows of a better solution for that? [1] https://help.github.com/articles/configuring-notification-emails-for-organizations -- ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [RFC][PATCH] Add analyzed token readings to failed bad sentence test output
On 2014-08-11 09:01, Silvan Jegen wrote: > Just for future reference: To discuss code changes, do you prefer > opening a Github issue (with or without code) or should we send an > email > to this list? If you already have a patch and the change is not totally intrusive, please make a pull request. > Maybe it would be best to automatically generate a mail to > this dev list whenever a Github issue has been opened... I agree. Do you know an easy way to set that up, or do we need to create a fake user that watches the issues? Regards Daniel -- ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [RFC][PATCH] Add analyzed token readings to failed bad sentence test output
Am 2014-08-11 01:07, schrieb Daniel Naber: > On 2014-08-10 17:37, Silvan Jegen wrote: > >> If including the analyzed token readings is useful in other assertion >> messages as well, it may also be better to refactor the token reading >> code into its own function and making it less ad hoc. >> >> What do you think ? > > Thanks, I have committed your changes (plus some more newlines, to make > the output easier to read). Thanks! Using fail directly is certainly better. Just for future reference: To discuss code changes, do you prefer opening a Github issue (with or without code) or should we send an email to this list? Maybe it would be best to automatically generate a mail to this dev list whenever a Github issue has been opened... Cheers, Silvan -- ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [RFC][PATCH] Add analyzed token readings to failed bad sentence test output
On 2014-08-10 17:37, Silvan Jegen wrote: > If including the analyzed token readings is useful in other assertion > messages as well, it may also be better to refactor the token reading > code into its own function and making it less ad hoc. > > What do you think ? Thanks, I have committed your changes (plus some more newlines, to make the output easier to read). Regards Daniel -- ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
[RFC][PATCH] Add analyzed token readings to failed bad sentence test output
If a rule test fails because no error has been found in the bad example
sentence, one of the reason can be that the tokenization of the bad
sentence example does not match the expected one in the rule itself.
To identify these cases more easily, add the token readings to the
assertion message.
Signed-off-by: Silvan Jegen
---
Hi
I had difficulties when creating Japanese rules because the mecab program
I used to determine the tokenization of the example phrases produced
different tokens than the tokenization library used in languagetool.
It took me quite a while to find out why the errors in my bad example
sentences where not found. Having the tokenized readings of the bad
sentence examples in the assertion message makes it easier to identify
issues with tokenization.
I realize that this change may be less useful for languages with easier
tokenization but I still think it would be nice to discuss whether
it would make sense to include this output. Maybe there is another
functionality in languagetool, that I do not know of, that would make
the suggested changes unnecessary?
If including the analyzed token readings is useful in other assertion
messages as well, it may also be better to refactor the token reading
code into its own function and making it less ad hoc.
What do you think ?
(If you want to include the patch, I can open a pull request on Github
if you prefer)
Cheers,
Silvan
.../org/languagetool/rules/patterns/PatternRuleTest.java | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git
a/languagetool-core/src/test/java/org/languagetool/rules/patterns/PatternRuleTest.java
b/languagetool-core/src/test/java/org/languagetool/rules/patterns/PatternRuleTest.java
index 0d5580d..d279b36 100644
---
a/languagetool-core/src/test/java/org/languagetool/rules/patterns/PatternRuleTest.java
+++
b/languagetool-core/src/test/java/org/languagetool/rules/patterns/PatternRuleTest.java
@@ -22,6 +22,7 @@ import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.lang.String;
+import java.lang.StringBuilder;
import java.util.*;
import junit.framework.TestCase;
@@ -281,9 +282,17 @@ public class PatternRuleTest extends TestCase {
}
if (!rule.isWithComplexPhrase()) {
-assertTrue(lang + ": Did expect one error in: \"" + badSentence
-+ "\" (Rule: " + rule + "), but found " + matches.size()
-+ ". Additional info:" + rule.getMessage() + ", Matches: " +
matches, matches.size() == 1);
+if (matches.size() != 1) {
+ final AnalyzedSentence analyzedSentence =
languageTool.getAnalyzedSentence(badSentence);
+ final AnalyzedTokenReadings[] analyzedTR =
analyzedSentence.getTokens();
+ final StringBuilder sb = new StringBuilder("Analyzed token
readings:");
+ for (AnalyzedTokenReadings atr : analyzedTR) {
+ sb.append(" " + atr.toString());
+ }
+ assertTrue(lang + ": Did expect one error in: \"" + badSentence
+ + "\" (Rule: " + rule + "), but found " + matches.size()
+ + ". Additional info:" + rule.getMessage() + ", " +
sb.toString() + ", Matches: " + matches, matches.size() == 1);
+}
assertEquals(lang
+ ": Incorrect match position markup (start) for rule " + rule
+ ", sentence: " + badSentence,
expectedMatchStart, matches.get(0).getFromPos());
--
2.0.4
--
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel
