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

Re: Observations on the 4.6rc1 windows package

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

Am 17.02.2012 19:16, schrieb Juhász Péter:
> On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
>>
>> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
>>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
>>>>
>>>> - On one of my machines, startup appeared to be extremely slow, taking
>>>> about 5 minutes (!). This is true for both the console and GUI versions.
>>>> For the first few tries I've actually killed the process, because I
>>>> didn't have the patience to wait it out. Once it started, it appeared to
>>>> work normally, there were no delays and plotting was instantaneous as
>>>> well. (Older versions had a long delay at the first plot because of
>>>> fontconfig or whatever.)
>>>> This happened in both interactive and non-interactive mode, however,
>>>> only on a virtual machine running Vista. On a real computer running
>>>> Windows 7, startup was instantaneous.
>>>
>>> I seem to recall this was discussed a couple of years ago.
>>> The issue then was that if the program did not find a certain set of fonts,
>>> it triggered creation of a bitmap font set from the underlying font
>>> descriptions.  This was painfully slow but only  happened the first time,
>>> since subsequent runs would find the  now-created font set.
>>> However, I wonder if you run under a virtual machine whether every time
>>> is a "first" time?  Anyhow, my best guess is that this is a font issue
>>> rather than anything to do with gnuplot per se.
>>>
>>> 	Ethan
>>>
>>
>> The cairo terminals no longer use the fontconfig mechanism of Windows,
>> so this particular issue should have been solved.
>> On the other hand I vaguely remember a similar report a while ago, but I
>> couldn't reproduce on various XP, Vista and 7 machines.
>>
>
> On further testing I've noticed that there *is* a slight delay on
> startup even on the Win7 machine (4-5 seconds). This means that even
> something like 'gnuplot -e "print 1"' takes this much time.
>
> Péter Juhász
>

Finally, I have been able to reproduce this delay on a Vista machine 
using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
4.5 build which does not include cairo and wxt terminals does not show 
the delay on start-up.
Also, I do not see any notable delay using my own build (including wxt 
and cairo), see
http://gnuplot.info/development/binaries/
Is anybody able to reproduce this observation?

   Bastian

Re: set macro inconsistency

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

On Tuesday, February 21, 2012 11:17:07 pm pl...@pi... wrote:
> Hi,
> 
> I just defined a few macros to shorten some lengthy plot commands, eg.
> 
> in_lt_blue=' linecol rgb "light-blue" '
> 
> It worked fine when I loaded the complete file using load command. No 
> errors and I got the right results.
> 
> Then I tested something else directly at the command prompt:
> 
> gnuplot> in_red=' linecol rgb "red" '
> gnuplot> @in_red
>                    ^
>           invalid character @
> 
> 
> I realised that this was in fact correct since I had not ' set macros'
> 
> But in that case why did it work when I loaded this and similar lines 
> with load ?
> 
> It seems that there is an inconsistency here. The load command should 
> equally have to parse the macros since there was no set macro command in 
> the script.
> 
> So there is an apparent bug: load command somehow circumvents the check 
> on the state of set macros and expands them anyway.

You are correct.  
The string_expand_macros() routine is called in two places.  
One is inside a test for if (expand_macros) {}, but the one used by the 
load command is not.  I do not recall if this was intentional
or simply an oversight.   

It would be a one-line change to misc.c, but let me think about possible
side effects.  

Re: set macro inconsistency

[<pl...@pi...>]

On 02/22/12 09:37, Christoph Bersch wrote:
> Hi,
>
> On 22.02.2012 08:17, pl...@pi... wrote:
>>
>> I just defined a few macros to shorten some lengthy plot commands, eg.
>>
>> in_lt_blue=' linecol rgb "light-blue" '
>>
>> It worked fine when I loaded the complete file using load command. No
>> errors and I got the right results.
>>
>> Then I tested something else directly at the command prompt:
>>
>> gnuplot>   in_red=' linecol rgb "red" '
>> gnuplot>   @in_red
>>                      ^
>>             invalid character @
>>
>>
>> I realised that this was in fact correct since I had not ' set macros'
>>
>> But in that case why did it work when I loaded this and similar lines
>> with load ?
>
> could you try to construct a small example which shows this behavior? I
> tried the following to reproduce the error, but it does not show what
> you report:
>
> system('echo "in_red='' linecol rgb \"red\" ''">  test.gp')
> load 'test.gp'
> @in_red
>
> this gives me "invalid character @"
>
> Christoph

Put this in a text file and load it . Change colours to confirm the 
macro is being expanded and used.

in_red=' linecol rgb "blue" '
plot sin(x) @in_red

show macros




gnuplot> load "../test.gnu"

         command line macros will not be expanded


Peter

Re: set macro inconsistency

[Christoph B. <us...@be...>]

Hi,

On 22.02.2012 08:17, pl...@pi... wrote:
>
> I just defined a few macros to shorten some lengthy plot commands, eg.
>
> in_lt_blue=' linecol rgb "light-blue" '
>
> It worked fine when I loaded the complete file using load command. No
> errors and I got the right results.
>
> Then I tested something else directly at the command prompt:
>
> gnuplot>  in_red=' linecol rgb "red" '
> gnuplot>  @in_red
>                     ^
>            invalid character @
>
>
> I realised that this was in fact correct since I had not ' set macros'
>
> But in that case why did it work when I loaded this and similar lines
> with load ?

