Re: Reworked qt terminal is much faster – and fails to work on Mac

[Mojca M. <moj...@gm...>]

On Sun, Feb 9, 2014 at 1:19 AM, sfeam wrote:
> On Sunday, 09 February 2014 01:01:20 AM Mojca Miklavec wrote:
>> > Another possible test:
>> > Change the timeout value on line 259 from
>> >                qt->socket.waitForConnected(200);
>> > to
>> >                qt->socket.waitForConnected(-1);
>> >
>> > This could potentially cause gnuplot to hang, but it also might work
>>
>> Gnuplot runs at 99% CPU with or without that change (just gnuplot,
>> gnuplot_qt doesn't consume any CPU at all after the first few
>> seconds).
>
> gnuplot is spinning CPU cycles while waiting for a timeout?
> The OSX implementation must really suck.
> Anyhow if you can see the gnuplot_qt process but the waitForConnected
> fails to return that's probably a huge clue to what's gone wrong.
> Let me think about this for a while.
>
> I'm cc-ing Jérôme Lodewyck.  Maybe he can decipher the clue.

I don't know if that's a clue or not, but if I run gdb and manually
press "n", only a single gnuplot_qt is started and gnuplot actually
returns to the console (if I simply run gnuplot, it runs at 99% CPU
"forever"). The first "plot sin(x)" doesn't show anything, but when I
plot something for the second time, the plot is actually shown.

So maybe there's just a problem of wrong
timing/synchronisation/initialisation somewhere after all.

The fact is that if I actually get to this point (by manually stepping
inside gdb), it works a lot better than it did with forking:
- printing doesn't crash
- there is no need for the dirty hack removeDockIcon()
  TransformProcessType(&psn, kProcessTransformToBackgroundApplication);
  to hide the nofunctional window

Mojca