Menu
▾
▴
gnuplot-beta
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-09-12 03:50:33
|
Version 4.4.4 ============= My plan is to release version 4.4.4 some time in the next month, consistent with the ~6 month release cycle that has held throughout the 4.2 and 4.4 release series. NEWS entries for 4.4.4 include * NEW boxxyerrors plot style now allows variable color * NEW splot with pm3d now allows variable rgb color * NEW "nonuniform matrix" indicates ascii data with explicit x, y * CHANGE columnhead(N) is a string-valued function, not a keyword * CHANGE Demarcate plots in svg output using <g id="Plot_#"><title>... * CHANGE xticlabels() works for binary data files as well as ascii * CHANGE "set key maxrows" now applies to 3D plots as well as 2D * CHANGE rewrite installation path rules for TeX files * FIX wxt terminal should now work on at least some flavors of OSX * FIX incorrect space allowed for outside left key box * FIX buffer overflow from enhanced text timefmt tic labels * FIX correction for offset in epochs when reading in time format "%s" * FIX discontinuity in defined palette limited by maxcolors * FIX initialization of svg pattern-fill definitions * FIX positioning of histogram bars when some data entries are missing * FIX emf terminal can handle UTF-8 encoding My thought is that 4.4.4 will probably be the last release in the 4.4 series. Of course we can re-think that if significant issues arise in the next 6 months. Beyond ====== After releasing 4.4.4, I am thinking that we should re-tag the CVS tree as the development branch for gnuplot version 5 and plan to put out a version 5.0 release candidate sometime after the New Year, aiming for a full release in the Spring. The chief arguments I see for bumping the version to 5 (rather than 4.6): 1) The code in the development branch has diverged enough from the code in the version 4 branch that most new patches cannot be easily back-ported. 2) There are significant syntax and UI changes already in or queued for the development branch, notably - block-structured if/else/do/for/while statements - nested iteration - local customization of linetypes using "set linetype" - tab completion and UTF-8 support in the builtin readline - reworked Windows driver - "stats" subsystem (Patchset #2894333) and probably more I'm not thinking of at the moment. What do you think? |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-09-13 12:54:16
|
On 12.09.2011 05:50, sfeam (Ethan Merritt) wrote: > The chief arguments I see for bumping the version to 5 > (rather than 4.6): > > 1) The code in the development branch has diverged enough from the > code in the version 4 branch that most new patches cannot be easily > back-ported. > 2) There are significant syntax and UI changes already in or queued for > the development branch, notably [...] I consider those good reasons to make a new non-patchlevel release, but I don't see the case for a major version number step. Those should IMHO be reserved for user-visible, _incomptabible_ changes. I.e. as long as basically all scripts written for version 4.0 (or maybe 4.4) still work, I don't quite see a reason to bump to 5.0. HBB |
|
From: Daniel J S. <dan...@ie...> - 2011-09-13 13:34:42
|
On 09/11/2011 10:50 PM, sfeam (Ethan Merritt) wrote: > Beyond > ====== > > After releasing 4.4.4, I am thinking that we should re-tag the CVS > tree as the development branch for gnuplot version 5 and plan to > put out a version 5.0 release candidate sometime after the New Year, > aiming for a full release in the Spring. > > The chief arguments I see for bumping the version to 5 > (rather than 4.6): > > 1) The code in the development branch has diverged enough from the > code in the version 4 branch that most new patches cannot be easily > back-ported. > > 2) There are significant syntax and UI changes already in or queued for > the development branch, notably > - block-structured if/else/do/for/while statements > - nested iteration > - local customization of linetypes using "set linetype" > - tab completion and UTF-8 support in the builtin readline > - reworked Windows driver > - "stats" subsystem (Patchset #2894333) > > and probably more I'm not thinking of at the moment. > > What do you think? I've been itching to revisit the hidden surface issues with gnuplot and give that a shot. If I remember correctly, there was someone from South America who submitted a hunk of code for breaking up intersecting triangular surface elements. There is much more to it, naturally, but I think using the hidden line code as a base should get us to an eventual implementation. The painter's algorithm of PM3D is very limited and just isn't amenable to true hidden surface. The first pass would be an all triangles implementation that will probably be slow and have dithering issues for surfaces that perfectly coincide. However, once that far, input from all developers for speed improvements should get things rolling where it might make a good feature for a 5.0 version in the six month time frame. Dan |
|
From: Ethan A M. <sf...@us...> - 2011-09-13 22:11:49
|
On Tuesday, September 13, 2011 05:54:07 am Hans-Bernhard Bröker wrote: > On 12.09.2011 05:50, sfeam (Ethan Merritt) wrote: > > > The chief arguments I see for bumping the version to 5 > > (rather than 4.6): > > > > 1) The code in the development branch has diverged enough from the > > code in the version 4 branch that most new patches cannot be easily > > back-ported. > > > 2) There are significant syntax and UI changes already in or queued for > > the development branch [...] > > I consider those good reasons to make a new non-patchlevel release, but > I don't see the case for a major version number step. Those should IMHO > be reserved for user-visible, _incomptabible_ changes. I.e. as long as > basically all scripts written for version 4.0 (or maybe 4.4) still work, > I don't quite see a reason to bump to 5.0. So then let's ask the question "Are there changes we held off from making because they would break backwards compatibility?" I can think of several. - We're still carrying around a bunch of conditional code under the control of --enable-backwards-compatibility. This could go away. I don't know a good way to find out how many people use this configuration option, but it isn't enabled in the linux distro packages I looked at. - The PostScript terminal driver is inconsistent with all other terminal drivers with regard to the "set size" command. Also it causes confusion that the font size in "eps" output is only half what the user requests. The "fontscale" option was a messy attempt to paper this over, but it causes additional confusion (if in fact people even realize it exists). Oh, and the sequence of dash patterns in post.trm is different from all others. Why on earth isn't linetype 1 a solid line???? We could bring post.trm into better agreement with the newer terminals. - The binary input code needs to be rewritten, if not replaced, and the revised version may well not be able to fully maintain the original syntax. It would be nice, for example, if the options controlling matrix/array input for ascii and binary files were consistent rather than re-using the same keywords for conflicting purposes. - The introduction of command line macros (./configure --enable-macros) was an early attempt to support string substitution. I believe it offers no functionality that isn't better handled using string functions. We could get rid of this conditional code. - The pieces are in place to support "dashtype" as a line property. The current syntax overloads "linetype" to mean a combination of dash properties, color properties, and width. Version 5 would be a great opportunity to clean this up and support a real "dashtype" property, but it would break old scripts that assume line color and dash pattern are really the same thing. - The "call" command no longer makes any sense, and arguably is broken. (I can't find the discussion we had about this, but it must have been about 2 years ago?). Let's get rid of it. - The alpha-channel representation of transparency used by "set style fill" and by plot style "with rgbalpha" are inconsistent. I'll accept the blame for this. Anyhow, I've held off work on supporting a general rgba color mode ( e.g. plot ... linecolor rgba "#3FAABBCC" ) because of the inconsistency. Easy enough to change the interpretation of "set style fill transparent ...", but it would invert the meaning of existing scripts. If we do go with a 4.6 release rather than 5.0, maybe these and other potential areas should be prominently marked DEPRECATED or MAY CHANGE? Ethan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-09-14 00:50:02
|
On 13.09.2011 23:59, Ethan A Merritt wrote: > So then let's ask the question "Are there changes we held off from > making because they would break backwards compatibility?" > - We're still carrying around a bunch of conditional code under the control > of --enable-backwards-compatibility. This could go away. Or we could put more old syntax we no longer want to support in the default under control of the existing switch. And maybe just drop the remainder of the support for stuff that has been in this box since version 4.0. > - The PostScript terminal driver is inconsistent with all other terminal > drivers with regard to the "set size" command. ... that's true in no small part only because you bodily removed a good number of other drivers that behaved the same way. > - The binary input code needs to be rewritten, if not replaced, and the > revised version may well not be able to fully maintain the original > syntax. It would be nice, for example, if the options controlling > matrix/array input for ascii and binary files were consistent rather > than re-using the same keywords for conflicting purposes. Now we're getting somewhere. That's an externally visible change to the main command syntax, and thus would warrant a major version number bump. > - The pieces are in place to support "dashtype" as a line property. > The current syntax overloads "linetype" to mean a combination of dash > properties, color properties, and width. That one had me completely puzzled when I (belatedly) saw it mentioned. What was so bad about 'set style line' that its functionality needed to be duplicated and incompatibly overloaded onto pre-existing syntax? Since the addition of 'linecolor' ages ago, 'linetype' already controls basically nothing but dashtype. What would be the benefit of changing the name? It would be a good deal less intrusive to add a new sub-command to 'set style' that just turns off the influence of linetype numbers on the default(!) line colours. > - The "call" command no longer makes any sense, and arguably is broken. > (I can't find the discussion we had about this, but it must have been > about 2 years ago?). I have not the slightest memory of such a discussion ever having taken place. Nor do I see how call might no longer make any sense. > - The alpha-channel representation of transparency used by "set style fill" > and by plot style "with rgbalpha" are inconsistent. I'll accept the > blame for this. Anyhow, I've held off work on supporting a general > rgba color mode ( e.g. plot ... linecolor rgba "#3FAABBCC" ) because > of the inconsistency. Easy enough to change the interpretation of > "set style fill transparent ...", but it would invert the meaning of > existing scripts. That, along with some of the other plans you brought up, looks like a rather good reason to put out a 4.6 release _before_ embarking on that journey. I.e. first make sure we have something to give people who want the new features in today's development version, with an official version stamp on it, and thus buy ourselves the time to perform major reworks that might make things worse for a while, before they get better. When we find ourselves frequently replying on the newsgroup: "but you need the development version for that", that means a new release on the trunk is in order. I think we've reached this point about half a year ago. So it's clear that the 4.4 branch should be ended soon, and replaced by a branch starting at the current CVS head. The question I see as open is whether the changes present in today's warrant a 5.0 version number. Things that are currently just plans should not factor into that decision. > If we do go with a 4.6 release rather than 5.0, maybe these and other > potential areas should be prominently marked DEPRECATED or MAY CHANGE? To the extent such plans are, indeed, known and accepted at the time of a 4.6 release, sure. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-09-14 05:15:17
|
On Tuesday, 13 September 2011, Hans-Bernhard Bröker wrote:
> On 13.09.2011 23:59, Ethan A Merritt wrote:
>
> > - The PostScript terminal driver is inconsistent with all other terminal
> > drivers with regard to the "set size" command.
>
> ... that's true in no small part only because you bodily removed a good
> number of other drivers that behaved the same way.
Terminals removed since version 4.0:
amiga apollo atari fg gnugraph gpr iris4d mgr multitos
png(libpng) rgip unixplot
None of those have been remotely relevant for the last decade.
Who cares now what they did about "set size"?
> > - The pieces are in place to support "dashtype" as a line property.
> > The current syntax overloads "linetype" to mean a combination of dash
> > properties, color properties, and width.
>
> That one had me completely puzzled when I (belatedly) saw it mentioned.
> What was so bad about 'set style line' that its functionality needed
> to be duplicated and incompatibly overloaded onto pre-existing syntax?
Clarify please. Nothing has changed about 'set style line' that I know of.
> Since the addition of 'linecolor' ages ago, 'linetype' already controls
> basically nothing but dashtype. What would be the benefit of changing
> the name?
I think we're talking at cross-purposes. The issue is that if you write
a script that refers to linetypes, it does different things depending on
whether you say "set term post solid color" or "set term post dashed mono".
The terminal itself changes how linetype is interpreted.
The other point is that you can [now] force the color regardless of the
terminal's own defaults. But there is no way to force the dash type;
you can only use the terminal defaults.
> It would be a good deal less intrusive to add a new sub-command to 'set
> style' that just turns off the influence of linetype numbers on the
> default(!) line colours.
Less intrusive than what?
> > - The "call" command no longer makes any sense, and arguably is broken.
> > (I can't find the discussion we had about this, but it must have been
> > about 2 years ago?).
>
> I have not the slightest memory of such a discussion ever having taken
> place. Nor do I see how call might no longer make any sense.
Variables are persistent across 'load foo' anyhow. There is no need
for a separate mechanism 'call foo var1 var2 var3'.
Brokenness: the call mechanism does not handle strings (understandable
since they didn't exist at the time it was written).
Ethan
|
