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

[Daniel J S. <dan...@ie...>]

On 02/08/2014 04:40 PM, Mojca Miklavec wrote:
> On Sat, Feb 8, 2014 at 7:28 PM, sfeam wrote:
>>
>> I think you have that backwards.
>> As I understand it, OSX does not like running the graphics display
>> loop in a separate thread but is OK with running it in a separate process.
>> So fork=good, separate thread=bad.
>
> Or maybe Qt on OS X simply has problems with both.
>
>> Mojca: - Do you have GNUPLOT_DRIVER_DIR set to the current
>> build directory?
>
> I didn't set that variable anywhere. But I use
>      ./configure --prefix=$PWD/inst
>      make&&  make install
>      ./inst/bin/gnuplot
>
>> I could imagine that if the new executable forks
>> a copy of an old gnuplot_qt that strange things might happen.
>
> The version of gnuplot_qt that is running is the proper one (unless
> "make install" doesn't work properly).
>
>> If you run with the following trivial patch, does the reported
>> process ID make sense?
>
> Yes, it does:
>
> Terminal type set to 'qt'
> gnuplot>  plot sin(x)
> started detached process  "qtgnuplot18712"
> Could not connect gnuplot_qt "" . Starting a new one
> started detached process  "qtgnuplot18714"
>
> The two running gnuplot_qt processes have exactly the right PID (and
> one of them is sometimes reporting 32 EB of shared memory ;), but it
> doesn't seem to work.

Well, it's encouraging that the processes for the two created qt_gnuplot 
instance exist in the OS space.  That's further along than you were 
having with the old version of the code where OSX aborted the process.

Now it seems that gnuplot isn't keeping track of the ID in the proper 
way to access the child process it is creating.  That is,

> Could not connect gnuplot_qt "" . Starting a new one

I'm assuming there should be something meaningful within those double 
quotes.  The problem lies in qt_connectToServer() or the call to 
qt_connectToServer().

Looking at the code, it seems that the printout above might be in error. 
  I see the following:

		if (connectToWidget)
		{
			qDebug() << "Could not connect to widget" << qt_option->Widget << ". 
Starting a QtGnuplotApplication";
			qt_option->Widget = QString();
			qt_connectToServer(qt->localServerName);
		}
		// The gnuplot_qt program could not be reached: try to start a new one
		else
		{
			qDebug() << "Could not connect gnuplot_qt" << qt_option->Widget << ". 
Starting a new one";
			execGnuplotQt();
			qt_connectToServer(qt->localServerName, false);
		}

Doesn't that seem like the second case (else) shouldn't be using 
qt_option-<Widget but the localServerName string in your case?  (Since 
you didn't specify to use an existing Widget.)  So, I'm guessing that 
the qt_option->Widget is a null string hence:

> Could not connect gnuplot_qt "" . Starting a new one

has an empty string when it should be reporting

> Could not connect gnuplot_qt "qtgnuplot18712" . Starting a new one

The second part of this is that I don't think "qtgnuplot18712" has any 
meaning to the OS.  The OS will probably understand "18712".  I'll defer 
to you and Ethan on that one.

Dan