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

Re: stat: standard deviation

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

On 08/30/14 02:10, Allin Cottrell wrote:
> It woud be sufficient either to state in the documentation that
> gnuplot gives the MLE or to switch to the sample standard deviation.
> I don't see much to be said for more complicated options.
>
> Allin Cottrell


This should be clearly stated up front without the need for digging the doc.

If gnuplot is calculating the "sample standard deviation" ( which would 
seem to be the most appropriate when given a sample of data ) then that 
is what it should label it as when outputting the result, rather than 
just 'std dev'.  The note about degrees of freedom assumption could go 
in the doc.

Uneducated used of these kind of statistics is pretty common, perhaps 
more so in population that are going to depend on a plotting program to 
provide them, rather than having existing knowledge and software to 
provide the stats.  It would be good to be as clear as possible about 
what is being output with an assumption that user probably has little 
knowledge of the subject.

A link to some starting point to further understanding as a note in help 
may be valuable.

Peter.

Re: stat: standard deviation

[Allin C. <cot...@wf...>]

On Sat, 30 Aug 2014, Petr Mikulik wrote:

> In gnuplot, the "stat" command calculates "Std Dev:" and "STATS_stddev_x" as
>     sqrt( SumOfSquares / n )

That's the maximum likelihood estimator (MLE) of the population 
standard deviation. It happens to be biased, although it's 
consistent (converges in probability on the population standard 
deviation in large samples).

> In GNU R, OpenOffice et al, the function stddev() calculates
>     sqrt( SumOfSquares / (n-1) )

That's the "sample standard deviation", an unbiased estimator of the 
population standard deviation if the relevant degrees of freedom are 
indeed n - 1.

> while function stddevp() returns
>     sqrt( SumOfSquares / n )
>
> That's confusing. Why has gnuplot chosen the other possibility (this smaller
> stddev estimate means that the average value of the statistical ensemble
> is known).
>
> What to do with that?

If what you're saying is correct as a description of what gnuplot 
does then it's arguably idiosyncratic of gnuplot to give the MLE 
when most statistical software gives the sample standard deviation.

It woud be sufficient either to state in the documentation that 
gnuplot gives the MLE or to switch to the sample standard deviation. 
I don't see much to be said for more complicated options.

Allin Cottrell

stat: standard deviation

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

In gnuplot, the "stat" command calculates "Std Dev:" and "STATS_stddev_x" as
     sqrt( SumOfSquares / n )

In GNU R, OpenOffice et al, the function stddev() calculates
     sqrt( SumOfSquares / (n-1) )
while function stddevp() returns
     sqrt( SumOfSquares / n )

That's confusing. Why has gnuplot chosen the other possibility (this smaller
stddev estimate means that the average value of the statistical ensemble
is known).

What to do with that?