could you try to construct a small example which shows this behavior? I 
tried the following to reproduce the error, but it does not show what 
you report:

system('echo "in_red='' linecol rgb \"red\" ''" > test.gp')
load 'test.gp'
@in_red

this gives me "invalid character @"

Christoph

set macro inconsistency

[<pl...@pi...>]

Hi,

I just defined a few macros to shorten some lengthy plot commands, eg.

in_lt_blue=' linecol rgb "light-blue" '

It worked fine when I loaded the complete file using load command. No 
errors and I got the right results.

Then I tested something else directly at the command prompt:

gnuplot> in_red=' linecol rgb "red" '
gnuplot> @in_red
                   ^
          invalid character @


I realised that this was in fact correct since I had not ' set macros'

But in that case why did it work when I loaded this and similar lines 
with load ?

It seems that there is an inconsistency here. The load command should 
equally have to parse the macros since there was no set macro command in 
the script.

So there is an apparent bug: load command somehow circumvents the check 
on the state of set macros and expands them anyway.

regards, Peter.

Re: No more zip file for 4.6?

[Tait <gnu...@t4...>]

Works now, and at least starts up.

Thanks!

> Sorry I have corrected the link. 
> Perhaps this time is OK.
> 
> Can you confirm download?
>
> > It's taken me a while to get back to this. The zip file from your link appears to be dead.
> > 
> > > I have prepared zip style distribution.
> > > http://www.tatsuromatsuoka.com/gnuplot/Eng/gp46/
> > > 
> > > > > I would like to also prepare zip style distribution for Windows binary.
> > > > > 
> > > > > > I went to try out 4.6rc today, but the only binary file available is a
> > > > > > *.exe. What happened to the *.zip file (which I prefer)?

Re: No more zip file for 4.6?

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

--- On Tue, 2012/2/21, Tait wrote:

> 
> It's taken me a while to get back to this. The zip file from your link appears to be dead.
> 
> 
> 
> > Hello
> > 
> > I have prepared zip style distribution.
> > 
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/gp46/
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > > --- On Fri, 2012/2/17, Tatsuro MATSUOKA  wrote:
> > > > Hello
> > > > 
> > > > gp46rc1-win32-setup.exe is an installer. You can install gnuplot to any directory in which you would like to place gnuplot.
> > > > 
> > > > BTW, there are need to old zip style distribution, it could be additional distribution style.
> > > > I would like to also prepare zip style distribution for Windows binary.
> > > > 
> > > > Regards
> > > > 
> > > > Tatsuro 
> > > > 
> > > > 
> > > > --- On Fri, 2012/2/17, Tait wrote:
> > > > 
> > > > > 
> > > > > I went to try out 4.6rc today, but the only binary file available is a
> > > > > *.exe. What happened to the *.zip file (which I prefer)?
> > > > > 
> > > > > Downloading an executable means the user must run it blindly. A zip file
> > > > > has the advantage that it is data, not an executable. A trusted unzip
> > > > > program can interpret and open the zip file, at least giving the user the
> > > > > chance to inspect the contents before executing code. For a program like
> > > > > gnuplot that doesn't actually need to execute code to install, this is
> > > > > unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
> > > > > provide any chance for verification, and given SourceForge compromises
> > > > > in the past, this makes me uncomfortable.
> > > > > 
> > > > > Second, the executable can't even be used unless the user is (logged in
> > > > > as) an administrator, which is also unnecessary and risky. Users who are
> > > > > not administrators can't even reasonably use gnuplot on Windows anymore.
> > > > > (I don't think expecting them to compile it from source, with all the
> > > > > dependencies, is reasonable.)
> > > > > 
> > > > > Can we bring the zip file back, at least as an additional download option,
> > > > > please?
> > > > > 
> > > > > 
> > > > > 
> > > > > 

Hello

Sorry I have corrected the link. 
Perhaps this time is OK.

Can you confirm download?

Regards

Tatsuro

Re: No more zip file for 4.6?

[Tait <gnu...@t4...>]

To be clear, I'm not asking to eliminate the installer! I'm only asking
that we _not_ eliminate the zip file. There's room for both, I think.

> the installer was (mostly) introduced because newer windows versions
> (esp. win7) give a lot of trouble if you just unzip and run a new
> application. ...

Yes, this information is stored as part of an NTFS stream attached to
the file, and is propagated to the files after unzipping. It's trivial
to work-around (and does not require administrative rights to do so).
Just go to the file properties and click "Unblock" before unzipping. I
don't have a Vista OS anymore to try this again today, but that is how
is has worked since one of the XP service backs all the way up through
7 (and still does, at least on 7). I expect that users who have
encountered this issue are already aware of the steps to work around
it. Those who are not will quickly find the answer by searching for
"unblock zip file windows".  The issue isn't unique to gnuplot, or even
to downloaded programs in general, but applies to all
inter-security-zone transfers.

