Menu
▾
▴
gnuplot-beta
|
From: sfeam <sf...@us...> - 2018-04-27 01:32:09
|
I have uploaded a 5.2.3 tarball to the "testing" section of the
gnuplot files folder on SourceForge.
https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
gnuplot-5.2.3-testing.tar.gz
So far as I know there is nothing unusual about this patchlevel
release. It is the usual mix of bugfixes and a few features
back-ported from the development version. However it is the first
release tarball prepared from a git branch rather than from our
old cvs repository. That shouldn't make any difference but I
suppose it is possible that something comes out a little different.
Please use the testing tarball to confirm a successful build or
report build errors. If no problems are found I expect to make a
regular release of 5.2.3 next week.
Ethan
|
|
From: Dima K. <gn...@di...> - 2018-04-27 04:18:23
Attachments:
tst.gp
|
sfeam via gnuplot-beta <gnu...@li...> writes: > I have uploaded a 5.2.3 tarball to the "testing" section of the > gnuplot files folder on SourceForge. I found a bug earlier that I haven't yet got around to reporting or trying to fix. Just confirmed that it's still an issue with this new build. Would you mind taking a look before this release becomes official? The bug: autoscaling of plots with any logscale axes doesn't work on a replot. For instance, the attached script produces reasonable autoscaling initially, but after a "replot", it is broken. This is significant because everyone using a tiling window manager ends up replotting at least once before looking at any plot. I vaguely recall a discussion at some point in the past where we talked about the "replot" command just recalling the axis extents from the initial plot command if it is sure the data hasn't changed (which is true for inline data, such as here). Should we do that? Thanks. |
|
From: sfeam <sf...@us...> - 2018-04-27 05:04:14
|
On Thursday, 26 April 2018 21:02:12 Dima Kogan wrote: > sfeam via gnuplot-beta <gnu...@li...> writes: > > > I have uploaded a 5.2.3 tarball to the "testing" section of the > > gnuplot files folder on SourceForge. > > I found a bug earlier that I haven't yet got around to reporting or > trying to fix. Just confirmed that it's still an issue with this new > build. Would you mind taking a look before this release becomes > official? > > The bug: autoscaling of plots with any logscale axes doesn't work on a > replot. For instance, the attached script produces reasonable > autoscaling initially, but after a "replot", it is broken. This is > significant because everyone using a tiling window manager ends up > replotting at least once before looking at any plot. I agree this is undesirable, but I don't see an immediate fix. There are at least a couple of work-arounds however 1) Don't replot in-line data. That didn't use to be possible at all and as you have found the change to allow it was imperfect. Put the data in a datablock instead. 2) Use writeback/restore: set xrange [*:*] writeback plot '-' ... set xrange restore replot > I vaguely recall a discussion at some point in the past where we talked > about the "replot" command just recalling the axis extents from the > initial plot command if it is sure the data hasn't changed (which is > true for inline data, such as here). Should we do that? I vaguely recall that also but I don't remember the details. I'll look into it. However I have a strong aversion to complicated last-minute changes before a release. If there's some stupid error in the logic because of log scaling that might have a trivial fix. But re-doing the way autoscale + replot works sounds like a major change that I'd want to have tested in the development version for a while before it went into a minor level release. cheers, Ethan |
|
From: Dima K. <gn...@di...> - 2018-04-27 05:39:48
|
sfeam <sf...@us...> writes: > I have a strong aversion to complicated last-minute changes before a > release. If there's some stupid error in the logic because of log > scaling that might have a trivial fix. But re-doing the way autoscale > + replot works sounds like a major change that I'd want to have tested > in the development version for a while before it went into a minor > level release. OK. Yes. Let's then talk about it separated from this release. > I agree this is undesirable, but I don't see an immediate fix. > There are at least a couple of work-arounds however > > 1) Don't replot in-line data. That didn't use to be possible at > all and as you have found the change to allow it was imperfect. > Put the data in a datablock instead. > > 2) Use writeback/restore: > set xrange [*:*] writeback > plot '-' > ... > set xrange restore > replot Neither of these work for me. 99% of my (quite heavy) gnuplot usage is via this frontend: https://github.com/dkogan/feedgnuplot It'd be great if we supported this sort of interface natively, but that's a separate (and bigger) conversation. Inline data is a core assumption of this tool. And since the window manager is doing the replotting, I'm not explicitly sending the "replot" command, so I can't explicitly ask gnuplot to save/restore the writeback. The earlier discussion was this: https://sourceforge.net/p/gnuplot/bugs/1947/ The suggestion was: when plotting: if( we have only inline data) { save writeback } when replotting: if( we have only inline data && current plot ranges are those computed from the autoranging ) { restore writeback } This assumes the data doesn't change for the replot, which is true in the case of inline data. This actually makes replotting inline data is easier than data in a file. Do you see downsides here? Thanks. |
|
From: sfeam <sf...@us...> - 2018-04-27 06:36:10
|
On Thursday, 26 April 2018 22:39:38 Dima Kogan wrote: > > sfeam <sf...@us...> writes: > > > I have a strong aversion to complicated last-minute changes before a > > release. If there's some stupid error in the logic because of log > > scaling that might have a trivial fix. But re-doing the way autoscale > > + replot works sounds like a major change that I'd want to have tested > > in the development version for a while before it went into a minor > > level release. > > OK. Yes. Let's then talk about it separated from this release. Heh. And indeed I found a stupid error that failed to check for logscaling at one point during the "refresh" command that is substituted for "replot" for inline data. I make no guarantee that it fixes everything but it does work on your test script. The larger routine that this error is embedded in all looks suspect to me, but changing the whole thing is more than I'm going to tackle right now. Can you test the stupid-error fix using git tip for the development version? I'll run some additional tests here also. If nothing bad turns up I'll make a decision about including it in 5.2.3 also. Ethan > > > > I agree this is undesirable, but I don't see an immediate fix. > > There are at least a couple of work-arounds however > > > > 1) Don't replot in-line data. That didn't use to be possible at > > all and as you have found the change to allow it was imperfect. > > Put the data in a datablock instead. > > > > 2) Use writeback/restore: > > set xrange [*:*] writeback > > plot '-' > > ... > > set xrange restore > > replot > > Neither of these work for me. 99% of my (quite heavy) gnuplot usage is > via this frontend: https://github.com/dkogan/feedgnuplot > > It'd be great if we supported this sort of interface natively, but > that's a separate (and bigger) conversation. Inline data is a core > assumption of this tool. And since the window manager is doing the > replotting, I'm not explicitly sending the "replot" command, so I can't > explicitly ask gnuplot to save/restore the writeback. > > The earlier discussion was this: > > https://sourceforge.net/p/gnuplot/bugs/1947/ > > The suggestion was: > > when plotting: > if( we have only inline data) > { > save writeback > } > > when replotting: > if( we have only inline data && > current plot ranges are those > computed from the autoranging ) > { > restore writeback > } > > This assumes the data doesn't change for the replot, which is true in > the case of inline data. This actually makes replotting inline data is > easier than data in a file. > > Do you see downsides here? > > Thanks. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Dima K. <gn...@di...> - 2018-04-27 06:50:37
|
sfeam <sf...@us...> writes: > Heh. And indeed I found a stupid error that failed to check for > logscaling at one point during the "refresh" command that is substituted > for "replot" for inline data. I make no guarantee that it fixes > everything but it does work on your test script. > > The larger routine that this error is embedded in all looks suspect > to me, but changing the whole thing is more than I'm going to tackle > right now. > > Can you test the stupid-error fix using git tip for the development > version? I'll run some additional tests here also. If nothing bad > turns up I'll make a decision about including it in 5.2.3 also. Thanks for doing this so quickly. I just tested it, and it indeed makes the test script work. Your commit to fix that problem only touches the x axis. I changed the test script to "set logscale y" instead of x to see if that's also broken, and indeed it is. Can you do whatever you did with the x axis to the y axis? I can imagine that x2 and y2 axes are affected and maybe 3d axes. And maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases, probably. Thanks again |
|
From: Ethan A M. <sf...@us...> - 2018-04-27 18:03:48
|
On Thursday, April 26, 2018 11:50:25 PM PDT Dima Kogan wrote: > sfeam <sf...@us...> writes: > > > Heh. And indeed I found a stupid error that failed to check for > > logscaling at one point during the "refresh" command that is substituted > > for "replot" for inline data. I make no guarantee that it fixes > > everything but it does work on your test script. > > > > The larger routine that this error is embedded in all looks suspect > > to me, but changing the whole thing is more than I'm going to tackle > > right now. > > > > Can you test the stupid-error fix using git tip for the development > > version? I'll run some additional tests here also. If nothing bad > > turns up I'll make a decision about including it in 5.2.3 also. > > Thanks for doing this so quickly. I just tested it, and it indeed makes > the test script work. Your commit to fix that problem only touches the x > axis. I changed the test script to "set logscale y" instead of x to see > if that's also broken, and indeed it is. Can you do whatever you did > with the x axis to the y axis? The stupid error I found was in code that only dealt with the x axis of the current plot (so either x or x2). > I can imagine that x2 and y2 axes are affected and maybe 3d axes. And > maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases, > probably. A higher-level fix is required so that all axes are correctly re-evaluated on refresh. The difficulty comes from trying to handle both pure "replot/refresh" requests and zoom operations. Ethan |
|
From: Dima K. <gn...@di...> - 2018-04-27 18:21:39
|
Ethan A Merritt <sf...@us...> writes: > The stupid error I found was in code that only dealt with the x axis > of the current plot (so either x or x2). Hmmm. I see a very outwardly-similar problem if I "set logscale y" instead of "set logscale x" in that test script. Do you see it too? >> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And >> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases, >> probably. > > A higher-level fix is required so that all axes are correctly re-evaluated > on refresh. The difficulty comes from trying to handle both pure > "replot/refresh" requests and zoom operations. Yeah. I think the auto-writeback logic proposed earlier is the more complete way to do this. Thanks dima |
|
From: Ethan A M. <sf...@us...> - 2018-04-27 19:12:15
|
On Friday, April 27, 2018 11:21:29 AM PDT Dima Kogan wrote: > Ethan A Merritt <sf...@us...> writes: > > > The stupid error I found was in code that only dealt with the x axis > > of the current plot (so either x or x2). > > Hmmm. I see a very outwardly-similar problem if I "set logscale y" > instead of "set logscale x" in that test script. Do you see it too? Yes I see it too. But there is no y axis fixup code analogous to the x axis fixup code, So there is not an analogous stupid error that I can fix with one line of code. Ethan > >> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And > >> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases, > >> probably. > > > > A higher-level fix is required so that all axes are correctly re-evaluated > > on refresh. The difficulty comes from trying to handle both pure > > "replot/refresh" requests and zoom operations. > > Yeah. I think the auto-writeback logic proposed earlier is the more > complete way to do this. |
|
From: Dima K. <gn...@di...> - 2018-04-27 20:19:00
Attachments:
refresh-auto-writeback.patch
|
Ethan A Merritt <sf...@us...> writes: >> Yeah. I think the auto-writeback logic proposed earlier is the more >> complete way to do this. A crude prototype patch is attached. It unconditionally saves the writeback before each plot, and unconditionally restores it before each refresh (not replot). Works for the test case here. With a bit of extending, I'd like to see something like this be included. |
|
From: sfeam <sf...@us...> - 2018-04-28 05:20:45
|
On Friday, 27 April 2018 13:18:50 Dima Kogan wrote: > Ethan A Merritt <sf...@us...> writes: > > >> Yeah. I think the auto-writeback logic proposed earlier is the more > >> complete way to do this. > > A crude prototype patch is attached. It unconditionally saves the > writeback before each plot, and unconditionally restores it before each > refresh (not replot). Works for the test case here. With a bit of > extending, I'd like to see something like this be included. Looks promising! I have applied your patch, lightly edited, to the development version and removed the code it replaces. The change fixes a problem with "refresh" in 3D plots that I was not aware of. I'd like to see this change tested in the development version for one cycle before applying it to the stable series, because it does change the use of the axis writeback flag and so has in theory a potential to break existing scripts that use "set xrange nowriteback". That was always a very obscure option so there may well not be any such scripts. While testing I managed to trigger a bad state after an "unzoom" operation of a plot with logscale axes. But then I couldn't reproduce it so I can't say for sure that it was really the new code at fault. It's hard to automate testing of zoom/unzoom and window redraw operations. If no one complains about the changed status of the writeback flag there is one further step of simplification possible by setting that flag in the default axis structures for x/y/etc rather than setting it all over again in every plot and splot command. Ethan |
|
From: Tatsuro M. <tma...@ya...> - 2018-04-28 01:52:49
|
Now I am compiling on windows. After fishing I will upload windows binary packages on the testing directory. Tatsuro ----- Original Message ----- > From: sfeam via gnuplot-beta <gnu...@li...> > To: gnu...@li... > Cc: > Date: 2018/4/27, Fri 10:31 > Subject: pre-release testing version of gnuplot 5.2.3 > > I have uploaded a 5.2.3 tarball to the "testing" section of the > gnuplot files folder on SourceForge. > > https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/ > gnuplot-5.2.3-testing.tar.gz > > > So far as I know there is nothing unusual about this patchlevel > release. It is the usual mix of bugfixes and a few features > back-ported from the development version. However it is the first > release tarball prepared from a git branch rather than from our > old cvs repository. That shouldn't make any difference but I > suppose it is possible that something comes out a little different. > > Please use the testing tarball to confirm a successful build or > report build errors. If no problems are found I expect to make a > regular release of 5.2.3 next week. > > Ethan > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Tatsuro M. <tma...@ya...> - 2018-04-28 02:26:36
|
I have uploaded 5.2.3 testing windows binary packages. Tatsuro ----- Original Message ----- > From: Tatsuro MATSUOKA <tma...@ya...> > To: Merritt Ethan <sf...@us...>; gnu...@li... > Cc: > Date: 2018/4/28, Sat 10:52 > Subject: Re: pre-release testing version of gnuplot 5.2.3 > > Now I am compiling on windows. > After fishing I will upload windows binary packages on the testing directory. > > Tatsuro > > > > ----- Original Message ----- >> From: sfeam via gnuplot-beta <gnu...@li...> >> To: gnu...@li... >> Cc: >> Date: 2018/4/27, Fri 10:31 >> Subject: pre-release testing version of gnuplot 5.2.3 >> >> I have uploaded a 5.2.3 tarball to the "testing" section of the >> gnuplot files folder on SourceForge. >> >> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/ >> gnuplot-5.2.3-testing.tar.gz >> >> >> So far as I know there is nothing unusual about this patchlevel >> release. It is the usual mix of bugfixes and a few features >> back-ported from the development version. However it is the first >> release tarball prepared from a git branch rather than from our >> old cvs repository. That shouldn't make any difference but I >> suppose it is possible that something comes out a little different. >> >> Please use the testing tarball to confirm a successful build or >> report build errors. If no problems are found I expect to make a >> regular release of 5.2.3 next week. >> >> Ethan >> >> > ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> gnuplot-beta mailing list >> gnu...@li... >> Membership management via: >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X