have now. Therefore my biggest interests are to
make LanguageTool faster and slimmer.
Regards,
Stefan
On Wed, Sep 11, 2013 at 2:43 PM, Daniel Naber list2...@danielnaber.de wrote:
I'd like to welcome Stefan Lotties as a new committer. Stefan has
written patches to make core classes of LT thread
+1 for this proposal. It would be good to be able to add new rules and
override existing ones for fixing them on 'user-side' or in projects.
The latter case is a special one and will most likely not be used very
often, but it's still good to be able to do so.
On Fri, Sep 13, 2013 at 8:52 AM,
I like Notepad++, too, as simple text/XML editor. If you use Eclipse
then the Spket plugin is an alternative. It contains a javascript
editor and an XML editor. Both are very responsive (no lags, etc.) and
support basic syntax highlighting (missing end tags, DTD/XSD
validation) and completion
It is... I just had the same problem on English text. Running LT on the
same text again there was no problem. Anyway, I think the problem is
this:
-a MultiThreadedJLanguageTool uses one Language object from multiple
threads
-the Language object has one BaseSynthesizer
-BaseSynthesizer is
On Wed, Oct 2, 2013 at 11:34 AM, Daniel Naber list2...@danielnaber.de wrote:
On 2013-10-02 11:14, Stefan Lotties wrote:
Sounds right. The fix should look very similar to the one in
BaseTagger: cache the Dictionary, but re-create the IStemme whenever
it's needed.
Depending on how complicated
The BaseSynthesizer is now thread-safe. The PolishSynthesizer had the
same bug and has been fixed, too.
@Ruud:
Sorry for the inconvenience. It should work now.
On Wed, Oct 2, 2013 at 5:16 PM, Daniel Naber list2...@danielnaber.de wrote:
On 2013-10-02 12:00, Stefan Lotties wrote:
I'll check
On Sat, Oct 5, 2013 at 9:50 AM, Kumara Bhikkhu kumara.bhik...@gmail.com wrote:
At the same time I also understand the demand for
single language versions. Wanting a lighter
program is one. The other is the perception that
If it's meant for dozens of languages, it
probably doesn't do one well.
LO/OO provides dictionaries when installing it. Can't we use them
instead of our own hunspell dictionaries? Languages such as german
stiff have a huge grammar.xml beside the dictionary, but leaving out
the dictionaries is already a huge win: the ZIP has a size of ~24 MB
instead of ~44 MB.
IMHO _final_ should never be used on local variables unless you need
them, e.g. because you pass the variable to an anonymous class aka
closure aka lambda expression. Simply because it pollutes the code for
an optimization that's AFAIK also done by the HotSpot. On parameters
it's a matter of
If it works, then I do nothing, but if it doesn't succeed, then I kill
the process (if it's still there) and I restart it again.
That wasn't enough for me, as sometimes the server had a high load but
still replied to some requests or so, so I'm using a script that checks
the load the process
, Stefan Lotties wrote:
Oh, I didn't know where using the JDK-based server. Did you ever think
about switching to netty or some other lightweight HTTP server?
Yes, I think I even started porting the code to Jetty but I didn't
finish. As it mostly works now, the pressure just wasn't high enough
Actually I did change all those code to the double-locking technique
because the IStemmer is not thread-safe. And I was pretty sure that
there's no problem with the double-locking technique. Damn it! Well,
now I know better. Thanks for hint.
The idea behind using the double-locking was just to
12 matches
Mail list logo