FAT filesystems don't support NTFS streams, which is why that
information is lost when you copy over to a FAT file system and back.

> Also, the added security you get from installing by a trusted unzip
> program is negligible. ...

You're partially right, of course. A targeted attack against gnuplot
specifically will be more subtle. But the issue is actually more
complex, and I was hoping to skim over it because this isn't a
security discussion forum. Just please take my word that some users
see a significant and justifiable difference in the security of a
zip file vs. an executable. (And I happen to be one such user.)

My tangent to that was a gentle suggestion that maybe we should
announce hashes of the binaries we release, which would be resistant
to even targeted attack. (Assuming the hashes weren't announced by
putting them on the same website as the executable, of course. The
mailing list is one alternative venue for widespread dissemination
of hash information.)

> You absolutely need to have administrator privileges to install a
> program..

There are different meanings of "install" at work here, I think. To
modify Windows' idea about what is installed and can be uninstalled,
one of course needs administrative privileges*. Gnuplot doesn't (or
hasn't) need(ed) to be "installed" in that sense of the word. It is
perfectly happy to run from an unzipped folder, in similar fashion
to how "portable" apps work. Users who don't care about what Windows
considers "installed" can use gnuplot as a non-administrator by un-
zipping it to their home directory and running from there.

My point was that the new installer will not even allow extracting
its contents unless the user is an administrator. And that breaks
the usage model I outlined in the paragraph above. Non-administrative
users can't get access to the bits needed to run gnuplot... at all.

* And that's not even strictly true for all configurations, but again,
I'm trying to stay mostly topical to gnuplot.

> On 20:59, Tait wrote:
> > I went to try out 4.6rc today, but the only binary file available is a
> > *.exe. What happened to the *.zip file (which I prefer)?
> > 
> > Downloading an executable means the user must run it blindly...
> > 
> > Second, the executable can't even be used unless the user is (logged in
> > as) an administrator...
> > 
> > Can we bring the zip file back, at least as an additional download option,
> > please?

Re: No more zip file for 4.6?

[Tait <gnu...@t4...>]

It's taken me a while to get back to this. The zip file from your link appears to be dead.



> Hello
> 
> I have prepared zip style distribution.
> 
> http://www.tatsuromatsuoka.com/gnuplot/Eng/gp46/
> 
> Regards
> 
> Tatsuro
> 
> > --- On Fri, 2012/2/17, Tatsuro MATSUOKA  wrote:
> > > Hello
> > > 
> > > gp46rc1-win32-setup.exe is an installer. You can install gnuplot to any directory in which you would like to place gnuplot.
> > > 
> > > BTW, there are need to old zip style distribution, it could be additional distribution style.
> > > I would like to also prepare zip style distribution for Windows binary.
> > > 
> > > Regards
> > > 
> > > Tatsuro 
> > > 
> > > 
> > > --- On Fri, 2012/2/17, Tait wrote:
> > > 
> > > > 
> > > > I went to try out 4.6rc today, but the only binary file available is a
> > > > *.exe. What happened to the *.zip file (which I prefer)?
> > > > 
> > > > Downloading an executable means the user must run it blindly. A zip file
> > > > has the advantage that it is data, not an executable. A trusted unzip
> > > > program can interpret and open the zip file, at least giving the user the
> > > > chance to inspect the contents before executing code. For a program like
> > > > gnuplot that doesn't actually need to execute code to install, this is
> > > > unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
> > > > provide any chance for verification, and given SourceForge compromises
> > > > in the past, this makes me uncomfortable.
> > > > 
> > > > Second, the executable can't even be used unless the user is (logged in
> > > > as) an administrator, which is also unnecessary and risky. Users who are
> > > > not administrators can't even reasonably use gnuplot on Windows anymore.
> > > > (I don't think expecting them to compile it from source, with all the
> > > > dependencies, is reasonable.)
> > > > 
> > > > Can we bring the zip file back, at least as an additional download option,
> > > > please?
> > > > 
> > > > 
> > > > 
> > > > ------------------------------------------------------------------------------
> > > > Virtualization & Cloud Management Using Capacity Planning
> > > > Cloud computing makes use of virtualization - but cloud computing 
> > > > also focuses on allowing computing to be delivered as a service.
> > > > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Virtualization & Cloud Management Using Capacity Planning
> > > Cloud computing makes use of virtualization - but cloud computing 
> > > also focuses on allowing computing to be delivered as a service.
> > > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > 
> > 
> > ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing 
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >

Re: No more zip file for 4.6?

[Karl-Friedrich R. <mai...@gm...>]

Hi,

the installer was (mostly) intruduced because newer windows versions
(esp. win7) give a lot of trouble if you just unzip and run a new
application. The explorer will remember that the executable came
from a web download and regard it as unsafe, and ask you every time
you want to run it. If you´re no administrator, there is no way to
"unlock" it. The help file was especially troublesome in this
regard, the only way to get it to run was (in my experience) to copy
it to a fat filesystem (where it forgets its origin), and then
retrieve it from there.

