Re: spell-checking only
Am 06.02.2013 19:42, schrieb Stephan Hennig: To get LanguageTool and the spelling package together, I have the following requests/questions: 3. Is there a way to use a user dictionary for spell-checking with LanguageTool? That is, a file containing correct spellings (false positives). Best regards, Stephan Hennig -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: spell-checking only
On 08.02.2013, 19:51:18 Stephan Hennig wrote: 3. Is there a way to use a user dictionary for spell-checking with LanguageTool? That is, a file containing correct spellings (false positives). There's resource/XX/hunspell/ignore.txt (XX being the language code). these words are ignored during spell checking. Regards Daniel -- http://www.danielnaber.de -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: spell-checking only
Am 08.02.2013 21:16, schrieb Daniel Naber: On 08.02.2013, 19:51:18 Stephan Hennig wrote: 3. Is there a way to use a user dictionary for spell-checking with LanguageTool? That is, a file containing correct spellings (false positives). There's resource/XX/hunspell/ignore.txt (XX being the language code). these words are ignored during spell checking. Ignored by all of LanguageTool's modules or by Hunspell only as the file path suggests? The spelling package provides it's own white list mechanism. But since it relies on an external spell-checker for finding misspellings (it can actually just highlight given words in PDF output during typesetting), in the manual I advise users to use a personal dictionary with the external spell-checker to cope with false positives. Is that possible for an ordinary user with LanguageTool 1. on the command-line, 2. via the HTTP server? Best regards, Stephan Hennig -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
public HTTP API
Hi, we have a public HTTPS endpoint running anyway for the LT Firefox plugin, so why not properly document it? Here it is: http://www.languagetool.org/http-api/ Let me know if any information is missing. Regards Daniel -- http://www.danielnaber.de -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: switching to Maven - done!
Daniel Naber wrote: There's now languagetool-commandline.jar. It would be nice to move all libs to a lib directory except the LT ones, but I'm not sure yet how that works. Thanks for that. When running mvn clean package, I see 2 jar files created: ./languagetool-standalone/target/LanguageTool-2.1-SNAPSHOT/LanguageTool-2.1-SNAPSHOT/languagetool-commandline.jar ./languagetool-commandline/target/languagetool-commandline-2.1-SNAPSHOT.jar Also the grammar.xml rules are copied twice. Example with French grammar xml: -rw-rw-r-- 1 pel pel 1250981 Feb 6 22:58 ./languagetool-language-modules/fr/src/main/resources/org/languagetool/rules/fr/grammar.xml -rw-rw-r-- 1 pel pel 1250981 Feb 9 00:59 ./languagetool-language-modules/fr/target/classes/org/languagetool/rules/fr/grammar.xml -rw-rw-r-- 1 pel pel 1250981 Feb 9 01:06 ./languagetool-standalone/target/LanguageTool-2.1-SNAPSHOT/LanguageTool-2.1-SNAPSHOT/org/languagetool/rules/fr/grammar.xml Is it expected to be copied twice? Is the duplication in the directory name .../LanguageTool-2.1-SNAPSHOT/LanguageTool-2.1-SNAPSHOT/... also expected? Regards Dominique -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: switching to Maven - done!
Richard Eckart de Castilho wrote: Without having had a look at the build, I would expect at least two things to cause: 1) Maven (like ant) is a Java application and it takes a moment to fire up the JVM. make is a native application. 2) The package goal always runs the full packaging (building of ZIPs and JARs from the compiled sources). So even if the compile is up-to-date, doing the packaging takes a moment. If further plugins, e.g. JavaDoc, have been activated during normal builds, they may further slow down the build. Understood for the overhead of running the JVM (multiple times?) during the build. But why would Maven mvn package always re-create the ZIPs and JARs when nothing has changed? There might be a good reason, but at first sight it seems like a waste of time. Shouldn't a build system try to do the least amount of work and rebuild only the targets for which at least one of their dependencies has changed, based on a DAG (Directed Acyclic Graph) of target/dependencies? Running mvn compile when nothing has changed is faster than mvn package but not really fast either. mvn compile takes 6.5 sec on my laptop when nothing has changed (nothing to compile), which is presumably much more than what the JVM needs to initialize when launching mvn. I was also searching for parallel builds in the hope of speeding up (something like make -j4 with GNU make). I found this... http://stackoverflow.com/questions/581465/maven-how-to-do-parallel-builds ... but it does not work. $ cd languagetool $ mvn -T 4 compile ...snip... [INFO] Building languagetool-parent 2.1-SNAPSHOT [INFO] [WARNING] * [WARNING] * Your build is requesting parallel execution, but project * [WARNING] * contains the following plugin(s) that are not marked as * [WARNING] * @threadSafe to support parallel building. * [WARNING] * While this /may/ work fine, please look for plugin updates* [WARNING] * and/or request plugins be made thread-safe. * [WARNING] * If reporting an issue, report it against the plugin in* [WARNING] * question, not against maven-core * [WARNING] * [WARNING] The following plugins are not marked @threadSafe in LanguageTool Style and Grammar Checker Core: [WARNING] org.apache.maven.plugins:maven-resources-plugin:2.3 [WARNING] * [WARNING] * [WARNING] * Your build is requesting parallel execution, but project * [WARNING] * contains the following plugin(s) that are not marked as * [WARNING] * @threadSafe to support parallel building. * [WARNING] * While this /may/ work fine, please look for plugin updates* [WARNING] * and/or request plugins be made thread-safe. * [WARNING] * If reporting an issue, report it against the plugin in* [WARNING] * question, not against maven-core * [WARNING] * [WARNING] The following plugins are not marked @threadSafe in Hunspell native libs: [WARNING] org.apache.maven.plugins:maven-resources-plugin:2.3 ...snip... Maybe I've been spoiled with GNU make, where parallel builds generally work and builds do the least amount of work possible. Maven builds seem quite slow. Regards Dominique -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: switching to Maven - done!
Am 09.02.2013 um 01:50 schrieb Dominique Pellé dominique.pe...@gmail.com: Richard Eckart de Castilho wrote: Without having had a look at the build, I would expect at least two things to cause: 1) Maven (like ant) is a Java application and it takes a moment to fire up the JVM. make is a native application. 2) The package goal always runs the full packaging (building of ZIPs and JARs from the compiled sources). So even if the compile is up-to-date, doing the packaging takes a moment. If further plugins, e.g. JavaDoc, have been activated during normal builds, they may further slow down the build. Understood for the overhead of running the JVM (multiple times?) during the build. As far as I know, the JVM is started once for the main build and may be started again for running tests, so that tests are well isolated in their own JVM. Depending on the configuration of the surefire plugin, the JVM may be started more than once (see forkMode parameter). But why would Maven mvn package always re-create the ZIPs and JARs when nothing has changed? There might be a good reason, but at first sight it seems like a waste of time. Shouldn't a build system try to do the least amount of work and rebuild only the targets for which at least one of their dependencies has changed, based on a DAG (Directed Acyclic Graph) of target/dependencies? For Java classes, the tool knows the dependencies between files and can avoid to recompile files. As far as I know, for artifacts, Maven does not know or maintain a record of what files go into the artifacts. It may also be that zip/jar archives are not necessarily the best file format for incremental updates and need to be rewritten from scratch every time they are changed. Running mvn compile when nothing has changed is faster than mvn package but not really fast either. mvn compile takes 6.5 sec on my laptop when nothing has changed (nothing to compile), which is presumably much more than what the JVM needs to initialize when launching mvn. I'm probably also spoilt by Eclipse's incremental compile and by Jenkins. In both cases, I do run into these problems. In cases where I do run Maven on the command line, I probably got used to the build times. Anyway, firing up the JVM is likely much less than 6.5s, but then the application is not initialized. I am pretty sure that Maven performs some heavy self-configuration during startup, checking that its modules are available, wiring them all together internally and so on. Maven itself is build in a highly modular way. I would expect this initialization is taking a major part of the startup time. I was also searching for parallel builds in the hope of speeding up (something like make -j4 with GNU make). I found this... http://stackoverflow.com/questions/581465/maven-how-to-do-parallel-builds ... but it does not work. I never was successful with that, but I had tried it on a way more complex build. You might want to update to the version 2.6 of the resources plugin and see if that supports parallel builds. Cheers, -- Richard -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
