gnuplot-beta — Developers and beta testers of new gnuplot code

screendump and Qt - Re: Getting ready to put out a 4.6 release candidate

[Petr M. <mi...@ph...>]

> I really like the fact that it has "export to PDF", "Print" functionality 
> and auto-resize the plot, none of which is present in wxt.

I like it too. It remembers me that gnuplot on MSW has command "screendump" 
which invokes the print dialog. What about making this command working also 
for Qt?

---
Petr

Re: $HOME in loadpath - Re: Getting ready to put out a 4.6 release candidate

[Petr M. <mi...@ph...>]

> > "/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
> > during intialization

A typo: intialization => initialization

> > WARNING: Error during initialization
> > 
> > I think it would be better to avoid $HOME/.gnuplot completely during "make", 
> > but allow anything during ordinary gnuplot use.
> 
> Issue 1:
> 
> I would go even further, and say that it should not be necessary to 
> run gnuplot in order to "make" gnuplot.
> 
> The failure you see comes specifically from doing a "make" in the 
> PostScript tutorial subdirectory.  I agree that this shouldn't be part of
> the default set of "make" targets, but it has been since forever.
> To avoid rebuilding the tutorial on every make, you have to do  
> "./configure --without-tutorial". I have that in my default build script.  
> But then you can't build it later on even if you want to, so yes, 
> it is a bug in the build system.
> 
> I think the tutorial should just be an optional make target, similar to
> the various optional targets in the ../docs or ../demo directories.  
> Then it would not require a special option in ./configure.  
> It would not be recreated by "make", only by "make tutorial".  

Unfortunately INSTALL does not list the possible targets; I think it would 
be useful to list them (pdf, tutorial, pdffigures(?), ...).


> Issue 2:
> > set loadpath "`echo $HOME`/foo"
> > 
> > I don't know any other way how to get the home dir there (except for 
> > GNUPLOT_LIB via shell's rc script); the "~" is not expanded.
> 
> By coincidence, I ran into the same issue myself just a couple of
> days ago.  So I fixed it.   As of yesterday, both "set loadpath"
> and "set fontpath"  call gp_expand_tilde().   I don't know why they have
> not always done so - perhaps it was just an oversight.

