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