From: Tatsuro M. <tma...@ya...> - 2014-08-23 02:39:14
|
----- 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 |