Also, the added security you get from installing by a trusted unzip
program is negligible. Anybody who can taint the installer could
also meddle with any of the executables in the zip file. That is not
even "security by obscurity", you just fool yourself into thinking
you´re somewhat safer.

You absolutely need to have administrator privileges to install a
program, and it is a good thing that windows nowerdays enforces this
(or at least tries to). You never need to log in as one, win7 gets
you a "sudo" equivalent if you right-click on an executable.

So I´d say under w2k or XP the old zip-file style worked OK, but you
really gain nothing, and on win7 it´s just a lot of trouble.

Kind regards,
   Karl





On 20:59, Tait wrote:
> 
> I went to try out 4.6rc today, but the only binary file available is a
> *.exe. What happened to the *.zip file (which I prefer)?
> 
> Downloading an executable means the user must run it blindly. A zip file
> has the advantage that it is data, not an executable. A trusted unzip
> program can interpret and open the zip file, at least giving the user the
> chance to inspect the contents before executing code. For a program like
> gnuplot that doesn't actually need to execute code to install, this is
> unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
> provide any chance for verification, and given SourceForge compromises
> in the past, this makes me uncomfortable.
> 
> Second, the executable can't even be used unless the user is (logged in
> as) an administrator, which is also unnecessary and risky. Users who are
> not administrators can't even reasonably use gnuplot on Windows anymore.
> (I don't think expecting them to compile it from source, with all the
> dependencies, is reasonable.)
> 
> Can we bring the zip file back, at least as an additional download option,
> please?
> 
> 
> 
> 

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> 
> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> >>
> >> - On one of my machines, startup appeared to be extremely slow, taking
> >> about 5 minutes (!). This is true for both the console and GUI versions.
> >> For the first few tries I've actually killed the process, because I
> >> didn't have the patience to wait it out. Once it started, it appeared to
> >> work normally, there were no delays and plotting was instantaneous as
> >> well. (Older versions had a long delay at the first plot because of
> >> fontconfig or whatever.)
> >> This happened in both interactive and non-interactive mode, however,
> >> only on a virtual machine running Vista. On a real computer running
> >> Windows 7, startup was instantaneous.
> >
> > I seem to recall this was discussed a couple of years ago.
> > The issue then was that if the program did not find a certain set of fonts,
> > it triggered creation of a bitmap font set from the underlying font
> > descriptions.  This was painfully slow but only  happened the first time,
> > since subsequent runs would find the  now-created font set.
> > However, I wonder if you run under a virtual machine whether every time
> > is a "first" time?  Anyhow, my best guess is that this is a font issue
> > rather than anything to do with gnuplot per se.
> >
> > 	Ethan
> >
> 
> The cairo terminals no longer use the fontconfig mechanism of Windows, 
> so this particular issue should have been solved.
> On the other hand I vaguely remember a similar report a while ago, but I 
> couldn't reproduce on various XP, Vista and 7 machines.
> 

On further testing I've noticed that there *is* a slight delay on
startup even on the Win7 machine (4-5 seconds). This means that even
something like 'gnuplot -e "print 1"' takes this much time.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

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

Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
>>
>> - On one of my machines, startup appeared to be extremely slow, taking
>> about 5 minutes (!). This is true for both the console and GUI versions.
>> For the first few tries I've actually killed the process, because I
>> didn't have the patience to wait it out. Once it started, it appeared to
>> work normally, there were no delays and plotting was instantaneous as
>> well. (Older versions had a long delay at the first plot because of
>> fontconfig or whatever.)
>> This happened in both interactive and non-interactive mode, however,
>> only on a virtual machine running Vista. On a real computer running
>> Windows 7, startup was instantaneous.
>
> I seem to recall this was discussed a couple of years ago.
> The issue then was that if the program did not find a certain set of fonts,
> it triggered creation of a bitmap font set from the underlying font
> descriptions.  This was painfully slow but only  happened the first time,
> since subsequent runs would find the  now-created font set.
> However, I wonder if you run under a virtual machine whether every time
> is a "first" time?  Anyhow, my best guess is that this is a font issue
> rather than anything to do with gnuplot per se.
>
> 	Ethan
>

The cairo terminals no longer use the fontconfig mechanism of Windows, 
so this particular issue should have been solved.
On the other hand I vaguely remember a similar report a while ago, but I 
couldn't reproduce on various XP, Vista and 7 machines.

   Bastian

>> I have no idea what causes this, and why it appears on one machine but
>> doesn't on the other. Have any of you experienced anything similar?
>> I think this issue is potentially serious, because those who meet with
>> it unsuspectingly may end up thinking that gnuplot is completely useless
>> - "I've clicked on the icon", they would say, "but nothing happened!"
>>
>> - The reworked windows terminal is awesome! To everyone who contributed
>> to it: good work! I miss the "previous zoom" button from the wxt
>> terminal, though.
>>
>> Péter Juhász
>>

Re: Observations on the 4.6rc1 windows package

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

