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

[sfeam <sf...@us...>]

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.

	Ethan

> On Saturday, 08 February 2014 03:01:09 AM Mojca Miklavec wrote:
> > On Fri, Feb 7, 2014 at 10:03 PM, Thomas Bleher wrote:
> > > - Does it work if you start gnuplot_qt manually? The qt terminal can
> > > 
> > >   connect to already running programs. To do this:
> > >   - start gnuplot_qt
> > >   - determine its pid
> > >   - start gnuplot
> > >   - call 'set terminal qt widget "qtgnuplot<pid>"', where <pid> is
> > >   
> > >     replaced by the numerical pid of the gnuplot_qt process
> > >   
> > >   - Try to plot something, e.g. "plot x"
> > 
> > Yes, that works.
> > 
> > Mojca
> 
> That's kind of unexpected.
> In that case it seems that all you need to do is figure out what
> differs in those two initialization paths, and the fix should be evident.
> Could it be as simple as timing?
> Maybe just wait 1 second before leaving  execGnuplotQt().
> If that works we can worry about changing it to a proper test that
> the newly created process is now running.
> 
>         Ethan