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

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

On Sat, Feb 8, 2014 at 11:59 PM, Daniel J Sebald wrote:
> On 02/08/2014 04:40 PM, Mojca Miklavec wrote:
>> On Sat, Feb 8, 2014 at 7:28 PM, sfeam wrote:
>>>
>>> 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.

Can you please explain what you meant with this? What exactly is mean
with "the old version"? (Which version is the old version here?) And
what kind of aborting are you talking about?

> 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?

If I change that to
   qDebug() << "Could not connect gnuplot_qt" << qt->localServerName
<< ". Starting a new one";
I indeed get

gnuplot> plot sin(x)
started detached process  "qtgnuplot20164"
Could not connect gnuplot_qt "qtgnuplot20164" . Starting a new one
started detached process  "qtgnuplot20166"

so your observation makes sense. (But of course it doesn't affect
functionality.)

> 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.

Please note that GDB says

261  while((qt->socket.state() != QLocalSocket::ConnectedState) &&
(QDateTime::currentDateTime() < timeout));
(gdb) p qt->socket.state()
$19 = QLocalSocket::ConnectedState

So it probably does connect somehow.

Mojca

PS: It would be really nice if someone with sufficient knowledge of Qt
would create a tiny app where gnuplot would already start as a Qt
application similar to Terminal and simply open Qt windows from there
(no need for support for wxWidgets or X11 in that mode). Something
very similar to what wgnuplot.exe does on Windows. Yes, that would be
another mode of operation, but it would be a very useful one and would
make distribution of binaries for Mac a lot easier for example.