On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> 
> - On one of my machines, startup appeared to be extremely slow, taking
> about 5 minutes (!). This is true for both the console and GUI versions.
> For the first few tries I've actually killed the process, because I
> didn't have the patience to wait it out. Once it started, it appeared to
> work normally, there were no delays and plotting was instantaneous as
> well. (Older versions had a long delay at the first plot because of
> fontconfig or whatever.)
> This happened in both interactive and non-interactive mode, however,
> only on a virtual machine running Vista. On a real computer running
> Windows 7, startup was instantaneous.

I seem to recall this was discussed a couple of years ago.
The issue then was that if the program did not find a certain set of fonts, 
it triggered creation of a bitmap font set from the underlying font
descriptions.  This was painfully slow but only  happened the first time, 
since subsequent runs would find the  now-created font set.  
However, I wonder if you run under a virtual machine whether every time 
is a "first" time?  Anyhow, my best guess is that this is a font issue
rather than anything to do with gnuplot per se.

	Ethan

> I have no idea what causes this, and why it appears on one machine but
> doesn't on the other. Have any of you experienced anything similar?
> I think this issue is potentially serious, because those who meet with
> it unsuspectingly may end up thinking that gnuplot is completely useless
> - "I've clicked on the icon", they would say, "but nothing happened!"
> 
> - The reworked windows terminal is awesome! To everyone who contributed
> to it: good work! I miss the "previous zoom" button from the wxt
> terminal, though.
> 
> Péter Juhász
> 

Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

Dear gnuplot-beta list members,

I had to do some work with gnuplot on a windows machine, and I've have
some comments on the windows version of 4.6rc1.

- I agree with the previous discussion that the old style zip package
has to be provided as an alternative, but overall I think it's good that
we finally have an installer. For the majority of windows users, this is
what makes sense, while they are unfamiliar with zip packages.

- The installer opens the windows-specific readme file at the end of the
installation, however, the file appears garbled in Notepad because the
line endings are \n instead of \r\n which is usual on windows. Most
editors can handle this but Notepad (at least on Vista) can't.

- On one of my machines, startup appeared to be extremely slow, taking
about 5 minutes (!). This is true for both the console and GUI versions.
For the first few tries I've actually killed the process, because I
didn't have the patience to wait it out. Once it started, it appeared to
work normally, there were no delays and plotting was instantaneous as
well. (Older versions had a long delay at the first plot because of
fontconfig or whatever.)
This happened in both interactive and non-interactive mode, however,
only on a virtual machine running Vista. On a real computer running
Windows 7, startup was instantaneous.
I have no idea what causes this, and why it appears on one machine but
doesn't on the other. Have any of you experienced anything similar?
I think this issue is potentially serious, because those who meet with
it unsuspectingly may end up thinking that gnuplot is completely useless
- "I've clicked on the icon", they would say, "but nothing happened!"

- The reworked windows terminal is awesome! To everyone who contributed
to it: good work! I miss the "previous zoom" button from the wxt
terminal, though.

Péter Juhász

Re: No more zip file for 4.6?

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

Hello

I have prepared zip style distribution.

http://www.tatsuromatsuoka.com/gnuplot/Eng/gp46/

Regards

Tatsuro

--- On Fri, 2012/2/17, Tatsuro MATSUOKA > wrote:

> Hello
> 
> Sorry I have written the previous post without understanding what you would like to say.
> 
> I can prepare zip style distribution. Is it required for 4.6-rc1?
> If so, I will prepare it and upload to the my web site.
> 
> For the 4.6.0 release, I will also prepare zip style binary.
> 
> Regards
> 
> Tatsuro
> 
> --- On Fri, 2012/2/17, Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > gp46rc1-win32-setup.exe is an installer. You can install gnuplot to any directory in which you would like to place gnuplot.
> > 
> > BTW, there are need to old zip style distribution, it could be additional distribution style.
> > I would like to also prepare zip style distribution for Windows binary.
> > 
> > Regards
> > 
> > Tatsuro 
> > 
> > 
> > --- On Fri, 2012/2/17, Tait wrote:
> > 
> > > 
> > > I went to try out 4.6rc today, but the only binary file available is a
> > > *.exe. What happened to the *.zip file (which I prefer)?
> > > 
> > > Downloading an executable means the user must run it blindly. A zip file
> > > has the advantage that it is data, not an executable. A trusted unzip
> > > program can interpret and open the zip file, at least giving the user the
> > > chance to inspect the contents before executing code. For a program like
> > > gnuplot that doesn't actually need to execute code to install, this is
> > > unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
> > > provide any chance for verification, and given SourceForge compromises
> > > in the past, this makes me uncomfortable.
> > > 
> > > Second, the executable can't even be used unless the user is (logged in
> > > as) an administrator, which is also unnecessary and risky. Users who are
> > > not administrators can't even reasonably use gnuplot on Windows anymore.
> > > (I don't think expecting them to compile it from source, with all the
> > > dependencies, is reasonable.)
> > > 
> > > Can we bring the zip file back, at least as an additional download option,
> > > please?
> > > 
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Virtualization & Cloud Management Using Capacity Planning
> > > Cloud computing makes use of virtualization - but cloud computing 
> > > also focuses on allowing computing to be delivered as a service.
> > > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > 
> > 
> > ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing 
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: No more zip file for 4.6?

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

