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