gnuplot-beta

Getting ready to put out a 4.6 release candidate

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

Over the holidays I resolved several long-standing bugs related to 
the helper threads forked by the wxt and qt terminals.
This should take care of reported problems with zombie processes,
truncated history files, and program failures if mouse and keyboard
events arrive out of the expected order.  The qt terminal is now
acting very reliably for me under linux, which is a big improvement.

So my list of must-fix-for-4.6 items is now empty.

Does anyone know of issues that should be addressed before putting 
out a version 4.6.rc1 release candidate?

You can have a look at a draft announcement on the News section of
the gnuplot home page.

		Happy New Year!

			Ethan

Re: Getting ready to put out a 4.6 release candidate

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

On Tue, Jan 3, 2012 at 01:32, sfeam (Ethan Merritt) wrote:
>
> So my list of must-fix-for-4.6 items is now empty.
>
> Does anyone know of issues that should be addressed before putting
> out a version 4.6.rc1 release candidate?

Qt terminal doesn't work on Mac OS X, but I don't know if you plan to
fix this before 4.6 on not.

There are at least the following issues:
- configure script is unable to find Qt (it should be easy enough to
check for at least one more default location; I don't know how to work
with autotools, but I can tell which flags are needed)
- MOC and UIC are set to an empty string; here "moc" and "uic"
commands work fine, but I don't know why configure script doesn't find
them
- if I fix the two above, qt terminal compiles fine, but I cannot plot anything:


Terminal type set to 'qt'
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.
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.
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.
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.

(I'm willing to provide information and test, but I don't know how to
write patches for configure scripts.)

Mojca

Re: Getting ready to put out a 4.6 release candidate

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

Mojca Miklavec <moj...@gm...> wrote >
 
> Qt terminal doesn't work on Mac OS X, but I don't know if you plan to
> fix this before 4.6 on not.

Not me :-)  I think we have established very well that people here are not
up to the task of configuring support for new options under OSX.

> There are at least the following issues:
> - configure script is unable to find Qt 

It uses pkg-config.  If your Qt installation does not come with a set of
*.pc files then the configuration script will not work.

> - MOC and UIC are set to an empty string; here "moc" and "uic"
> commands work fine, but I don't know why configure script doesn't find
> them

Because it queries pkg-config to find out where they are.
   MOC=`pkg-config --variable=moc_location QtCore`

By the way, what version of Qt are you trying to use?
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.

No idea what that's about. It is clearly some OSX weirdness.
Googling that error message turns up this totally bizarre advice:

  In Server Admin stop SMB, remove it from services (save), re-add it (save), then start SMB.

In other words, people seem to have gotten this error message as a side effect of
the network/SMB configuration.

	Ethan

Re: Getting ready to put out a 4.6 release candidate

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

Hello

Please discuss the below for windows distribution,
contents of docs directory in windows binaries
http://news.gmane.org/gmane.comp.graphics.gnuplot.devel

Regards

Tatsuro


--- On Tue, 2012/1/3, sfeam (Ethan Merritt) wrote:

> Over the holidays I resolved several long-standing bugs related to 
> the helper threads forked by the wxt and qt terminals.
> This should take care of reported problems with zombie processes,
> truncated history files, and program failures if mouse and keyboard
> events arrive out of the expected order.  The qt terminal is now
> acting very reliably for me under linux, which is a big improvement.
> 
> So my list of must-fix-for-4.6 items is now empty.
> 
> Does anyone know of issues that should be addressed before putting 
> out a version 4.6.rc1 release candidate?
> 
> You can have a look at a draft announcement on the News section of
> the gnuplot home page.
> 
>         Happy New Year!
> 
>             Ethan
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Getting ready to put out a 4.6 release candidate

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

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?

Regards

Tatsuro

--- On Wed, 2012/1/4, Tatsuro MATSUOKA  wrote:

> Hello
> 
> Please discuss the below for windows distribution,
> contents of docs directory in windows binaries
> http://news.gmane.org/gmane.comp.graphics.gnuplot.devel
> 
> Regards
> 
> Tatsuro
> 
> 
> --- On Tue, 2012/1/3, sfeam (Ethan Merritt) wrote:
> 
> > Over the holidays I resolved several long-standing bugs related to 
> > the helper threads forked by the wxt and qt terminals.
> > This should take care of reported problems with zombie processes,
> > truncated history files, and program failures if mouse and keyboard
> > events arrive out of the expected order.  The qt terminal is now
> > acting very reliably for me under linux, which is a big improvement.
> > 
> > So my list of must-fix-for-4.6 items is now empty.
> > 
> > Does anyone know of issues that should be addressed before putting 
> > out a version 4.6.rc1 release candidate?
> > 
> > You can have a look at a draft announcement on the News section of
> > the gnuplot home page.
> > 
> >         Happy New Year!
> > 
> >             Ethan
> > 
> > ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create 
> > new or port existing apps to sell to consumers worldwide. Explore the 
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Getting ready to put out a 4.6 release candidate

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

Tatsuro MATSUOKA <tma...@ya...> wrote >
> 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?   
Have there been any user reports to indicate how many people have
successfully used it?

	Ethan

Re: Getting ready to put out a 4.6 release candidate

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

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.

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

[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, 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: Getting ready to put out a 4.6 release candidate

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

Hello

I have checked out the recent 4.6 cvs source.
I have confirmed the windows installer can be made using this source tree.

I will check cygwin and djgpp.

Regards

Tatsuro


--- On Sat, 2012/1/7, Tatsuro MATSUOKA 

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

snapshot of windows, cygwin and djgpp binaries of version 4.6 from cvs source (was Getting ready to put out a 4.6 release candidate)

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

Hello

I have made windows, cygwin and djgpp binaries of version 4.6 from cvs source.
I have upload them for checking purpose.

Regards

Tatsuro
 
--- On Tue, 2012/1/17, Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello
> 
> I have checked out the recent 4.6 cvs source.
> I have confirmed the windows installer can be made using this source tree.
> 
> I will check cygwin and djgpp.
> 
> Regards
> 
> Tatsuro
> 
> 
> --- On Sat, 2012/1/7, Tatsuro MATSUOKA 
> 
> > 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 
> > 
> > ------------------------------------------------------------------------------
> > 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
> > 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

$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

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

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

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

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: screendump and Qt - Re: Getting ready to put out a 4.6 release candidate

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

On Sat, Jan 7, 2012 at 01:12, Petr Mikulik wrote:
>> 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?

What is the difference between screendump and print then?

Mojca

Re: 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?
> 
> What is the difference between screendump and print then?

"screendump" is the command to do the print action (instead of clicking the 
icon)

---
Petr

Lua/tikz terminal for DJGPP binary (Re: Getting ready to put out a 4.6 release candidate)

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

Hello

Current dggpp binary from cvs source that I have been distributed experimentally includes the lua/tikz terminal.

For the official 4.6 release, will the lua/tikz be included?

Regards

Tatsuro  


--- On Tue, 2012/1/3, sfeam (Ethan Merritt)  wrote:

> Over the holidays I resolved several long-standing bugs related to 
> the helper threads forked by the wxt and qt terminals.
> This should take care of reported problems with zombie processes,
> truncated history files, and program failures if mouse and keyboard
> events arrive out of the expected order.  The qt terminal is now
> acting very reliably for me under linux, which is a big improvement.
> 
> So my list of must-fix-for-4.6 items is now empty.
> 
> Does anyone know of issues that should be addressed before putting 
> out a version 4.6.rc1 release candidate?
> 
> You can have a look at a draft announcement on the News section of
> the gnuplot home page.
> 
>         Happy New Year!
> 
>             Ethan
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Lua/tikz terminal for DJGPP binary (Re: Getting ready to put out a 4.6 release candidate)

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

> Hello
> 
> Current dggpp binary from cvs source that I have been distributed experimentally includes the lua/tikz terminal.
> 
> For the official 4.6 release, will the lua/tikz be included?

  So far as I know, yes.
  Is there some reason not to include it?

	Ethan

> Regards
> Tatsuro  
>