Hello

Sorry I have written the previous post without understanding what you would like to say.

I can prepare zip style distribution. Is it required for 4.6-rc1?
If so, I will prepare it and upload to the my web site.

For the 4.6.0 release, I will also prepare zip style binary.

Regards

Tatsuro

--- On Fri, 2012/2/17, Tatsuro MATSUOKA  wrote:

> Hello
> 
> gp46rc1-win32-setup.exe is an installer. You can install gnuplot to any directory in which you would like to place gnuplot.
> 
> BTW, there are need to old zip style distribution, it could be additional distribution style.
> I would like to also prepare zip style distribution for Windows binary.
> 
> Regards
> 
> Tatsuro 
> 
> 
> --- On Fri, 2012/2/17, Tait wrote:
> 
> > 
> > I went to try out 4.6rc today, but the only binary file available is a
> > *.exe. What happened to the *.zip file (which I prefer)?
> > 
> > Downloading an executable means the user must run it blindly. A zip file
> > has the advantage that it is data, not an executable. A trusted unzip
> > program can interpret and open the zip file, at least giving the user the
> > chance to inspect the contents before executing code. For a program like
> > gnuplot that doesn't actually need to execute code to install, this is
> > unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
> > provide any chance for verification, and given SourceForge compromises
> > in the past, this makes me uncomfortable.
> > 
> > Second, the executable can't even be used unless the user is (logged in
> > as) an administrator, which is also unnecessary and risky. Users who are
> > not administrators can't even reasonably use gnuplot on Windows anymore.
> > (I don't think expecting them to compile it from source, with all the
> > dependencies, is reasonable.)
> > 
> > Can we bring the zip file back, at least as an additional download option,
> > please?
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing 
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: No more zip file for 4.6?

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

Hello

gp46rc1-win32-setup.exe is an installer. You can install gnuplot to any directory in which you would like to place gnuplot.

BTW, there are need to old zip style distribution, it could be additional distribution style.
I would like to also prepare zip style distribution for Windows binary.

Regards

Tatsuro 


--- On Fri, 2012/2/17, Tait wrote:

> 
> I went to try out 4.6rc today, but the only binary file available is a
> *.exe. What happened to the *.zip file (which I prefer)?
> 
> Downloading an executable means the user must run it blindly. A zip file
> has the advantage that it is data, not an executable. A trusted unzip
> program can interpret and open the zip file, at least giving the user the
> chance to inspect the contents before executing code. For a program like
> gnuplot that doesn't actually need to execute code to install, this is
> unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
> provide any chance for verification, and given SourceForge compromises
> in the past, this makes me uncomfortable.
> 
> Second, the executable can't even be used unless the user is (logged in
> as) an administrator, which is also unnecessary and risky. Users who are
> not administrators can't even reasonably use gnuplot on Windows anymore.
> (I don't think expecting them to compile it from source, with all the
> dependencies, is reasonable.)
> 
> Can we bring the zip file back, at least as an additional download option,
> please?
> 
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

No more zip file for 4.6?

[Tait <gnu...@t4...>]

I went to try out 4.6rc today, but the only binary file available is a
*.exe. What happened to the *.zip file (which I prefer)?

Downloading an executable means the user must run it blindly. A zip file
has the advantage that it is data, not an executable. A trusted unzip
program can interpret and open the zip file, at least giving the user the
chance to inspect the contents before executing code. For a program like
gnuplot that doesn't actually need to execute code to install, this is
unnecessary. I know "nobody" verifies MD5/SHA/signatures, but we don't
provide any chance for verification, and given SourceForge compromises
in the past, this makes me uncomfortable.

Second, the executable can't even be used unless the user is (logged in
as) an administrator, which is also unnecessary and risky. Users who are
not administrators can't even reasonably use gnuplot on Windows anymore.
(I don't think expecting them to compile it from source, with all the
dependencies, is reasonable.)

Can we bring the zip file back, at least as an additional download option,
please?

Re: mouse coord read-out in wxt multiplot

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

On Saturday, 11 February 2012, Petr Mikulik wrote:

> BTW, the 2nd paragraph in "help mouse" says that mousing is not available in 
> multiplot. Do you think a similar message should be added to "help 
> multiplot"?

No mouse _during_ multiplot is fine.

The problem comes when you exit multiplot.
Now the screen display still shows the multiplot panels,
but mousing is re-enabled and if you try to use it then
it destroys the current display.

Maybe it would be better if we didn't re-enable mousing until
the next plot command?

	Ethan

Re: mouse coord read-out in wxt multiplot

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

> > All of this has been true for gnuplot terminals since approximately forever.
> > "replot" can only reproduce the immediately prior plot command.
> > It can't dive back into history and re-execute earlier plots in
> > the session.
> 
> Would be nice if it could ;) The history is there ...
> 
> Would rerunning everything in history since multiplot last became active 
> make sense?
> 
> "multireplot" if it needs to be functionally separte.