I have that   set loadpath "`echo $HOME`/foo"  for ages and never realized 
I could ask for "~" expansion :-(



> Issue 3 (this is the major one):
> > I have the following line in my $HOME/.gnuplot:
> > set loadpath "`echo $HOME`/usr/lib/gnuplot"
> 
> In preparation for 4.6, last month I looked through all the configure options.
> I was appalled to discover that the option
>    --with-cwdrc    check current directory for .gnuplot file,
>                    normally disabled for security reasons

> So at the same time I fixed the configuration option, I disabled running 
> shell commands from the initialization code.

If an intruder can damage your $HOME/.gnuplot file, then it can do much 
worse things. So I would allow shell commands.


> It is true that the "time bomb" scenario is less of a concern for the
> initialization file in your home directory than it is for files in other,
> shared, directories.  So it would be possible to make a distinction between
> what is allowed in ~/.gnuplot and what is allowed in $CWD/.gnuplot or
> $GNUPLOT_SHARE_DIR/gnuplotrc etc.  The particular example you showed can
> be fixed without this (and has been); can you think of other legitimate
> reasons to invoke a shell command from ~/.gnuplot?

I have used several times $CWD/.gnuplot which set some commands or hotkeys 
and then loaded $HOME/.gnuplot. But you can achieve the same by
	gnuplot .gnuplot -
and thus the $CWD/.gnuplot feature is not necessary. 


---
Petr

Re: Getting ready to put out a 4.6 release candidate

[Tatsuro M. <tma...@ya...>]

Hello

--- On Fri, 2012/1/6, Bastian Märkisch  wrote:

> Please note that it is possible to include extra files in the binary 
> distribution by specifying an EXTRADIST directory in Makefile.

Oops! I have overlooked. Thank you for your pointing.

Regards

Tatsuro 

Re: Qt rcc absolute path - Re: Getting ready to put out a 4.6 release candidate

[Ethan M. <merritt@u.washington.edu>]

On Friday, January 06, 2012 11:09:49 am Mojca Miklavec wrote:

> Btw: Jérôme now fixed the source to the extent that I can work with Qt
> terminal (it is usable for testing, but the remaining problems are not
> acceptable for a release). Thanks to the fix I don't have to manually
> patch Makefiles any more.

So he replied to you directly?  What is the nature of the fix?   
It will be more useful if any changes are kept in sync with the CVS
version. 

Do you think that it's realistic after all to say that we should aim for 
a working OSX+qt in version 4.6?

> I like the terminal and have some more feature requests and bug
> reports (or maybe patches for the trivial issues), but I will wait
> until it starts working properly. I really like the fact that it has
> "export to PDF", "Print" functionality and auto-resize the plot, none
> of which is present in wxt.

The PDF output is not bad, but the SVG output is definitely not as
useful as the output directly from the svg terminal.  No object
grouping, no attributes, no interactive mousing, etc.

But yeah, I like it too.  I switched to using qt by default just
so I could identify and fix any weak points.  The main problem I see
is that supposedly the performance is much better in "opengl" mode,
but I have not figured out how to enable that mode.  I have a package
libqtopengl4 installed, but this is apparently not sufficient.

I don't quite follow what your problem is with auto-resize.  
The wxt terminal does almost exactly the same thing except it doesn't 
have a toggle button in the tool widget.  [As it happens, I like the wxt 
behavior better, since sometimes I want a pure expansion and for the 
times I don't the a replot is only one mouse click away. 
But this is clearly a matter of opinion.]

	cheers,

		Ethan

> 
> Mojca


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: Qt rcc absolute path - Re: Getting ready to put out a 4.6 release candidate

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

On Fri, Jan 6, 2012 at 19:34, Ethan Merritt wrote:
> On Friday, January 06, 2012 07:11:35 am Petr Mikulik wrote:
>
>> Is this a bug in pkg-config? Here is what I get with pkg-config:
>>
>> $ pkg-config --variable=rcc_location QtCore
>> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
>>
>> $ pkg-config --variable=uic_location QtCore
>> /usr/bin/uic
>
> Sure looks like a pkg-config error to me.

To me it looks as if ./configure was set to install Qt to
/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1 and then
the installer has simply copied the files to /usr/bin etc., without
fixing *.pc along the way. But maybe I'm completely wrong. This was
just a hypothesis/speculation.

> The reason I was adjusting the configure.in script section for Qt was
> that Mojca and I also ran into pkg-config bugs.

(For me it wasn't just a pkg-config bug as I don't have pkg-config for
Qt at all.)

But thank you very much for fixing the MOC and UIC paths.

Btw: Jérôme now fixed the source to the extent that I can work with Qt
terminal (it is usable for testing, but the remaining problems are not
acceptable for a release). Thanks to the fix I don't have to manually
patch Makefiles any more.

I like the terminal and have some more feature requests and bug
reports (or maybe patches for the trivial issues), but I will wait
until it starts working properly. I really like the fact that it has
"export to PDF", "Print" functionality and auto-resize the plot, none
of which is present in wxt.

Mojca

Re: Qt rcc absolute path - Re: Getting ready to put out a 4.6 release candidate

[Ethan M. <merritt@u.washington.edu>]

On Friday, January 06, 2012 07:11:35 am Petr Mikulik wrote:
> During make, I see:
> 
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc: Command 
> not found
> make[3]: *** [qrc_QtGnuplotResource.cpp] Error 127
> 
> and similarly for lrelease. 
> 
> Directory
>         /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1
> does not exist; rcc and lrelease are directly in /usr/bin/.
> 
> 
> Is this a bug in pkg-config? Here is what I get with pkg-config:
> 
> $ pkg-config --variable=rcc_location QtCore
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
> 
> $ pkg-config --variable=uic_location QtCore
> /usr/bin/uic

Sure looks like a pkg-config error to me.
What does it produce if you type:
  pkg-config --variable=moc_location QtCore


The reason I was adjusting the configure.in script section for Qt was
that Mojca and I also ran into pkg-config bugs.  The *.pc files shipped
with qt 4.6.3 (Mandriva 2010) fail to define rcc or lrelease at all;
instead they shipped a file /etc/profile.d/60qt4.sh that explicitly
adds a directory to $PATH.   But in qt 4.7.0 (Mandriva 2011) they
switched back to defining these in QtCore.pc just as they always had
for moc and uic:
  moc_location=/usr/lib/qt4/bin/moc
  uic_location=/usr/lib/qt4/bin/uic
  rcc_location=/usr/lib/qt4/bin/rcc
  lupdate_location=/usr/lib/qt4/bin/lupdate
  lrelease_location=/usr/lib/qt4/bin/lrelease

> Among others, the following libraries are installed:
> libqt4-devel-4.7.1-154.1
> qt3-devel-3.3.8b-87.11
> qt3-3.3.8b-87.11
> 
> It's on OpenSUSE 11.1 with KDE3.

Hmm.  I can see that there would be some trickiness required if the
same QtCore.pc file is supposed to handle parallel simultaneous 
installations of qt3 and qt4.  But yours seems to describe only qt4,
though it gets those two definitions wrong.  The gnuplot configure
script could test first for "rcc" and "lrelease" being in the current
path (that might handle Mojca's problem case also).  But again you
might run into interesting problems if you have both the qt3 and qt4
devel packages installed.

Anyhow, these are exactly the sort of platform-specific build problems
that the -rc1 is intended to shake out.  So I guess the plan is 
working even though -rc1 isn't yet announced :-)

	Ethan


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: $HOME in loadpath - Re: Getting ready to put out a 4.6 release candidate

[Ethan A M. <sf...@us...>]

Petr Mikulik <mi...@ph...> wrote 
>
>

I see three separate issues here.
I will re-arrange your post to answer them.


> I see the following problem which leads to failure of "make":
> 
> make[2]: Entering directory 
> `/home/mikulik/work/Software/gnuplot/gnuplot/tutorial'
> if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript 
> GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg1.plt ; else gnuplot eg1.plt ; 
> fi
> if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript 
> GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg2.plt ; else gnuplot eg2.plt ; 
> fi
> "/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
> during intialization
> 
> WARNING: Error during initialization
> 
> I think it would be better to avoid $HOME/.gnuplot completely during "make", 
> but allow anything during ordinary gnuplot use.

Issue 1:

I would go even further, and say that it should not be necessary to 
run gnuplot in order to "make" gnuplot.

The failure you see comes specifically from doing a "make" in the 
PostScript tutorial subdirectory.  I agree that this shouldn't be part of
the default set of "make" targets, but it has been since forever.
To avoid rebuilding the tutorial on every make, you have to do  
"./configure --without-tutorial". I have that in my default build script.  
But then you can't build it later on even if you want to, so yes, 
it is a bug in the build system.

I think the tutorial should just be an optional make target, similar to
the various optional targets in the ../docs or ../demo directories.  
Then it would not require a special option in ./configure.  
It would not be recreated by "make", only by "make tutorial".  


Issue 2:
> set loadpath "`echo $HOME`/foo"
> 
> I don't know any other way how to get the home dir there (except for 
> GNUPLOT_LIB via shell's rc script); the "~" is not expanded.

By coincidence, I ran into the same issue myself just a couple of
days ago.  So I fixed it.   As of yesterday, both "set loadpath"
and "set fontpath"  call gp_expand_tilde().   I don't know why they have
not always done so - perhaps it was just an oversight.



Issue 3 (this is the major one):
> 
> Even worse, it fails even during gnuplot start-up:
> 
> $ ./gnuplot
> 
>         G N U P L O T
>         Version 4.5 patchlevel 0    last modified 2012-01-05 
>         Build System: Linux i686
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2011
>         Thomas Williams, Colin Kelley and many others
> 
>         gnuplot home:     http://www.gnuplot.info
>         mailing list:     gnu...@li...
>         faq, bugs, etc:   type "help FAQ"
>         immediate help:   type "help"  (plot window: hit 'h')
> "/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
> during intialization
> 
> WARNING: Error during initialization
> 
> I have the following line in my $HOME/.gnuplot:
> set loadpath "`echo $HOME`/usr/lib/gnuplot"
> 
> This seems to be a consequence of
> 2011-12-28  Ethan A Merritt  
>   Do not allow execution of system(), shell, or popen() commands in 
>   the initialization files.
> 
> What's the reason for this change?

In preparation for 4.6, last month I looked through all the configure options.
I was appalled to discover that the option
   --with-cwdrc    check current directory for .gnuplot file,
                   normally disabled for security reasons
did not work, and never did work.  No matter how you set that option, the
program has always looked for an initialization file ./.gnuplot
As the configuration comment states, this is very bad security practice.
It invites "time bombs" left by a malicious user in the expectation that
someday someone will run a program (in this case gnuplot) while their current
directory is set to somewhere, perhaps /tmp, containing the time bomb.
The damage that could be done by such a bomb is of course much worse if the
initialization file can trigger arbitrary shell commands.  So at the same time
I fixed the configuration option, I disabled running shell commands from the
initialization code.

It is true that the "time bomb" scenario is less of a concern for the
initialization file in your home directory than it is for files in other,
shared, directories.  So it would be possible to make a distinction between
what is allowed in ~/.gnuplot and what is allowed in $CWD/.gnuplot or
$GNUPLOT_SHARE_DIR/gnuplotrc etc.  The particular example you showed can
be fixed without this (and has been); can you think of other legitimate
reasons to invoke a shell command from ~/.gnuplot?

	Ethan

Qt rcc absolute path - Re: Getting ready to put out a 4.6 release candidate

[Petr M. <mi...@ph...>]

During make, I see:

/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc: Command 
not found
make[3]: *** [qrc_QtGnuplotResource.cpp] Error 127

and similarly for lrelease. 

Directory
	/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1
does not exist; rcc and lrelease are directly in /usr/bin/.


Is this a bug in pkg-config? Here is what I get with pkg-config:

$ pkg-config --variable=rcc_location QtCore
/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc

$ pkg-config --variable=uic_location QtCore
/usr/bin/uic


Among others, the following libraries are installed:
libqt4-devel-4.7.1-154.1
qt3-devel-3.3.8b-87.11
qt3-3.3.8b-87.11

It's on OpenSUSE 11.1 with KDE3.

---
Petr

$HOME in loadpath - Re: Getting ready to put out a 4.6 release candidate

[Petr M. <mi...@ph...>]

I see the following problem which leads to failure of "make":

make[2]: Entering directory 
`/home/mikulik/work/Software/gnuplot/gnuplot/tutorial'
if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript 
GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg1.plt ; else gnuplot eg1.plt ; 
fi
if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript 
GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg2.plt ; else gnuplot eg2.plt ; 
fi
"/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
during intialization

WARNING: Error during initialization

make[2]: *** [eg2.tex] Error 1
make[2]: *** Waiting for unfinished jobs....
"/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
during intialization

WARNING: Error during initialization


Even worse, it fails even during gnuplot start-up:

$ ./gnuplot

        G N U P L O T
        Version 4.5 patchlevel 0    last modified 2012-01-05 
        Build System: Linux i686

        Copyright (C) 1986-1993, 1998, 2004, 2007-2011
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        mailing list:     gnu...@li...
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')
"/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
during intialization

WARNING: Error during initialization


I have the following line in my $HOME/.gnuplot:
set loadpath "`echo $HOME`/usr/lib/gnuplot"

I don't know any other way how to get the home dir there (except for 
GNUPLOT_LIB via shell's rc script); the "~" is not expanded.

This seems to be a consequence of
2011-12-28  Ethan A Merritt  
  Do not allow execution of system(), shell, or popen() commands in 
  the initialization files.

What's the reason for this change?

I think it would be better to avoid $HOME/.gnuplot completely during "make", 
but allow anything during ordinary gnuplot use.

---
Petr

Re: Getting ready to put out a 4.6 release candidate

[Bastian M. <bma...@we...>]

Apologies for the late reply - I am quite busy right now. I will update 
config/mingw/Makefile and the installer accordingly. The patch mentioned 
below should cleanly apply to the 4.6 branch as well. This will make 
sure that files are included in the source tarball as well.

Please note that it is possible to include extra files in the binary 
distribution by specifying an EXTRADIST directory in Makefile.

In my opinion we shouldn't drop the zip distribution. gnuplot is a very 
nice "portable" application to carry around on an USB stick.

One thing I would like to be updated before an actual 4.6 release are 
the Windows menus wgnuplot.mnu, which are a bit out of snyc with 
gnuplot's current abilites.

Bastian


Am 06.01.2012 09:12, schrieb Tatsuro MATSUOKA:
> Hello
>
> --- On Fri, 2012/1/6, sfeam (Ethan Merritt) wrote:
>
>> The reason for putting out a "release candidate" 4.6.rc1 before putting
>> out 4.6.0 is so that there is time to collect reports of problems.
>> In particular I hope we find out if there are problems with configuration
>> or installation. That way we can hope to have fixed all the errors in 4.6.0.
>> Well, we can hope :-)
>>
>> Therefore I think the release candidate is a very good time to introduce
>> a new installation method.  If there are problems then we can fix
>> them or revert to the old installation method if necessary.
>>
>> You have said that a change is needed in mingw/Makefile.
>> Are there any other changes needed to support the new installer?
>> Any new files that I need to add to the list of files included
>> in the gnuplot-4.6.rc1.tar.gz?
>
> The below change of cvs (4.5) branch is necessary for installer.
> *******************************************************
> 2011-12-23  Bastian Maerkisch<bma...@we...>
>
> 	Installer for Windows. Japanese translation by Shigeharu Takeno.
>
> 	* win/gnuplot.iss win/modpath.iss: Installer script to be compiled by
> 	Inno Setup. New files.
>
> 	* win/Copyright-ja.txt: Japanese translation of Copyright, includes
> 	original text. Encoding is Shift-JIS.
>
> 	* win/README-Windows.txt win/README-Windows-ja.txt: New files,
> 	displayed by installer before installation. Based on Tatsuro Matsuoka's
> 	README.Windows.gpteam and README.
>
> 	* config/mingw/Makefile: New make target 'installer'. Let make dist
> 	copy TeX files to a standard TeX directory structure (TDS).
> *****************************************************************
>
> I have checked installer several times, it worked very fine.
> However the contents is different from the previous release.
>
> I have posted on Dec. 23, 2011 on beta list.
>
> contents of docs directory in windows binaries:
> http://sourceforge.net/mailarchive/message.php?msg_id=28585157
>
> I at the moment make extra.zip on my web for the windows cvs distribution.
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>
> I think that contents in docs directory should be discussed before release because windows users will seldom see the source of gnuplot.  In my opinion, postscript related documents is required in the binary release as was done previously.
>
> Regards
>
> Tatsuro
>
>
>
>>      Ethan
>>
>>
>>
>>
>>>
>>> Regards
>>>
>>> Tatsuro
>>>>       Ethan
>>>>
>>>

Re: Getting ready to put out a 4.6 release candidate

[Tatsuro M. <tma...@ya...>]

Hello

--- On Fri, 2012/1/6, sfeam (Ethan Merritt) wrote:

> The reason for putting out a "release candidate" 4.6.rc1 before putting 
> out 4.6.0 is so that there is time to collect reports of problems.
> In particular I hope we find out if there are problems with configuration
> or installation. That way we can hope to have fixed all the errors in 4.6.0.
> Well, we can hope :-)
> 
> Therefore I think the release candidate is a very good time to introduce
> a new installation method.  If there are problems then we can fix
> them or revert to the old installation method if necessary.
> 
> You have said that a change is needed in mingw/Makefile.
> Are there any other changes needed to support the new installer?
> Any new files that I need to add to the list of files included
> in the gnuplot-4.6.rc1.tar.gz?