- It would be nice if gnuplot gets compatible and has both
   "Std Dev:" and "STATS_stddev_x" and "Std Dev P:" and "STATS_stddevp_x".
   But then scripts running on different gnuplot versions would give
   different results :-(

- Let gnuplot write both variants of stddev so that the user sees which
   values is which type of stddev (one is smaller and the other is larger). The
   other could be called "Std Dev (n-1):" and "STATS_stddev1_x".

- Document stddev used in gnuplot by writing its formula in the help.

- I would also like if gnuplot writes the deviation of the mean
   as used in (mean +- err)  where err=sqrt(SumOfSquares/(n*(n-1))).
   How to call this value?

Well, I figured this out when preparing some hints for students...

---
Petr Mikulik

Re: preparation for 5.0rc2 windows and cygwin binary

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

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: Merritt Ethan 
> Cc: 
> Date: 2014/8/29, Fri 17:12
> Subject: Re: preparation for 5.0rc2 windows and cygwin binary
> 
> ----- Original Message -----
>> From: sfeam 
>> To: Tatsuro MATSUOKA  
>> Date: 2014/8/29, Fri 05:45
>> Subject: Re: preparation for 5.0rc2 windows and cygwin binary
>> 
>> 
>> 
>> On Wednesday, 27 August 2014 03:15:54 PM you wrote:
>>>  Today I checked out the branch-5-0-stable source.
>>>  I confirmed it was able to be built on native windows (mingw) and the 
> cygwin.
>>>  (Both 32 and 64 bit binaries were built.)
>>> 
>>>  If the official 5.0rc2 source will be uploaded, 
>>>  I will be able to make binaries for windows and cygwin 
>>>  and upload those on my web.
>>  
>> Tatsuro,
>>  
>> Today I have uploaded source for the 5.0.rc2 to SourceForge.
>> https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.rc2/
>>  
>> Please let me know when you have prepared windows binaries
>> so that I can copy them to SourceForge also.
>>  
>> thanks,
>>  
>> Ethan
> 
> I have uploaded the windows and cygwin binaries of gnuplot 5.0rc2 on:
> http://www.tatsuromatsuoka.com/gnuplot/Eng/gp50rc2/
> 
> 
> The upload site I am using does not allow to place files name of which ends 
> ".exe".
> Therefore the installer exe files are zipped and named "....exe.zip".
> At uploading SourceForge site, please extract them before uploading.


I confirmed that binaries were uploaded on SourceForge site.

Thanks!

preparation for 5.0rc2 windows and cygwin binary

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

Today I checked out the branch-5-0-stable source.
I confirmed it was able to be built on native windows (mingw) and the cygwin.
(Both 32 and 64 bit binaries were built.)

If the official 5.0rc2 source will be uploaded, 
I will be able to make binaries for windows and cygwin 
and upload those on my web.

Tatsuro

Re: 18-August-2014 Update on version 5 progress

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

----- Original Message -----

> From: sfeam 
> To: gnu...@li...
> Cc: Pieter-Tjerk de Boer 
> Date: 2014/8/23, Sat 00:18
> Subject: Re: 18-August-2014 Update on version 5 progress
> 
> On Friday, 22 August 2014 12:03:45 PM Pieter-Tjerk de Boer wrote:
>> 
>>  Back in June this year, there was some discussion about the fit command,
>>  and in a mail to this list on June 15, I provided a patch to resolve
>>  some issues with it.
>>  I don't see 'fit' mentioned here either as a change or as an 
> unresolved
>>  issue, so I guess this was overlooked?
> 
> Patches sent to the mailing list tend to get lost.  Please upload
> it to the Patches section of the web site:
> 
>   https://sourceforge.net/p/gnuplot/patches/
> 
> I discovered yesterday that the new fit keyword "errors" does not
> work. I don't suppose your patch happens to fix that?
> 
> Also there is no documentation for that keyword or the other new
> error-related keywords.  So indeed there are some issues remaining with
> fit that will hopefully be fixed during -rc2 testing and before the final
> release of version 5.  
> 
>     Ethan
> 
> 
>> 
>>  Regards,
>>    Pieter-Tjerk
>> 
>> 
>>  On Mon, Aug 18, 2014 at 11:56:33AM -0700, Ethan A Merritt wrote:
>>  > I plan to package a second release candidate for gnuplot version 5
>>  > next weekend, unless of course someone points out an important
>>  > bug or mis-feature in the currect CVS source that is easily fixable.
>>  > 
>>  > The plan is to create a new version 5.0 branch of the CVS source tree.
>>  > It will initially hold 5.0-rc2 and will essentially freeze the source 
> for 5.0
>>  > except for bug fixes turned up by testing of -rc2.
>>  > Development will continue in the main CVS tree, which will be labeled
>>  > 5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
>>  > New features added to 5.1 may not appear in the final release package
>>  > for 5.0.
>>  > 
>>  > Thanks to everyone who test the first release candidate and reported
>>  > problems or suggestions for improvement. Many of the issues identified
>>  > were immediately fixable and hopefully have been resolved in the
>>  > upcoming -rc2 release. 
>>  > 
>>  > None of this will affect the planned release of 4.6.6 in 
> September/October,
>>  > which will probably be the last release in the 4.6 series.
>>  > 
>>  > Changes between 5.0 -rc1 and -rc2
>>  > =============================
>>  > 
>>  > * NEW grey out key entries when corresponding plot is toggled off
>>  > * NEW allow parenthesized expressions as call parameters
>>  > * NEW command "set margins <left>, <right>, 
> <top>, <bottom>"
>>  > * NEW command "set trange [theta_min:theta_max] filters polar 
> mode input data
>>  > * NEW command "set mouse zoomfactors 
> <xfact>,<yfact>"
>>  > * NEW matrix keywords for text data: "columnheaders" and 
> "rowheaders"
>>  > * CHANGE apply "set key {no}enhanced}" to the key title
>>  > * CHANGE scale dashlength with line width (not yet done for all 
> terminals)
>>  > * CHANGE apply default rectangle style during "set obj" 
> rather than when drawn
>>  > * FIX width adjustment for long key title in multicolumn keys
>>  > * FIX treat data value read as "NaN" the same as we would 
> "1/0"
>>  > * FIX pointtype PT_CHARACTER in 3D plots
>>  > * FIX do not store long strings (e.g. epslatex_header) in terminal 
> options
>>  > * FIX extra resize of initial qt window may fix problems on OSX, 
> Debian
>>  > * FIX handling of events triggered by closing the qt plot window
>>  > * FIX refresh of plot with log-scaled color box
>>  > * FIX MSWin pipe issues
>>  > * FIX if terminal is in "monochrome" mode, convert color 
> requests to black
>>  > * FIX various bugs related to the new dashtype code (there are surely 
> more!)
>>  > 
>>  > 
>>  > Unresolved issues
>>  > =================
>>  > 
>>  > - The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
>>  >   No fix is known and so far as I know no one is working on it.
>>  >   The problem is made worse for Debian/Ubuntu users because Debian
>>  >   plans to drop support for wxWidgets 2.8.
>>  > 
>>  > - Initialization and resizing of the qt terminal may still have
>>  >   problems on OSX (and other platforms?).
>>  > 
>>  > - The lua terminal does not accepts ARGB color specifiers
>>  >   (alpha is ignored).
>>  > 
>>  > - There is general agreement that the "dashlength" property 
> of
>>  >   dashed lines should scale with the linewidth.  Not all terminals
>>  >   have yet been modified to act this way. 
>>  > 
>>  > - Version 5 terminals default to enhanced text mode.  This change
>>  >   broke some scripts.  While "set termoption noenhanced" 
> restores the
>>  >   Version 4 default, this command is not persistent.  I.e. it is lost
>>  >   whenever you do another "set term" command.  Should there 
> be
>>  >   a new command like "set {no}enhanced" that would apply for 
> an
>>  >   entire gnuplot session?  Maybe it could offer finer control:
>>  >     set {no}enhanced {titles} {tics} {labels} {key}
>>  > 
>>  > - A similar issue exists for terminals with a "monochrome" 
> mode.
>>  >   Should there be a global "set monochrome {some options}" 
> command?
>>  >   Would this clobber all current linetype definitions, or would 
>>  >   there be a separate parallel set of monochrome linetypes, or what?
>>  > 
>>  > - The <space> (raise console) and <q> (close plot window) 
> hot keys
>>  >   do not work consistently for different terminal types.  It would
>>  >   be preferable to move this functionality into the core mouse.c
>>  >   code and get rid of the special-case code in the individual 
>>  >   terminal drivers.  This is not a release-blocker, however, and may
>>  >   have to wait until after the final version 5.0 release.
>>  > 
>>  >         Ethan Merritt (sf...@us...)
>>  > 
>>  > 



The patch was attached at this thread:
http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18519



Tatsuro

Re: version.c still points to 5.0 rc1.

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

----- Original Message -----

> From: sfeam 
> To: gnu...@li...; Tatsuro MATSUOKA 
> Date: 2014/8/23, Sat 00:03
> Subject: Re: version.c still points to 5.0 rc1.
> 
> On Friday, 22 August 2014 03:01:57 PM Tatsuro MATSUOKA wrote:
>>  Hello
>> 
>>  I have check out the cvs source and found the cvs version is now updated to 
> 5.1.
>> 
>>  However, the version pointed in version.c in 5.1 branch still points 5.0 
> rc1.
>> 
>>  42: const char gnuplot_version[] = "5.0";
>>  43: const char gnuplot_patchlevel[] = "rc1";
>> 
>>  Please correct it.
> 
> These are supposed to be replaced by the contents of VERSION and PATCHLEVEL
> by the build procedure.  But OK, it should be changed in version.c for
> consistency.


The reason that I have noticed that version.c is not changed is that version +
patch level that is represented in the startup screen is 5.0rc-1.

In MinGW build, the version number and patch level are reflected to the file name
of installer and zip file.

In Cygwin build, the version number is reflected to the install directory name.

The above example that I have noticed.

Tatsuro 

Re: 18-August-2014 Update on version 5 progress

[sfeam <sf...@us...>]

On Friday, 22 August 2014 12:03:45 PM Pieter-Tjerk de Boer wrote:
> 
> Back in June this year, there was some discussion about the fit command,
> and in a mail to this list on June 15, I provided a patch to resolve
> some issues with it.
> I don't see 'fit' mentioned here either as a change or as an unresolved
> issue, so I guess this was overlooked?

Patches sent to the mailing list tend to get lost.  Please upload
it to the Patches section of the web site:

   https://sourceforge.net/p/gnuplot/patches/

I discovered yesterday that the new fit keyword "errors" does not
work. I don't suppose your patch happens to fix that?

Also there is no documentation for that keyword or the other new
error-related keywords.  So indeed there are some issues remaining with
fit that will hopefully be fixed during -rc2 testing and before the final
release of version 5.  

	Ethan


> 
> Regards,
>   Pieter-Tjerk
> 
> 
> On Mon, Aug 18, 2014 at 11:56:33AM -0700, Ethan A Merritt wrote:
> > I plan to package a second release candidate for gnuplot version 5
> > next weekend, unless of course someone points out an important
> > bug or mis-feature in the currect CVS source that is easily fixable.
> > 
> > The plan is to create a new version 5.0 branch of the CVS source tree.
> > It will initially hold 5.0-rc2 and will essentially freeze the source for 5.0
> > except for bug fixes turned up by testing of -rc2.
> > Development will continue in the main CVS tree, which will be labeled
> > 5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
> > New features added to 5.1 may not appear in the final release package
> > for 5.0.
> > 
> > Thanks to everyone who test the first release candidate and reported
> > problems or suggestions for improvement. Many of the issues identified
> > were immediately fixable and hopefully have been resolved in the
> > upcoming -rc2 release. 
> > 
> > None of this will affect the planned release of 4.6.6 in September/October,
> > which will probably be the last release in the 4.6 series.
> > 
> > Changes between 5.0 -rc1 and -rc2
> > =============================
> > 
> > * NEW grey out key entries when corresponding plot is toggled off
> > * NEW allow parenthesized expressions as call parameters
> > * NEW command "set margins <left>, <right>, <top>, <bottom>"
> > * NEW command "set trange [theta_min:theta_max] filters polar mode input data
> > * NEW command "set mouse zoomfactors <xfact>,<yfact>"
> > * NEW matrix keywords for text data: "columnheaders" and "rowheaders"
> > * CHANGE apply "set key {no}enhanced}" to the key title
> > * CHANGE scale dashlength with line width (not yet done for all terminals)
> > * CHANGE apply default rectangle style during "set obj" rather than when drawn
> > * FIX width adjustment for long key title in multicolumn keys
> > * FIX treat data value read as "NaN" the same as we would "1/0"
> > * FIX pointtype PT_CHARACTER in 3D plots
> > * FIX do not store long strings (e.g. epslatex_header) in terminal options
> > * FIX extra resize of initial qt window may fix problems on OSX, Debian
> > * FIX handling of events triggered by closing the qt plot window
> > * FIX refresh of plot with log-scaled color box
> > * FIX MSWin pipe issues
> > * FIX if terminal is in "monochrome" mode, convert color requests to black
> > * FIX various bugs related to the new dashtype code (there are surely more!)
> > 
> > 
> > Unresolved issues
> > =================
> > 
> > - The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
> >   No fix is known and so far as I know no one is working on it.
> >   The problem is made worse for Debian/Ubuntu users because Debian
> >   plans to drop support for wxWidgets 2.8.
> > 
> > - Initialization and resizing of the qt terminal may still have
> >   problems on OSX (and other platforms?).
> > 
> > - The lua terminal does not accepts ARGB color specifiers
> >   (alpha is ignored).
> > 
> > - There is general agreement that the "dashlength" property of
> >   dashed lines should scale with the linewidth.  Not all terminals
> >   have yet been modified to act this way. 
> > 
> > - Version 5 terminals default to enhanced text mode.  This change
> >   broke some scripts.  While "set termoption noenhanced" restores the
> >   Version 4 default, this command is not persistent.  I.e. it is lost
> >   whenever you do another "set term" command.  Should there be
> >   a new command like "set {no}enhanced" that would apply for an
> >   entire gnuplot session?  Maybe it could offer finer control:
> >     set {no}enhanced {titles} {tics} {labels} {key}
> > 
> > - A similar issue exists for terminals with a "monochrome" mode.
> >   Should there be a global "set monochrome {some options}" command?
> >   Would this clobber all current linetype definitions, or would 
> >   there be a separate parallel set of monochrome linetypes, or what?
> > 
> > - The <space> (raise console) and <q> (close plot window) hot keys
> >   do not work consistently for different terminal types.  It would
> >   be preferable to move this functionality into the core mouse.c
> >   code and get rid of the special-case code in the individual 
> >   terminal drivers.  This is not a release-blocker, however, and may
> >   have to wait until after the final version 5.0 release.
> > 
> > 		Ethan Merritt (sf...@us...)
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: version.c still points to 5.0 rc1.

[sfeam <sf...@us...>]

On Friday, 22 August 2014 03:01:57 PM Tatsuro MATSUOKA wrote:
> Hello
> 
> I have check out the cvs source and found the cvs version is now updated to 5.1.
> 
> However, the version pointed in version.c in 5.1 branch still points 5.0 rc1.
> 
> 42: const char gnuplot_version[] = "5.0";
> 43: const char gnuplot_patchlevel[] = "rc1";
> 
> Please correct it.

These are supposed to be replaced by the contents of VERSION and PATCHLEVEL
by the build procedure.  But OK, it should be changed in version.c for
consistency.

Re: 18-August-2014 Update on version 5 progress

[Pieter-Tjerk de B. <p.t...@ut...>]

Back in June this year, there was some discussion about the fit command,
and in a mail to this list on June 15, I provided a patch to resolve
some issues with it.
I don't see 'fit' mentioned here either as a change or as an unresolved
issue, so I guess this was overlooked?

Regards,
  Pieter-Tjerk


On Mon, Aug 18, 2014 at 11:56:33AM -0700, Ethan A Merritt wrote:
> I plan to package a second release candidate for gnuplot version 5
> next weekend, unless of course someone points out an important
> bug or mis-feature in the currect CVS source that is easily fixable.
> 
> The plan is to create a new version 5.0 branch of the CVS source tree.
> It will initially hold 5.0-rc2 and will essentially freeze the source for 5.0
> except for bug fixes turned up by testing of -rc2.
> Development will continue in the main CVS tree, which will be labeled
> 5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
> New features added to 5.1 may not appear in the final release package
> for 5.0.
> 
> Thanks to everyone who test the first release candidate and reported
> problems or suggestions for improvement. Many of the issues identified
> were immediately fixable and hopefully have been resolved in the
> upcoming -rc2 release. 
> 
> None of this will affect the planned release of 4.6.6 in September/October,
> which will probably be the last release in the 4.6 series.
> 
> Changes between 5.0 -rc1 and -rc2
> =============================
> 
> * NEW grey out key entries when corresponding plot is toggled off
> * NEW allow parenthesized expressions as call parameters
> * NEW command "set margins <left>, <right>, <top>, <bottom>"
> * NEW command "set trange [theta_min:theta_max] filters polar mode input data
> * NEW command "set mouse zoomfactors <xfact>,<yfact>"
> * NEW matrix keywords for text data: "columnheaders" and "rowheaders"
> * CHANGE apply "set key {no}enhanced}" to the key title
> * CHANGE scale dashlength with line width (not yet done for all terminals)
> * CHANGE apply default rectangle style during "set obj" rather than when drawn
> * FIX width adjustment for long key title in multicolumn keys
> * FIX treat data value read as "NaN" the same as we would "1/0"
> * FIX pointtype PT_CHARACTER in 3D plots
> * FIX do not store long strings (e.g. epslatex_header) in terminal options
> * FIX extra resize of initial qt window may fix problems on OSX, Debian
> * FIX handling of events triggered by closing the qt plot window
> * FIX refresh of plot with log-scaled color box
> * FIX MSWin pipe issues
> * FIX if terminal is in "monochrome" mode, convert color requests to black
> * FIX various bugs related to the new dashtype code (there are surely more!)
> 
> 
> Unresolved issues
> =================
> 
> - The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
>   No fix is known and so far as I know no one is working on it.
>   The problem is made worse for Debian/Ubuntu users because Debian
>   plans to drop support for wxWidgets 2.8.
> 
> - Initialization and resizing of the qt terminal may still have
>   problems on OSX (and other platforms?).
> 
> - The lua terminal does not accepts ARGB color specifiers
>   (alpha is ignored).
> 
> - There is general agreement that the "dashlength" property of
>   dashed lines should scale with the linewidth.  Not all terminals
>   have yet been modified to act this way. 
> 
> - Version 5 terminals default to enhanced text mode.  This change
>   broke some scripts.  While "set termoption noenhanced" restores the
>   Version 4 default, this command is not persistent.  I.e. it is lost
>   whenever you do another "set term" command.  Should there be
>   a new command like "set {no}enhanced" that would apply for an
>   entire gnuplot session?  Maybe it could offer finer control:
>     set {no}enhanced {titles} {tics} {labels} {key}
> 
> - A similar issue exists for terminals with a "monochrome" mode.
>   Should there be a global "set monochrome {some options}" command?
>   Would this clobber all current linetype definitions, or would 
>   there be a separate parallel set of monochrome linetypes, or what?
> 
> - The <space> (raise console) and <q> (close plot window) hot keys
>   do not work consistently for different terminal types.  It would
>   be preferable to move this functionality into the core mouse.c
>   code and get rid of the special-case code in the individual 
>   terminal drivers.  This is not a release-blocker, however, and may
>   have to wait until after the final version 5.0 release.
> 
> 		Ethan Merritt (sf...@us...)
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

version.c still points to 5.0 rc1.

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

Hello

I have check out the cvs source and found the cvs version is now updated to 5.1.

However, the version pointed in version.c in 5.1 branch still points 5.0 rc1.

42: const char gnuplot_version[] = "5.0";
43: const char gnuplot_patchlevel[] = "rc1";

Please correct it.

Tatsuro

Re: bf_test fails to build on Mac OS X (latest CVS)

[Jun T. <tak...@kb...>]

On 2014/08/22, at 13:14, sfeam <sf...@us...> wrote:
> Please confirm that the modified version now in CVS
> works on OSX.

Thanks, it builds fine now (OS X 10.8/10.9).

Re: bf_test fails to build on Mac OS X (latest CVS)

[sfeam <sf...@us...>]

On Friday, 22 August 2014 12:04:48 PM Jun T. wrote:
> Compiling bf_test.c fails on my Mac as follows:
> 
> bf_test.c:24:10: fatal error: 'malloc.h' file not found
> 
> malloc.h is not available on Mac OS X; calloc() is in stdlib.h.
> 
> Since configure script checks for both stdlib.h and malloc.h,
> it would be possible to use HAVE_STDLIB_H and HAVE_MALLOC_H
> to include proper header file. I believe we can ignore systems
> on which neither stdlib.h nor malloc.h is available.


OK. We'll try that and see if any other problem platforms are
reported.  Please confirm that the modified version now in CVS
works on OSX.

   thanks,

    	Ethan

bf_test fails to build on Mac OS X (latest CVS)

[Jun T. <tak...@kb...>]

Compiling bf_test.c fails on my Mac as follows:

bf_test.c:24:10: fatal error: 'malloc.h' file not found

malloc.h is not available on Mac OS X; calloc() is in stdlib.h.

Since configure script checks for both stdlib.h and malloc.h,
it would be possible to use HAVE_STDLIB_H and HAVE_MALLOC_H
to include proper header file. I believe we can ignore systems
on which neither stdlib.h nor malloc.h is available.

Re: 18-August-2014 Update on version 5 progress

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

I plan to package a second release candidate for gnuplot version 5
next weekend, unless of course someone points out an important
bug or mis-feature in the currect CVS source that is easily fixable.

The plan is to create a new version 5.0 branch of the CVS source tree.
It will initially hold 5.0-rc2 and will essentially freeze the source for 5.0
except for bug fixes turned up by testing of -rc2.
Development will continue in the main CVS tree, which will be labeled
5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
New features added to 5.1 may not appear in the final release package
for 5.0.

Thanks to everyone who test the first release candidate and reported
problems or suggestions for improvement. Many of the issues identified
were immediately fixable and hopefully have been resolved in the
upcoming -rc2 release. 

None of this will affect the planned release of 4.6.6 in September/October,
which will probably be the last release in the 4.6 series.

Changes between 5.0 -rc1 and -rc2
=============================

* NEW grey out key entries when corresponding plot is toggled off
* NEW allow parenthesized expressions as call parameters
* NEW command "set margins <left>, <right>, <top>, <bottom>"
* NEW command "set trange [theta_min:theta_max] filters polar mode input data
* NEW command "set mouse zoomfactors <xfact>,<yfact>"
* NEW matrix keywords for text data: "columnheaders" and "rowheaders"
* CHANGE apply "set key {no}enhanced}" to the key title
* CHANGE scale dashlength with line width (not yet done for all terminals)
* CHANGE apply default rectangle style during "set obj" rather than when drawn
* FIX width adjustment for long key title in multicolumn keys
* FIX treat data value read as "NaN" the same as we would "1/0"
* FIX pointtype PT_CHARACTER in 3D plots
* FIX do not store long strings (e.g. epslatex_header) in terminal options
* FIX extra resize of initial qt window may fix problems on OSX, Debian
* FIX handling of events triggered by closing the qt plot window
* FIX refresh of plot with log-scaled color box
* FIX MSWin pipe issues
* FIX if terminal is in "monochrome" mode, convert color requests to black
* FIX various bugs related to the new dashtype code (there are surely more!)


Unresolved issues
=================

- The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
  No fix is known and so far as I know no one is working on it.
  The problem is made worse for Debian/Ubuntu users because Debian
  plans to drop support for wxWidgets 2.8.

- Initialization and resizing of the qt terminal may still have
  problems on OSX (and other platforms?).

- The lua terminal does not accepts ARGB color specifiers
  (alpha is ignored).

- There is general agreement that the "dashlength" property of
  dashed lines should scale with the linewidth.  Not all terminals
  have yet been modified to act this way. 

- Version 5 terminals default to enhanced text mode.  This change
  broke some scripts.  While "set termoption noenhanced" restores the
  Version 4 default, this command is not persistent.  I.e. it is lost
  whenever you do another "set term" command.  Should there be
  a new command like "set {no}enhanced" that would apply for an
  entire gnuplot session?  Maybe it could offer finer control:
    set {no}enhanced {titles} {tics} {labels} {key}

- A similar issue exists for terminals with a "monochrome" mode.
  Should there be a global "set monochrome {some options}" command?
  Would this clobber all current linetype definitions, or would 
  there be a separate parallel set of monochrome linetypes, or what?

- The <space> (raise console) and <q> (close plot window) hot keys
  do not work consistently for different terminal types.  It would
  be preferable to move this functionality into the core mouse.c
  code and get rid of the special-case code in the individual 
  terminal drivers.  This is not a release-blocker, however, and may
  have to wait until after the final version 5.0 release.

		Ethan Merritt (sf...@us...)

Re: PAUSE -1 and Windows terminal

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

----- Original Message -----

> From: Alan Greynolds <la...@ao...>
> To: gnu...@li...
> Cc: 
> Date: 2014/8/8, Fri 22:47
> Subject: Re: PAUSE -1 and Windows terminal
> 
> I’m using the same binaries but on Win7 and the problem appears to be only with 
> the win terminal.  I also found that just moving the mouse after the first mouse 
> click on the OK or CANCEL buttons, also dismisses the PAUSE dialog.
> 
> On Aug 8, 2014, at 12:46 AM, Bastian Märkisch <bma...@we...> wrote:
> 
>>  I cannot reproduce this on Win8 using Tatsuro Matsuoka's binaries. For 
> me the 32 and 64 bit version work with a single mouse click for 'pause 
> -1' using the win, wxt or qt terminal.
>> 
>>   Bastian
>> 
>>  Am 07.08.2014 um 18:49 schrieb Alan Greynolds:
>>>  I've noticed in MinGW-64bit version of 5.0 that with the Windows
>>>  terminal, the PAUSE -1 dialog is dismissed immediately if I hit the
>>>  return key, but takes 2 separate mouse clicks on the OK button.   4.6
>>>  and before required only 1 mouse click.
>>> 
>>>  Al Greynolds
>>> 
I cannot reproduce this on Win7 using binaries on my web site.


Tatsuro

Re: PAUSE -1 and Windows terminal

[Alan G. <la...@ao...>]

I’m using the same binaries but on Win7 and the problem appears to be only with the win terminal.  I also found that just moving the mouse after the first mouse click on the OK or CANCEL buttons, also dismisses the PAUSE dialog.

On Aug 8, 2014, at 12:46 AM, Bastian Märkisch <bma...@we...> wrote:

> I cannot reproduce this on Win8 using Tatsuro Matsuoka's binaries. For me the 32 and 64 bit version work with a single mouse click for 'pause -1' using the win, wxt or qt terminal.
> 
>  Bastian
> 
> Am 07.08.2014 um 18:49 schrieb Alan Greynolds:
>> I've noticed in MinGW-64bit version of 5.0 that with the Windows
>> terminal, the PAUSE -1 dialog is dismissed immediately if I hit the
>> return key, but takes 2 separate mouse clicks on the OK button.   4.6
>> and before required only 1 mouse click.
>> 
>> Al Greynolds
>> 
> 

Re: PAUSE -1 and Windows terminal

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

I cannot reproduce this on Win8 using Tatsuro Matsuoka's binaries. For 
me the 32 and 64 bit version work with a single mouse click for 'pause 
-1' using the win, wxt or qt terminal.

   Bastian

Am 07.08.2014 um 18:49 schrieb Alan Greynolds:
> I've noticed in MinGW-64bit version of 5.0 that with the Windows
> terminal, the PAUSE -1 dialog is dismissed immediately if I hit the
> return key, but takes 2 separate mouse clicks on the OK button.   4.6
> and before required only 1 mouse click.
>
> Al Greynolds
>

Re: WIN terminal text default

[Allin C. <cot...@wf...>]

On Thu, 7 Aug 2014, Alan Greynolds wrote:

> I've also noticed in (MinGW-64bit version of)  5.0 that the default is now
> 'enhanced' for the Windows terminal while it was 'noenhanced' in version 4.6
> and below.  Is this intentional?

Yes, and the change applies to all terminals.

Allin Cottrell

WIN terminal text default

[Alan G. <la...@ao...>]

I've also noticed in (MinGW-64bit version of)  5.0 that the default is now
'enhanced' for the Windows terminal while it was 'noenhanced' in version 4.6
and below.  Is this intentional?

 

Al 

 

RE: PAUSE -1 and Windows terminal

[Alan G. <la...@ao...>]

I've noticed in MinGW-64bit version of 5.0 that with the Windows terminal,
the PAUSE -1 dialog is dismissed immediately if I hit the return key, but
takes 2 separate mouse clicks on the OK button.   4.6 and before required
only 1 mouse click.

 

Al Greynolds

 

Re: pause mouse any: wrong key for MB1

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

>>>> I have just tried the current cvs to which the enclosed patch has been applied
>>>> but all the commands
>>>>  	pause mouse ...
>>>> do not work now (gnuplot command prompt is frozen till Ctrl/C).
>>>> Can you please repair it?
>>>
>>> What terminal and what operating system?  4.6 or 5.0?
>>
>> Cvs of both 4.6 and 5.0.
>> Linux with x11 and wxt terminals.
>
> Very strange.
> I don't see any problems here, and I can't fix it if I can't see it.
>
> I do notice one thing that possibly is confusing...
> When you say "pause mouse {button1|any}" and then
> click the mouse, no <cr> is sent to the terminal and
> no new prompt is generated.
> So it is not obvioud that control has returned to the terminal and a
> new command can be typed and executed.

Yes, you are right - just the prompt does not go back if a mouse button is 
pressed; I thought I have to press Ctrl/C while <Enter> is fine as well.
Now it works fine as well as ginput() in Octave, thanks.

Petr

Re: pause mouse any: wrong key for MB1

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

On Monday, 04 August, 2014 22:56:47 Petr Mikulik wrote:
> >> I have just tried the current cvs to which the enclosed patch has been applied
> >> but all the commands
> >>  	pause mouse ...
> >> do not work now (gnuplot command prompt is frozen till Ctrl/C).
> >> Can you please repair it?
> >
> > What terminal and what operating system?  4.6 or 5.0?
> 
> Cvs of both 4.6 and 5.0.
> Linux with x11 and wxt terminals.

Very strange.
I don't see any problems here, and I can't fix it if I can't see it.

The patch only touches the code path in which mouse button 1 is clicked.
I could imagine that the new action is not correct for some platform or
some terminal. But I cannot see how the patch can affect mouse commands
that do not involve button 1,  nor do I understand how it can affect any
command at all up to the point when mouse button 1 is clicked.

I do notice one thing that possibly is confusing...
When you say "pause mouse {button1|any}" and then
click the mouse, no <cr> is sent to the terminal and
no new prompt is generated.
So it is not obvioud that control has returned to the terminal and a
new command can be typed and executed.
Try this:

type "plot sin(x)"
type "pause mouse any"
type "show variable MOUSE"

No prompt is showing and no output appears yet in the terminals.
Now go the the plot window and left-click the mouse
In response to the mouse click, control will return to the terminal
and the output of "show variable MOUSE" will appear.

Does that not work for you?

	Ethan


> 
> Petr
> 
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: pause mouse any: wrong key for MB1

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

>> I have just tried the current cvs to which the enclosed patch has been applied
>> but all the commands
>>  	pause mouse ...
>> do not work now (gnuplot command prompt is frozen till Ctrl/C).
>> Can you please repair it?
>
> What terminal and what operating system?  4.6 or 5.0?

Cvs of both 4.6 and 5.0.
Linux with x11 and wxt terminals.

Petr

Re: pause mouse any: wrong key for MB1

[sfeam <sf...@us...>]

On Monday, 04 August 2014 09:53:42 AM Petr Mikulik wrote:
> I have just tried the current cvs to which the enclosed patch has been applied 
> but all the commands
>  	pause mouse ...
> do not work now (gnuplot command prompt is frozen till Ctrl/C).
> Can you please repair it?

 What terminal and what operating system?  4.6 or 5.0?

 	Ethan


> Thanks, Petr
> 
> 
> On Thu, 31 Jul 2014, sfeam wrote:
> 
> > On Thursday, 31 July 2014 03:40:40 PM Petr Mikulik wrote:
> >> More observation for various gnuplot versions:
> >>
> >> 4.6.1:		MB1 returns correct value
> >>
> >> 4.6.2 - 4.6.4:	"pause mouse any" ignores MB1
> >>  		"pause mouse button1" never ends
> >>
> >> 4.6.5:		pause mouse works, but returns incorrect value of MB1
> >>
> >>
> >> (I have found this problem as ginput() of Octave broke after a change of
> >> gnuplot binary from /usr/bin (OpenSUSE 12.3) to /usr/local/bin.)
> >>
> >>> ----- Original Message -----
> >>>> I've noticed that
> >>>>     plot x
> >>>>     pause mouse any
> >>>>     show var
> >>>>
> >>>> does not work correctly if you click MB1; it produces
> >>>>          MOUSE_KEY = 1063
> >>>>          MOUSE_CHAR = "'"
> >>>> instead of
> >>>>          MOUSE_BUTTON = 1
> >>>>          MOUSE_KEY = 1
> >>>>          MOUSE_CHAR = "\001"
> >>>>
> >>>> It works fine for gnuplot 4.5.1 but is wrong in the latests releases including
> >>>> cvs, using all x11, wxt and qt terminals.
> >>>>
> >>>> What's going wrong?
> >
> > I don't have time to test this properly, but the following may fix it.
> > %%%%%%
> > --- gnuplot/src/mouse.c	2014-07-22 22:45:48.000000000 -0700
> > +++ gnuplot-cvs/src/mouse.c	2014-07-31 22:15:36.096081154 -0700
> > @@ -1816,7 +1816,13 @@ event_buttonpress(struct gp_event_t *ge)
> >     } else if (ALMOST2D) {
> >         if (!setting_zoom_region) {
> > 	    if (1 == b) {
> > -	      /* not bound in 2d graphs */
> > +	      /* "pause button1" or "pause any" takes precedence over key bindings */
> > +		if (paused_for_mouse & PAUSE_BUTTON1) {
> > +		    load_mouse_variables(mouse_x, mouse_y, TRUE, b);
> > +		    event_reset(ge);
> > +		    return;
> > +		}
> > +
> > 	    } else if (2 == b) {
> > 		/* not bound in 2d graphs */
> > 	    } else if (3 == b &&
> > %%%%%%
> >
> > 	Ethan