The only way how to achieve such a functionality is by doing "save" into a 
temporary file just after each plot. multireplot would have to load each 
file (and hope the original data are still available). There is no single 
structure keeping the complete gnuplot session, so a file is necessary.

Actually, multireplot is not necessary as you can use "set term xxx n" 
instead and enjoy mousing in the nth window.

BTW, the 2nd paragraph in "help mouse" says that mousing is not available in 
multiplot. Do you think a similar message should be added to "help 
multiplot"?

---
PM

Re: mouse coord read-out in wxt multiplot

[<pl...@pi...>]

On 02/11/12 00:09, Ethan A Merritt wrote:
>> There's perhaps more to this wxt+multiplot situation than the problems I
>> indicated.
>>
>> Now using a CVS pull of today ( 10th Feb 2011).
>>
>>
>> If I do a mouse scroll in any area of a multiplot, the multplot vanishes
>> and is replaced by a full window version of the last plot. If it does
>> anything restricted to one plot,  it should perhaps scroll the last plot
>> within the multiplot. Binning the multiplot altogether is a pretty nasty
>> bug.
>
> All of this has been true for gnuplot terminals since approximately forever.
> "replot" can only reproduce the immediately prior plot command.
> It can't dive back into history and re-execute earlier plots in
> the session.

Would be nice if it could ;) The history is there ...

Would rerunning everything in history since multiplot last became active 
make sense?

"multireplot" if it needs to be functionally separte.


Incidentally if this could work it would remove the "you can't change 
terminal when multiplot is active" restriction.  Being able to do:  set 
terminal png ; set output ... ; replot;  like I do in single plot would 
be good.

I currently have to have lots of if's and else's , flip a do_png 
variable and reload the script.

>
> So if you do a "replot" after a multiplot, it can only redraw
> the most recent subpanel.
>
> While I certainly understand the desire to re-create the entire set
> of panels that make up the multiplot, it takes more than a "replot"
> command to get there.

Sure, there could be all sorts of changed settings in between each plot 
command. The aim is to have something sane happen if I do something like 
a one increment on the mouse wheel instead of blowing out the whole 
multiplot and needing to rerun the script.

Your explanations may help fix it up a bit. Thanks.

>
>> Worse, if I close the wxt window and run the gnuplot script again using
>> load command I get the multiplot format but with axes, xrange and yrange
>> stolen from the earlier last plot in the series.  The auto scaling
>> feature that was working correctly before is now disabled and the
>> scaling suitable for the last plot is applied to all.
>
> Exiting multiplot does not reset or otherwise change the axis scaling.
> In that way it's just like any other plot.  So unless you do a "reset" or
> "set auto" before re-executing the script, you won't be starting from a
> clean slate.

I think what I was missing is that I did not realise the mouse scroll 
would turn off auto-scaling. Since it has to set a specific yrange I 
suppose that makes sense. Thanks.

>
>> I am able to restore sanity by  set yr [*:*] .
>
> Right. That's equivalent to "set auto"
>
>> Clearly this is a bug.
>
> Not really.  Unless you do a "reset", all the current settings will
> influence the script you load.  That's true regardless of multiplot.

Not quite true, a zoom will be lost. That's probably what led me to a 
false expectation that the scrolled window would be reset as well.

I agree this is not a bug, just my mistaken expectation.

>
> FWIW I don't see exactly the same behaviour that you describe for wxt.
> When I use mouse scrolling after a multiplot it blanks the screen and
> redraws only the most recent panel, in the same size it was before.
> It does not go to full-screen as you describe.  I suppose this might
> depend on exactly what size/origin commands were used in the multiplot.

Ah, that maybe a clue. I just specified the layout and let automatic 
placement to the rest.  It looks like explicitly setting origin etc. may 
preserve plot size and position.

> Anyhow, I wonder if it's possible to skip the screen-blank step,
> leaving all the other panels untouched while the most recent one is updated?
> But it might be tricky to figure out automatically when that is or isn't
> the best thing to do.
>


>
>> If I click the autoscale button in the wxt toolbar, it also jumps to
>> last plot full size display of the last plot element but does not mess
>> up the autoscaling if I reload the gnuplot script.
>
> In truth I have never figured out how that button is intended to work :-)
>
> 	Ethan
>

Peter.

Re: mouse coord read-out in wxt multiplot

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

> There's perhaps more to this wxt+multiplot situation than the problems I 
> indicated.
> 
> Now using a CVS pull of today ( 10th Feb 2011).
> 
> 
> If I do a mouse scroll in any area of a multiplot, the multplot vanishes 
> and is replaced by a full window version of the last plot. If it does 
> anything restricted to one plot,  it should perhaps scroll the last plot 
> within the multiplot. Binning the multiplot altogether is a pretty nasty 
> bug.

All of this has been true for gnuplot terminals since approximately forever.
"replot" can only reproduce the immediately prior plot command.
It can't dive back into history and re-execute earlier plots in
the session.  

So if you do a "replot" after a multiplot, it can only redraw 
the most recent subpanel.

While I certainly understand the desire to re-create the entire set
of panels that make up the multiplot, it takes more than a "replot"
command to get there.