The below change of cvs (4.5) branch is necessary for installer.
*******************************************************
2011-12-23  Bastian Maerkisch  <bma...@we...>

	Installer for Windows. Japanese translation by Shigeharu Takeno.

	* win/gnuplot.iss win/modpath.iss: Installer script to be compiled by
	Inno Setup. New files.

	* win/Copyright-ja.txt: Japanese translation of Copyright, includes
	original text. Encoding is Shift-JIS.

	* win/README-Windows.txt win/README-Windows-ja.txt: New files, 
	displayed by installer before installation. Based on Tatsuro Matsuoka's
	README.Windows.gpteam and README.

	* config/mingw/Makefile: New make target 'installer'. Let make dist
	copy TeX files to a standard TeX directory structure (TDS). 
*****************************************************************

I have checked installer several times, it worked very fine.
However the contents is different from the previous release.

I have posted on Dec. 23, 2011 on beta list.

contents of docs directory in windows binaries:
http://sourceforge.net/mailarchive/message.php?msg_id=28585157

I at the moment make extra.zip on my web for the windows cvs distribution.
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

I think that contents in docs directory should be discussed before release because windows users will seldom see the source of gnuplot.  In my opinion, postscript related documents is required in the binary release as was done previously.

Regards

Tatsuro



>     Ethan
> 
> 
> 
> 
> > 
> > Regards
> > 
> > Tatsuro
> > >     Ethan
> > > 
> > 
> 
> 

