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

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

On 02/08/2014 05:26 PM, Mojca Miklavec wrote:
> 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?

The posts from a day or two ago were referring to the gnuplot version 
before QProcess::startDetached was introduced, and now we are referring 
to the gnuplot version after QProcess::startDetached was introduced. 
 From what I've seen elsewhere, the older (pre startDetached) used to 
launch the Qt child process and then get a complaint like the following 
from OSX:

__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___



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

Chipping away at things then...


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

OK, hard for me to tell what is happening without a bit of trial-and-error.

Dan