> Worse, if I close the wxt window and run the gnuplot script again using 
> load command I get the multiplot format but with axes, xrange and yrange 
> stolen from the earlier last plot in the series.  The auto scaling 
> feature that was working correctly before is now disabled and the 
> scaling suitable for the last plot is applied to all.

Exiting multiplot does not reset or otherwise change the axis scaling.  
In that way it's just like any other plot.  So unless you do a "reset" or 
"set auto" before re-executing the script, you won't be starting from a 
clean slate.

> I am able to restore sanity by  set yr [*:*] .

Right. That's equivalent to "set auto"

> Clearly this is a bug.

Not really.  Unless you do a "reset", all the current settings will
influence the script you load.  That's true regardless of multiplot.

FWIW I don't see exactly the same behaviour that you describe for wxt.
When I use mouse scrolling after a multiplot it blanks the screen and
redraws only the most recent panel, in the same size it was before.
It does not go to full-screen as you describe.  I suppose this might
depend on exactly what size/origin commands were used in the multiplot.
Anyhow, I wonder if it's possible to skip the screen-blank step, 
leaving all the other panels untouched while the most recent one is updated?
But it might be tricky to figure out automatically when that is or isn't 
the best thing to do.


> If I click the autoscale button in the wxt toolbar, it also jumps to 
> last plot full size display of the last plot element but does not mess 
> up the autoscaling if I reload the gnuplot script.

In truth I have never figured out how that button is intended to work :-)

	Ethan

Re: mouse coord read-out in wxt multiplot

[<pl...@pi...>]

On 02/09/12 19:15, Ethan A Merritt wrote:
> On Thursday, February 09, 2012 09:22:50 am pl...@pi... wrote:
>> On 02/09/12 15:45, pl...@pi... wrote:
>>> Hi,
>>>
>>> quick one.
>>>
>>> coordinate readout in wxt multiplot is on "whole window" coord. system,
>>> centred at screen centre.
>>>
>>> This seems rather unhelpful since it does not relate to ANY of the
>>> plots' axes.
>>>
>>> Wouldn't this be a more useful feature if it translated mouse to 'local'
>>> axes of the hovered plot.
>
> This is a very long-standing Feature Request.
>
> The nature of the problem is that the generic mousing code uses internal
> variables that are only correct for the "current" plot (actually the
> plot that was just completed).  Since these variables are overwritten with
> each new plot in a multiplot, the information is not available except for
> the most recent subpanel.
>
> Relatively recently we added terminal-specific code to dump plot layout
> information so that mousing could be done by terminals like svg and canvas
> where the information was necessarily stored in the output file itself.
> As each plot is completed, the summary variables (essentially the ones
> reported in GPVAL_TERM_XXX) are written into a data structure.
>
> That provides a template for how we might do the same for the interactive
> terminals.  I think it would have to be tackled one terminal at a time,
> but it sounds like a relatively straightforward programming task.
> If anyone is looking for a project .... :-)
>
> 	Ethan
>


There's perhaps more to this wxt+multiplot situation than the problems I 
indicated.

Now using a CVS pull of today ( 10th Feb 2011).


If I do a mouse scroll in any area of a multiplot, the multplot vanishes 
and is replaced by a full window version of the last plot. If it does 
anything restricted to one plot,  it should perhaps scroll the last plot 
within the multiplot. Binning the multiplot altogether is a pretty nasty 
bug.

Worse, if I close the wxt window and run the gnuplot script again using 
load command I get the multiplot format but with axes, xrange and yrange 
stolen from the earlier last plot in the series.  The auto scaling 
feature that was working correctly before is now disabled and the 
scaling suitable for the last plot is applied to all.

I am able to restore sanity by  set yr [*:*] .

Clearly this is a bug.

If I click the autoscale button in the wxt toolbar, it also jumps to 
last plot full size display of the last plot element but does not mess 
up the autoscaling if I reload the gnuplot script.


Peter.

Re: more oddities on wxt multiplot and legend toggle

[<pl...@pi...>]

On 02/09/12 18:35, Ethan A Merritt wrote:
> To the best of my knowledge, this was fixed by the following ChangeLog
> entry:
>
> 2011-12-10  Ethan A Merritt<merritt@u.washington.edu>
>          * src/term.c src/wxterminal/wxt_gui.cpp term/svg.trm:
>          Allow toggling individual plots on/off inside a multiplot page.
>          Bugfix.

Correct.

I decided to update since all this was starting to get in the way.

The legend toggle silliness was fixed as you indicate.

thanks.

Peter.

simplifying CVS instructions

[<pl...@pi...>]

Hi,


I just looked at the CVS instructions at :
http://www.gnuplot.info/development/index.html

 >>
   export 
CVSROOT=:pserver:ano...@gn...:/cvsroot/gnuplot
   cvs login
   cvs -z3 checkout gnuplot

Note: hit Enter when asked for a password.
 >>

Changing the login command line to :

echo > cvs login

makes the login automatic and removes the need for instructions about 
"hitting enter" .

This  makes it a simply cut and paste operation that could equally be 
used as a script.

regards, Peter.