Re: Getting ready to put out a 4.6 release candidate

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 04 January 2012, Tatsuro MATSUOKA wrote:
> Hello
> 
> --- On Thu, 2012/1/5, Ethan A Merritt  wrote:
> 
> > Tatsuro MATSUOKA 
> > > Hello
> > > 
> > > In my opinion, the windows binary distribution is better to done in installer style for gnuplot-4.6.
> > > Therefore change for installer is better to be included in the mingw/Makefile for 4.6.
> > > 
> > > Ethan and Bastian
> > > How do you think?
> > 
> > Fine with me.  
> > It just went into 4.5 CVS very recently, right?   
> You are right.
> 
> > Have there been any user reports to indicate how many people have
> > successfully used it?
> There have been no reports binaries in installer style.
> If you do not want hurry about this matter, the distribution of 4.6.0 will be done in zip style and the distribution of 4.6.1 will be changed to installer style.

The reason for putting out a "release candidate" 4.6.rc1 before putting 
out 4.6.0 is so that there is time to collect reports of problems.
In particular I hope we find out if there are problems with configuration
or installation. That way we can hope to have fixed all the errors in 4.6.0.
Well, we can hope :-)

Therefore I think the release candidate is a very good time to introduce
a new installation method.  If there are problems then we can fix
them or revert to the old installation method if necessary.

You have said that a change is needed in mingw/Makefile.
Are there any other changes needed to support the new installer?
Any new files that I need to add to the list of files included
in the gnuplot-4.6.rc1.tar.gz?

	Ethan




> 
> Regards
> 
> Tatsuro
> >     Ethan
> > 
> 

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/05/2012 11:01 AM, Ethan A Merritt wrote:
>> On 01/05/2012 01:35 AM, Daniel J Sebald wrote:
>>
>> Be that as it may, it might pay to step back a bit and consider just
>> what the QApplication is doing.
>>
>> But first, let me ask whether
>>
>>                  // Start
>>                  application.exec();
>>                  exit(0);
>>
>> should be _exit(0) instead of exit(0).
>
> Good point.  But that wouldn't help if there is an exit() call
> inside application.exec() somewhere, e.g. from an error.

If there's an exit() inside QtCore I can't tell (e.g., user closes all 
terminals using the mouse), but I would hope that is done gracefully in 
Qt.  There is a qt_atexit() routine, so I would guess that is the last 
thing called when QApplication is complete.  But that still doesn't 
answer if Qt exits directly or always comes back to the application.exec().

There is an exit() inside QtGnuplotEventHandler::readEvent() that you 
added to deal with any zombie processes.  The other way to get rid of 
zombies is to use the "wait()" inside the parent process after sending a 
drawing command to the Qt terminal.  (In that case, maybe exit should be 
replaced by a change in signal to indicate to the parent that something 
went wrong.)  If zombie processes are destroyed along with the parent, 
having a zombie process around isn't necessarily bad, unless it is a CPU 
hogging infinite loop.


>> J�r�me, do you think it would make sense to set up initialization of the
>> Qt terminal similar to the gplt_x11 terminal for better organization and
>> enable function under OS X at the same time?
>
> Wouldn't the IPC channel have to be revised as well?
> See the comments at the top of qt_flushOutBuffer() in qt_term.cpp

I see the comment, but I'm not completely understanding.  I did read in 
the Qt documentation somewhere that this flush was necessary so that 
there aren't duplicate input data of some sort.

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

[Ethan A M. <sf...@us...>]

> On 01/05/2012 01:35 AM, Daniel J Sebald wrote:
> 
> Be that as it may, it might pay to step back a bit and consider just 
> what the QApplication is doing.
> 
> But first, let me ask whether
> 
>                 // Start
>                 application.exec();
>                 exit(0);
> 
> should be _exit(0) instead of exit(0).

Good point.  But that wouldn't help if there is an exit() call
inside application.exec() somewhere, e.g. from an error.

> Also, these lines of code:
> 
>                 // Make sure the forked copy doesn't trash the history file
>                 cancel_history();
> 
> and
> 
>         // The creation of a QApplication mangled our locale settings
> #ifdef HAVE_LOCALE_H
>         setlocale(LC_NUMERIC, "C");
>         setlocale(LC_TIME, current_locale);
> #endif
> 
> are somewhat kluge-like in the sense they shouldn't be necessary.  (I 
> wonder if the mangled locale settings is because the child code used 
> exit() instead of _exit().)

You are absolutely right that both of these are empirical fixes
(kluges if you like), and it would seem that there should be a cleaner solution.  
I would be happy to apply any better solution you can suggest!  
In the case of normal program execution, your suggestion to
use _exit(0) would make the call to cancel_history() unnecessary.
If there's an error exit, I'm not so sure.


> J�r�me, do you think it would make sense to set up initialization of the 
> Qt terminal similar to the gplt_x11 terminal for better organization and 
> enable function under OS X at the same time?  

Wouldn't the IPC channel have to be revised as well?
See the comments at the top of qt_flushOutBuffer() in qt_term.cpp

	Ethan



