It has been running for some hours now; no dump yet.
Ruud
> On 2014-05-28 07:28, R.J. Baars wrote:
>
>> Unfortunately, the dump is still there in the nightly build of
>> yesterday:
>
> Are you sure you're using the latest build? The line numbers look like
> Marcin's fix is not included. I have ad
That is great. I will add tonights build tomorrow.
Verzonden van smartphone.
Daniel Naber schreef:
On 2014-05-28 07:28, R.J. Baars wrote:
> Unfortunately, the dump is still there in the nightly build of
> yesterday:
Are you sure you're using the latest build? The line numbers look like
Mar
On 2014-05-28 07:28, R.J. Baars wrote:
> Unfortunately, the dump is still there in the nightly build of
> yesterday:
Are you sure you're using the latest build? The line numbers look like
Marcin's fix is not included. I have added another change to today's
build so it will print the sentence t
By the way, it would be helpfull if in the dump there was some info of the
input ... I dont knwo if that is possible, but it would surely help.
Ruud
> W dniu 2014-05-27 12:42, Daniel Naber pisze:
>> On 2014-05-27 11:06, Marcin MiÅkowski wrote:
>>
>>> maybe it was because of a simple mistake in
Unfortunately, the dump is still there in the nightly build of yesterday:
I will try to find examples making it dump, though they are rare.
Ruud
Exception in thread "main" java.lang.RuntimeException:
java.util.concurrent.ExecutionException:
java.lang.StringIndexOutOfBoundsException: String inde
W dniu 2014-05-27 12:42, Daniel Naber pisze:
> On 2014-05-27 11:06, Marcin Miłkowski wrote:
>
>> maybe it was because of a simple mistake in the isNumberOrDot() method.
>> I fixed it,
>
> Are you sure you have pushed it? I cannot see it in the list of changes.
Apparently, something weird happened
On 2014-05-27 11:06, Marcin Miłkowski wrote:
> maybe it was because of a simple mistake in the isNumberOrDot() method.
> I fixed it,
Are you sure you have pushed it? I cannot see it in the list of changes.
Regards
Daniel
---
I did so. Will have to wait some time until the process will skip to
another input file, but I will keep you informed.
Ruud
op 27-05-14 11:06, Marcin Miłkowski schreef:
> Hi,
>
> maybe it was because of a simple mistake in the isNumberOrDot() method.
> I fixed it, so the today's build should run
Hi,
maybe it was because of a simple mistake in the isNumberOrDot() method.
I fixed it, so the today's build should run fine. Could you download the
nightly and see whether you get crashes on your data?
Best,
Marcin
W dniu 2014-05-27 09:20, R.J. Baars pisze:
> Hi.
>
> I am currently using lang
The long process is running again, with last nights snapshot.
I will report whether it dumps or, completes correctly. That will take a
few days.
Ruud
--
October Webinars: Code for Performance
Free Intel webinars can hel
No need for excuses. imho this is already quite stable. I will download a
snapshot and start again.
I am glad to have helped getting rid of a bug.
Ruud
> The BaseSynthesizer is now thread-safe. The PolishSynthesizer had the
> same bug and has been fixed, too.
>
> @Ruud:
> Sorry for the inconveni
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 wrote:
> On 2013-10-02 12:00, Stefan Lotties wrote:
>
>> I'll check some more code then. It
On 2013-10-02 12:00, Stefan Lotties wrote:
> I'll check some more code then. It's already the second part that
> still isn't thread-safe and there might be more.
Okay. I will not work on the release for Maven Central until this is
fixed (the Maven/Nexus problem is still not resolved, maybe I'll
Right. It crashed again with the big batch.
Some solution would be nice.
Ruud
On 02-10-13 12:00, Stefan Lotties wrote:
> On Wed, Oct 2, 2013 at 11:34 AM, Daniel Naber wrote:
>> On 2013-10-02 11:14, Stefan Lotties wrote:
>>
>>> Sounds right. The fix should look very similar to the one in
>>> Bas
On Wed, Oct 2, 2013 at 11:34 AM, Daniel Naber 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 this becomes,
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 this becomes, just protecting the calls
with 'synchronized' would also be f
> 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
> -BaseSynthesiz
On 2013-10-01 21:18, Dominique Pellé wrote:
> Hopefully it's fixed indeed... or it's a rare multi-threading bug
> and those are painful bugs to debug and reproduce.
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 p
I just restarted the same corpus check routine using the release version
wiht the changes disambiguation file.
We'll see.
About compilers, debuggers, that is too complex for me. I can do simple
scripts, but tend to hire people to get things like that done.
Ruud
On 01-10-13 21:18, Dominique Pe
Ruud Baars wrote:
> I retrace the steps with 2.3, and the error does not reproduce. It must
> be a snapshot thing.
>
> No matter, case closed.
>
> Ruud
Hopefully it's fixed indeed... or it's a rare multi-threading bug
and those are painful bugs to debug and reproduce. In fact
I just saw another
I retrace the steps with 2.3, and the error does not reproduce. It must
be a snapshot thing.
No matter, case closed.
Ruud
On 01-10-13 15:52, R.J. Baars wrote:
> No, that is all I changed, but with a (recent) snapshot.
>
> I will check tonight with the new release.
> - without the altered disam
No, that is all I changed, but with a (recent) snapshot.
I will check tonight with the new release.
- without the altered disambig
- with it
It could be platform, But I am not the only one on (K)ubuntu, using JDK.
Ruud
> On 2013-09-30 18:17, Ruud Baars wrote:
>
>> For reproducing exactly: remov
On 2013-09-30 18:17, Ruud Baars wrote:
> For reproducing exactly: remove the line feeds from the sentence. They
> were introduced by the e-mail.
That and using your disambiguation file didn't help, I still cannot
reproduce the problem. Does it also happen with the 2.3 release? Did you
change so
Yes, it is a snapshot of a few days ago, with edited disambiguation.
Tests run perfectly.
I can send the changed disambiguation, maybe it is in that.
But tonight, I am in the train right now and then at work, without
connections. Security...
Ruud
> On 2013-09-29 22:32, Ruud Baars wrote:
>
>> D
On 2013-09-29 22:32, Ruud Baars wrote:
> Daniel, others, it is the paragraph below that makes LT crash (command
> line as well as GUI) when checking in Dutch.
Thanks for taking the time to find the sentence. However, like
Dominique, I cannot reproduce the crash. Does it crash every time for
yo
On Sun, Sep 29, 2013 at 10:32 PM, Ruud Baars wrote:
> Daniel, others, it is the paragraph below that makes LT crash (command
> line as well as GUI) when checking in Dutch.
>
> (The sentence is not perfect, but a crash should not be expected).
>
> Ruud
>
> De Duitse herder is onderworpen aan een z
Daniel, others, it is the paragraph below that makes LT crash (command
line as well as GUI) when checking in Dutch.
(The sentence is not perfect, but a crash should not be expected).
Ruud
De Duitse herder is onderworpen aan een zeer strikt fokprogramma. Enkel
honden die aan bepaalde, door de
I used:
java -jar languagetool-commandline.jar -l nl -b --api -r ok > LTresults.txt
Where ok is the folder containing 62 files of 5.3 GB in total; all lines
containing paragraphs with only words known to be correct.
Right now, the command is running again, but without the directory
recursion, e
I just added a bug for this on Sourceforge.
I was wondering what all those fields the creator is able to set are
doing there, there is no explanation at all.
What is Milestone?
Owner?
Which priority is highest?
Should all these items not be set by the 'moderator' of the bugs list?
Ruud
--
On 2013-09-29 11:02, Ruud Baars wrote:
> But I will have do redo it all (it happend after 14 GB of output ..) ,
> and there is no indication of file it was in, nor a file pointer.
> (Could
> be usefull in the output as fields?)
I'll try to add better debugging output for those errors. How exactl
I might.
But I will have do redo it all (it happend after 14 GB of output ..) ,
and there is no indication of file it was in, nor a file pointer. (Could
be usefull in the output as fields?)
Wasn't there an option to have LT output the full text it worked on in
the API output, instead of the sh
On 2013-09-29 08:33, Ruud Baars wrote:
> After hours of processing paragraphs from the command line, for a large
> set of file, this dump was caused.
Can you somehow drill down what text or paragraph caused this? If not,
can you provide the files you used as input? Also, could you please open
a
32 matches
Mail list logo
