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

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

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.

> --- gnuplot/src/qtterminal/qt_term.cpp  2014-01-26 13:57:10.687171903 -0800
> +++ gnuplot-cvs/src/qtterminal/qt_term.cpp      2014-02-08 10:25:19.819905362 -0800
> @@ -211,9 +211,10 @@ void execGnuplotQt()
>
>         qint64 pid;
>         qt->gnuplot_qtStarted = QProcess::startDetached(filename, QStringList(), QString(), &pid);
> -       if (qt->gnuplot_qtStarted)
> +       if (qt->gnuplot_qtStarted) {
>                 qt->localServerName = "qtgnuplot" + QString::number(pid);
> -       else
> +               qDebug() << "started detached process " << qt->localServerName;
> +       } else
>                 qDebug() << "Could not start gnuplot_qt with path" << filename;
>  }

Mojca