> That is, put these lines 
> into a small separate C executable:
> 
> main(appropriate vectors)
> {
>                 signal(SIGINT, SIG_IGN); // Do not listen to SIGINT signals anymore
> 
> #ifndef HAVE_QT_47
>                 /*
>                  * FIXME: EAM Nov 2011
>                  * It is better to use environmental variable
>                  * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
>                  * "raster" is ~5x faster than "native" (default).
>                  * Unfortunately "opengl" isn't recognized on my test systems :-(
>                  */
>                 // This makes a huge difference to the speed of polygon rendering.
>                 // Alternatives are "native", "raster", "opengl"
>                 QApplication::setGraphicsSystem("raster");
> #endif
> 
>                 QtGnuplotApplication application(argc, (char**)( NULL));
> 
>                 // Make sure the forked copy doesn't trash the history file
>                 cancel_history();
> 
>                 // Load translations for the qt library
>                 QTranslator qtTranslator;
>                 qtTranslator.load("qt_" + QLocale::system().name(), 
> QLibraryInfo::location(QLibraryInfo::TranslationsPath));
>                 application.installTranslator(&qtTranslator);
> 
>                 // Load translations for the qt terminal
>                 QTranslator translator;
>                 translator.load("qtgnuplot_" + QLocale::system().name(), 
> QTGNUPLOT_DATA_DIR);
>                 application.installTranslator(&translator);
> 
>                 // Start
>                 application.exec();
>                 exit(0);
> 
> }
> 
> And in the qt_init() have something like the following (I left out 
> details, but they are available in x11.trm file):
> 
>         if (pid < 0)
>                 fprintf(stderr, "Forking error\n");
>         else if (pid == 0) // Child: start the GUI
>         {
>                 execvp(qtterm_full_command_path, optvec);
>                 _exit(0);
>         }
> 
> The advantage of using execvp is that it sort of wipes the slate clean 
> for creating the QApplication.
> 
> Please give us your thoughts.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/05/2012 05:17 AM, Daniel J Sebald wrote:

>  It is sort of a hybrid
> of two worlds, the QApplication being another process ID while at the
> same time still being a object instance in the parent space.  I suppose
> it works, but it's also somewhat of an odd feeling.

That's a wrong statement that I meant to delete before sending the last 
email, but for some reason it slipped through.

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/05/2012 05:10 AM, Mojca Miklavec wrote:
> On Thu, Jan 5, 2012 at 08:35, Daniel J Sebald wrote:
>>
>>   If it is
>> the former, then perhaps Qt users should not be using fork, but QThread.
>
> As already said, I don't know anything about forking, but it is also
> not clear to me why forking or creating a new binary is needed at all.

The reason is (as from what I read about Qt and my limited 
understanding) QApplication has to be the only event loop in a process. 
  It cannot run as an event loop along with a process that is also 
running an event loop.  In other words, gnuplot (an event loop) can't 
coexist with QApplication GUI (an event loop because it is processing 
button/keyboard/other events).

A fork is simply a means of creating another process, at least for most 
high level applications.  (Low level, there are other aspects of the 
duplication from fork that can be utilized, but not important here.)


> Here is an example of communication between GUI and Threads:
>
> http://developer.qt.nokia.com/doc/qt-4.8/thread-basics.html#example-3-clock

Those are threads within the Qt application, which isn't exactly the 
same as the OS threads commonly thought of.  The example you show has a 
main() routine for which QApplication is the only event loop.  The other 
elements are QObjects and such.  The issue is:

1) QApplication must be the only event loop, i.e., being able to run a 
QApplication GUI and gnuplot simultaneously.  (Hence the need for 
fork...why Qt doesn't handle this is what I asked before.)

2) Dealing with the Mac OS X limitation that CoreFoundation APIs (which 
Qt uses) cannot appear in a child process any longer.  (Hence the need 
for fork + exec and a separate binary.)

Dan

>
> Mojca
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/05/2012 01:35 AM, Daniel J Sebald wrote:

> I think it means that Qt has to call some Apple-written APIs
> (Lion/Cocoa/Carbon/CoreServices).  But the "we" here--does that mean the
> Qt developers writing the Qt code now have to use fork-and-exec?  Or
> does that mean the people using the Qt utility have to use
> fork-and-exec?  If it is the former, then perhaps Qt users should not be
> using fork, but QThread.

Eh, the QThread isn't exactly analogous to process.  A QThread has its 
own stack, but memory is shared across threads.  It's sort of like 
threads inside the QApplication.  No use.

I see a statement that QApplication needs to be the one and only event 
loop in a process to work correctly.  Hence the need for a fork I would 
assume.  (I'm guessing the exit(0) in qt_init() applies to the child 
process.  Exiting gnuplot would make no sense.)  Why Qt doesn't handle 
this, I don't know.

Be that as it may, it might pay to step back a bit and consider just 
what the QApplication is doing.

But first, let me ask whether

		// Start
		application.exec();
		exit(0);

should be _exit(0) instead of exit(0).  A child shouldn't flush parent 
files:

http://www.cs.uleth.ca/~holzmann/C/system/pipeforkexec.html

The bigger question is whether this approach to creating a GUI 
QApplication, using fork() alone, is the best.  It is sort of a hybrid 
of two worlds, the QApplication being another process ID while at the 
same time still being a object instance in the parent space.  I suppose 
it works, but it's also somewhat of an odd feeling.  Also, these lines 
of code:

		// Make sure the forked copy doesn't trash the history file
		cancel_history();

and

	// The creation of a QApplication mangled our locale settings
#ifdef HAVE_LOCALE_H
	setlocale(LC_NUMERIC, "C");
	setlocale(LC_TIME, current_locale);
#endif

are somewhat kluge-like in the sense they shouldn't be necessary.  (I 
wonder if the mangled locale settings is because the child code used 
exit() instead of _exit().)

Jérôme, do you think it would make sense to set up initialization of the 
Qt terminal similar to the gplt_x11 terminal for better organization and 
enable function under OS X at the same time?  That is, put these lines 
into a small separate C executable:

main(appropriate vectors)
{
		signal(SIGINT, SIG_IGN); // Do not listen to SIGINT signals anymore

#ifndef HAVE_QT_47
		/*
		 * FIXME: EAM Nov 2011
		 * It is better to use environmental variable
		 * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
		 * "raster" is ~5x faster than "native" (default).
		 * Unfortunately "opengl" isn't recognized on my test systems :-(
		 */
		// This makes a huge difference to the speed of polygon rendering.
		// Alternatives are "native", "raster", "opengl"
		QApplication::setGraphicsSystem("raster");
#endif

		QtGnuplotApplication application(argc, (char**)( NULL));

		// Make sure the forked copy doesn't trash the history file
		cancel_history();

		// Load translations for the qt library
		QTranslator qtTranslator;
		qtTranslator.load("qt_" + QLocale::system().name(), 
QLibraryInfo::location(QLibraryInfo::TranslationsPath));
		application.installTranslator(&qtTranslator);

		// Load translations for the qt terminal
		QTranslator translator;
		translator.load("qtgnuplot_" + QLocale::system().name(), 
QTGNUPLOT_DATA_DIR);
		application.installTranslator(&translator);

		// Start
		application.exec();
		exit(0);

}

