The graphical listener is simply not meant to be used like this. You
can see that the command line listener (or a factor script, or a
deployed program) has no problem outputting million of lines with
./factor -run=listener
Jon
On Fri, Oct 9, 2015 at 5:34 PM, Alexander Ilin
Are you running 32-bit factor on 32-bit or 64-bit windows?
On Fri, Oct 9, 2015 at 9:52 AM, Alexander Ilin wrote:
> Hello, Jon!
>
> 09.10.2015, 19:17, "Jon Harper" :
> > The graphical listener is simply not meant to be used like this.
>
> I see your
Hello, Jon!
09.10.2015, 19:17, "Jon Harper" :
> The graphical listener is simply not meant to be used like this.
I see your point, but I thougt it wasn't meant to crash either.
---=---
Александр
So this works find on Mac OS X.
On Windows, the crash is due to an out-of-memory exception.
Perhaps we can improve the memory characteristics of printing text to the
UI listener.
On Fri, Oct 9, 2015 at 11:16 AM, Alexander Ilin wrote:
> Hello!
>
> 09.10.2015, 20:18, "John
Hello!
09.10.2015, 20:18, "John Benediktsson" :
> Are you running 32-bit factor on 32-bit or 64-bit windows?
32-bit Factor on 32-bit Windows XP Pro SP 3.
---=---
Александр
--
Hello!
Is it just me, or do you also can see this issue?
I downloaded the latest development build for Windows:
factor-windows-x86-32-2015-09-29-16-12.zip
It reports this on startup: Factor 0.98 x86.32 (1717,
heads/master-9a5cd7d13d, Tue Sep 29 16:12:54 2015)
[Microsoft Visual C++