And in the qt_init() have something like the following (I left out 
details, but they are available in x11.trm file):

	if (pid < 0)
		fprintf(stderr, "Forking error\n");
	else if (pid == 0) // Child: start the GUI
	{
		execvp(qtterm_full_command_path, optvec);
		_exit(0);
	}

The advantage of using execvp is that it sort of wipes the slate clean 
for creating the QApplication.

Please give us your thoughts.

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On Thu, Jan 5, 2012 at 08:35, Daniel J Sebald wrote:
>
> If it is
> the former, then perhaps Qt users should not be using fork, but QThread.

As already said, I don't know anything about forking, but it is also
not clear to me why forking or creating a new binary is needed at all.

Here is an example of communication between GUI and Threads:

http://developer.qt.nokia.com/doc/qt-4.8/thread-basics.html#example-3-clock

Mojca

Aquaterm version (was: Qt on Mac)

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

On Thu, Jan 5, 2012 at 02:36, Ethan A Merritt wrote:
> Mojca Miklavec wrote:
>> > sfeam wrote>
>> > Do you have a set of instructions we could include with 4.6 that tells
>> > people where/how to get a version of aquaterm compatible with current
>> > OSX and gnuplot?
>>
>> The latest released version of AquaTerm is compatible with Mac OS X
>> 10.4-10.7 (and probably later), with PowerPC, i386 and x86_64, so that
>> should be no problem.
>
> Aha. So I'm glad I asked for instructions.
>
> The information on the Aquaterm SourceForge page is different from what
> you give above.  There it says Aquaterm 1.1 is x86 only, and only tested
> on 10.5 and 10.6.  The previous version (Aquaterm 1.0.1) works on PPC under
> 10.5 and I can't quite figure out what it is saying about OSX 10.1 to 10.4.

I just realized that it was my bad memory about 10.4. It was a
deliberate decision to only support 10.5 in binary distribution for
several reasons (this kind of installer doesn't work on 10.4,
configuration scripts should be way more complex because a different
compiler would have to be used for different architectures, the old
version for 10.4 is still available, one can alway compile from source
etc.).

The README says that binary release supports Intel only. This doesn't
mean that it supports i386 and x86_64 (so both 32-bit and 64-bit).
What I honestly didn't know is that there were no PPC binaries. There
have always been in testing releases and the source code that I have
(https://github.com/gnuplot/aquaterm_aquaterm/blob/master/AquaTerm.xcodeproj/project.pbxproj)
lists PPC everywhere next to x86_64, so I have no idea why it was
dropped. (Still, given that the previous version works fine on PPC and
that this one hardly changes anything but adds 64-bit support, and
that PPC is heavily phased out, this is hardly critical. And building
from source should also work fine.)

> So is the information on the SourceForge page out of date,
> or is there another place to pull it from, or what?

I messed up a few things about 10.4 (also because I still have files
that make it possible to build for 10.4 and all three architectures,
they were just not included in the final release), PPC is indeed not
included when I check my binaries (I don't know why - it has always
been discussed that they would be), binaries work on 10.7 and have
indeed not been tested on 10.7 when AquaTerm was released. I don't
dare to claim anything, but it is quite possible that pre-last version
of AquaTerm works on 10.1-10.4.

However nobody cares about 10.1 any more. Many software doesn't even
support 10.5 any more. Apple's compilers always worked 2 versions
back. But the latest XCode is only able to compile binaries for 10.6
now.

Note that the source code of AquaTerm is still written in such a way
that it should probably still compile on 10.1. (Speculating a bit, but
not far from truth.) The only problem is that project files are not
compatible.

But I see no need for any special instructions in Gnuplot, like you
don't provide any instructions how to install wxt or qt or png/jpg or
other libraries. (What is really needed is a good Mac installer or
standalone application.)

I'm sorry for some slightly wrong & confusing claims.

Mojca

PS: users may influence AquaTerm behaviour (once gnuplot has already
been compiled) by setting the following two variables (just examples):
   export AQUATERM_PATH=/path/to/Applications/AquaTerm.app
   export DYLD_FRAMEWORK_PATH=/Library/Frameworks/
The first variable controls which AquaTerm.app will be launched in
case that there are many installed on the system and the second one
controls which Frameworks (dynamic library) will be used in case that,
say, AquaTerm is installed both under /Library/Frameworks and
/opt/Library/Frameworks for example (but may have other unexpected
side effects) .

Jérôme are you there? (was Re: Qt on Mac)

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

Jérôme,

There's a discussion going on about the Qt terminal under Mac OS X.  It 
seems that QtCore uses CoreFoundation APIs but a new rule imposed by 
Apple (or whomever) says that CoreFoundation calls can't be inside child 
processes.  The way the qt_term and qt_init are set up now creates the 
QApplication inside a child process.  Please look through the thread

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

I'm wondering if perhaps the creation of the GUI QApplication shouldn't 
be done in a way similar to gplt_x11, i.e., via exec().  I will follow up...

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/05/2012 12:58 AM, sfeam (Ethan Merritt) wrote:
> On Wednesday, 04 January 2012, Daniel J Sebald wrote:
>> On 01/04/2012 11:20 PM, sfeam (Ethan Merritt) wrote:
>>> On Wednesday, 04 January 2012, Daniel J Sebald wrote:
>> [snip]
>>> Dan:
>>>
>>> I could be wrong, but I don't think that  "application.exec()" is actually
>>> an exec() call in the normal linux sense.   See for example
>>>     http://stackoverflow.com/questions/3880693/qapplication-exec-creates-new-thread-process
>>>
>>> In this case it just means "start looping over the draw commands until I
>>> tell you to stop".   So your idea would be spot on if this were a real exec(),
>>> but I'm afraid it's not going to help in this case.   But hey, I could be wrong.
>>> It's simple enough to give it a try.
>>
>> Oh, that's a problem then.  The the code following the fork probably
>> needs to be written as a separate program and run via exec().  That's
>> considerable more work.
>>
>> Sorry, I can't find application.exec()
>
> It's inherited from the generic QtApplication.exec()
>
>> , but if all it does is reads
>> commands until done, then after that exit(0), why does this process need
>> to be forked?  (Maybe you don't know the reason.)
>
> The parent process is the usual gnuplot core code.
> The child process is the Qt display event loop, which manages the plot
> window, traps mouse events, and so on.
> The parent and child communicate via a shared channel that was set up
> before the fork().  This stuff is all conveniently handled by the Qt
> library routines, so you don't see much of it in the gnuplot code proper.
>
> Here's how I understand it.
> Suppose the core code wants to draw a point at (x,y).
> The call from the gnuplot side looks like this
>     (term->point)(x,y,type)
> But the different terminals do very different things.
>
> Non-interactive terminals:
> 	Call a library routine
> 	(synchronous; part of the same process)
> x11:
> 	Send the command over a pipe to gnuplot_x11
> 	(asynchronous; totally separate process)
> qt:
> 	Send the command via a shared channel to the Qt event loop
> 	(asynchronous; forked copy of the original process)
>
> I'm a bit fuzzy on how wxt works.  I _think_ it works the same as qt
> except that the fork is hidden inside the wxWidgets support code.
> If you run gnuplot using the wxt terminal you can see that it starts
> up a separate thread.   For a very long time people had trouble with
> wxt on OSX for I guess the same reason as we're now having trouble
> with qt.  However, somehow the wxt code was tweaked to avoid this
> specific OSX error (I am very hazy on that part!)  One might think
> a similar tweak would work for Qt, but the web page that Mojca found
> says that tripping over this OSX limitation in QtCore is "unavoidable".

The statement at that reference is slightly vague on the matter:

/**
  Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has 
always had issues
  on Mac OS X, but as of 10.5 is explicitly disallowed with an 
exception.  As a
  result, in the case where we would normally fork and then dlopen code, 
or continue
  to run other code, we must now fork-and-exec.

  See "CoreFoundation and fork()" at 
http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html
*/

I think it means that Qt has to call some Apple-written APIs 
(Lion/Cocoa/Carbon/CoreServices).  But the "we" here--does that mean the 
Qt developers writing the Qt code now have to use fork-and-exec?  Or 
does that mean the people using the Qt utility have to use 
fork-and-exec?  If it is the former, then perhaps Qt users should not be 
using fork, but QThread.

Anyway, here is that missing discussion on CoreFoundation and fork():

http://osdir.com/ml/darwin-dev/2009-05/msg00020.html

"CoreFoundation cannot be used on the child-side of fork()"

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 04 January 2012, Daniel J Sebald wrote:
> On 01/04/2012 11:20 PM, sfeam (Ethan Merritt) wrote:
> > On Wednesday, 04 January 2012, Daniel J Sebald wrote:
> [snip]
> > Dan:
> >
> > I could be wrong, but I don't think that  "application.exec()" is actually
> > an exec() call in the normal linux sense.   See for example
> >    http://stackoverflow.com/questions/3880693/qapplication-exec-creates-new-thread-process
> >
> > In this case it just means "start looping over the draw commands until I
> > tell you to stop".   So your idea would be spot on if this were a real exec(),
> > but I'm afraid it's not going to help in this case.   But hey, I could be wrong.
> > It's simple enough to give it a try.
> 
> Oh, that's a problem then.  The the code following the fork probably 
> needs to be written as a separate program and run via exec().  That's 
> considerable more work.
> 
> Sorry, I can't find application.exec()

It's inherited from the generic QtApplication.exec()

> , but if all it does is reads 
> commands until done, then after that exit(0), why does this process need 
> to be forked?  (Maybe you don't know the reason.)

The parent process is the usual gnuplot core code.
The child process is the Qt display event loop, which manages the plot
window, traps mouse events, and so on.
The parent and child communicate via a shared channel that was set up 
before the fork().  This stuff is all conveniently handled by the Qt
library routines, so you don't see much of it in the gnuplot code proper.

Here's how I understand it.  
Suppose the core code wants to draw a point at (x,y).
The call from the gnuplot side looks like this
   (term->point)(x,y,type)
But the different terminals do very different things.

Non-interactive terminals:   
	Call a library routine 
	(synchronous; part of the same process)
x11: 
	Send the command over a pipe to gnuplot_x11 
	(asynchronous; totally separate process)
qt:
	Send the command via a shared channel to the Qt event loop
	(asynchronous; forked copy of the original process)

I'm a bit fuzzy on how wxt works.  I _think_ it works the same as qt
except that the fork is hidden inside the wxWidgets support code.
If you run gnuplot using the wxt terminal you can see that it starts
up a separate thread.   For a very long time people had trouble with
wxt on OSX for I guess the same reason as we're now having trouble
with qt.  However, somehow the wxt code was tweaked to avoid this
specific OSX error (I am very hazy on that part!)  One might think
a similar tweak would work for Qt, but the web page that Mojca found
says that tripping over this OSX limitation in QtCore is "unavoidable".

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/04/2012 11:49 PM, Daniel J Sebald wrote:
> On 01/04/2012 11:20 PM, sfeam (Ethan Merritt) wrote:
>> On Wednesday, 04 January 2012, Daniel J Sebald wrote:
> [snip]
>> Dan:
>>
>> I could be wrong, but I don't think that  "application.exec()" is actually
>> an exec() call in the normal linux sense.   See for example
>>     http://stackoverflow.com/questions/3880693/qapplication-exec-creates-new-thread-process
>>
>> In this case it just means "start looping over the draw commands until I
>> tell you to stop".   So your idea would be spot on if this were a real exec(),
>> but I'm afraid it's not going to help in this case.   But hey, I could be wrong.
>> It's simple enough to give it a try.
>
> Oh, that's a problem then.  The the code following the fork probably
> needs to be written as a separate program and run via exec().  That's
> considerable more work.
>
> Sorry, I can't find application.exec(), but if all it does is reads
> commands until done, then after that exit(0), why does this process need
> to be forked?  (Maybe you don't know the reason.)

Answering my own question as best I can.  If I'm understanding 
correctly, Qt provides a mechanism for creating threads:

http://developer.qt.nokia.com/doc/qt-4.8/qthread.html

This is supposedly platform independent, which would suggest gnuplot's 
qt_init() shouldn't be using fork(), which is a platform dependent 
routine.  Maybe QThread is the way to go, and it takes care of all the 
fork/exec issues at its core.

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/04/2012 11:20 PM, sfeam (Ethan Merritt) wrote:
> On Wednesday, 04 January 2012, Daniel J Sebald wrote:
[snip]
> Dan:
>
> I could be wrong, but I don't think that  "application.exec()" is actually
> an exec() call in the normal linux sense.   See for example
>    http://stackoverflow.com/questions/3880693/qapplication-exec-creates-new-thread-process
>
> In this case it just means "start looping over the draw commands until I
> tell you to stop".   So your idea would be spot on if this were a real exec(),
> but I'm afraid it's not going to help in this case.   But hey, I could be wrong.
> It's simple enough to give it a try.

Oh, that's a problem then.  The the code following the fork probably 
needs to be written as a separate program and run via exec().  That's 
considerable more work.

Sorry, I can't find application.exec(), but if all it does is reads 
commands until done, then after that exit(0), why does this process need 
to be forked?  (Maybe you don't know the reason.)

Dan

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 04 January 2012, Daniel J Sebald wrote:
> On 01/04/2012 04:46 PM, Mojca Miklavec wrote:
> > On Wed, Jan 4, 2012 at 23:09, Ethan A Merritt wrote:
> >> Mojca Miklavec wrote>
> >> I've just been debugging configuration problems with Qt 4.7.4, where it turns
> >> out that I need to do the same thing in order to pick up locations for
> >> the rcc and lrelease utilities.
> >>
> >>> - if I fix the two above, qt terminal compiles fine, but I cannot plot anything:
> >>>
> >>> gnuplot>  plot sin(x)
> >>> The process has forked and you cannot use this CoreFoundation
> >>> functionality safely. You MUST exec().
> >>> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
> >>> to debug.> 
> 
> > Last time I didn't find anything useful either. However google now
> > pointed me to the following:
> >
> > http://gitorious.org/~friesoft/dinjam/friesoft-development/blobs/master/src/sources/data/standarddirs_mac.cpp
> >
> > /**
> >   Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has
> > always had issues
> >   on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
> >   result, in the case where we would normally fork and then dlopen
> > code, or continue
> >   to run other code, we must now fork-and-exec.
> 
> So what you are seeing is the exception that OS X is now throwing when 
> it sees you fork() and then not exec(), apparently.  My guess is this 
> might be a security measure in some way.  (How?  I don't know, just 
> guessing.)
> 
> 
> > I would be willing to debug, but I have no idea how to do so. I
> > created a ticket:
> >      https://sourceforge.net/tracker/?func=detail&aid=3469233&group_id=2055&atid=102055
> > where I attached crash report (I just realized where systems stores
> > crash reports) if that is of any help, but I'm not sure neither how to
> > debug nor how to fix anything.
> >
> > If you tell me how exactly to "exec()" after fork in qt_term.cpp, I
> > can test it, but I don't fully understand the code, so I'm not sure
> > what exactly to change and how.
> 
> It appears that the fork() is in the qt_init() routine:
> 
> 236        pid = fork();
> 237	        if (pid < 0)
> 238	                fprintf(stderr, "Forking error\n");
> 239	        else if (pid == 0) // Child: start the GUI
> 240	        {
> 241	                signal(SIGINT, SIG_IGN); // Do not listen to SIGINT 
> signals anymore
> 242	
> 243	#ifndef HAVE_QT_47
> 244	                /*
> 245	                 * FIXME: EAM Nov 2011
> 246	                 * It is better to use environmental variable
> 247	                 * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
> 248	                 * "raster" is ~5x faster than "native" (default).
> 249	                 * Unfortunately "opengl" isn't recognized on my 
> test systems :-(
> 250	                 */
> 251	                // This makes a huge difference to the speed of 
> polygon rendering.
> 252	                // Alternatives are "native", "raster", "opengl"
> 253	                QApplication::setGraphicsSystem("raster");
> 254	#endif
> 255	
> 256	                QtGnuplotApplication application(argc, (char**)( NULL));
> 
> 
> > It is pretty clear that problems start at this line in qt_term.cpp:
> >      QtGnuplotApplication application(argc, (char**)( NULL));
> > but after this line gets executed, I cannot even printf (whatever I
> > put into print, it doesn't get displayed until something semi-crashes
> > and printf sometimes starts working afer QApplication* application =
> > new QApplication(argc, (char**)( NULL)); again).
> 
> I would guess that the line Ethan conditioned isn't active when you 
> compile.  That leaves "signal(SIGINT, SIG_IGN);" as the first line after 
> the fork, and that is probably a CoreFunction routine itself so doesn't 
> throw the exception or odd behavior.  Thus "QtGnuplotApplication 
> application(argc, (char**)( NULL));" is the first line of code to follow 
> the fork and probably throws the exception.  According to what you have 
> found exec() should nearly follow fork() and you can't have all that 
> code in between.  Thus as a first test, perhaps try moving the fork 
> before the exec(), e.g.,
> 
> #ifndef HAVE_QT_47
>                  /*
>                   * FIXME: EAM Nov 2011
>                   * It is better to use environmental variable
>                   * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
>                   * "raster" is ~5x faster than "native" (default).
>                   * Unfortunately "opengl" isn't recognized on my test 
> systems :-(
>                   */
>                  // This makes a huge difference to the speed of polygon 
> rendering.
>                  // Alternatives are "native", "raster", "opengl"
>                  QApplication::setGraphicsSystem("raster");
> #endif
> 
>                  QtGnuplotApplication application(argc, (char**)( NULL));
> 
>                  // Make sure the forked copy doesn't trash the history 
> file
>                  cancel_history();
> 
>                  // Load translations for the qt library
>                  QTranslator qtTranslator;
>                  qtTranslator.load("qt_" + QLocale::system().name(), 
> QLibraryInfo::location(QLibraryInfo::TranslationsPath));
>                  application.installTranslator(&qtTranslator);
> 
>                  // Load translations for the qt terminal
>                  QTranslator translator;
>                  translator.load("qtgnuplot_" + 
> QLocale::system().name(), QTGNUPLOT_DATA_DIR);
>                  application.installTranslator(&translator);
> 
> 	        pid = fork();
> 
> 	        if (pid < 0)
> 	                fprintf(stderr, "Forking error\n");
> 	        else if (pid == 0) // Child: start the GUI
> 	        {
> 	                signal(SIGINT, SIG_IGN); // Do not listen to SIGINT 
> signals anymore
> 	                // Start
> 	                application.exec();
> 	                exit(0);
> 	        }
> 
> 
> That may fail because of dependence on the fork() being called before 
> some of those other routines, but it's a start.  (If it fails, try 
> moving the application.exec() up near the fork, but you'll have to leave 
> behind the exit(0) otherwise the translations will be missing.)
> 
> Dan

Dan:

I could be wrong, but I don't think that  "application.exec()" is actually
an exec() call in the normal linux sense.   See for example
  http://stackoverflow.com/questions/3880693/qapplication-exec-creates-new-thread-process

In this case it just means "start looping over the draw commands until I
tell you to stop".   So your idea would be spot on if this were a real exec(),
but I'm afraid it's not going to help in this case.   But hey, I could be wrong.
It's simple enough to give it a try.

		Ethan