Menu
▾
▴
gnuplot-beta
|
From: sfeam (E. Merritt) <eam...@gm...> - 2013-03-10 06:15:01
|
Anyone know of an unresolved 4.6 bug that should be fixed before
releasing 4.6.2? If not, I plan to put the usual source tarball
on SourceForge later this week.
Any volunteers to prepare a Windows install package?
Ethan
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
NEWS file for 4.6.2
New features, changes and fixes since gnuplot version 4.6.1
===========================================================
* NEW Allow the "bind" command to attach a user command to mouse button 1
* NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
* NEW -d option from command line skips ~/.gnuplot initialization file
* NEW plot '<&N' plots from file descriptor N opened during shell invocation
* CHANGE "unset term" restores original default terminal (GNUTERM)
* CHANGE ignore extraneous trailing comma in a plot command
* CHANGE special case code for faster input of uniform binary matrix data
* CHANGE test for whether the session should be interactive or non-interactive
* CHANGE draw zeroaxis lines in the same layer as the grid and border
* CHANGE allow 2-column-only variant of yerrorbars (implicit x coord)
* FIX aquaterm rendering of rgbimage plot type
* FIX gd terminal fontsize change requested by set_font(",newsize")
* FIX qt terminal font metrics
* FIX qt terminal mouse tracking and resize events for persistent plots
* FIX x11 terminal sometimes failed to reset the line width
* FIX -persist mode continued mousing of 3D "set view map" plots
* FIX reset parsing state after error in parsing string input
* FIX buffer overflow from very long tic label formats
* FIX broken handling of formatted input via 'using 1:2 "<format>"'
* FIX exit current command file from inside bracketed clause
* FIX estimation of space required for rotated x-axis tic labels
* FIX partial axis ranges (e.g. xrange [*:MAX]) when refreshing volatile data
* FIX -persist option broken if configured without x11
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
From: Daniel J S. <dan...@ie...> - 2013-03-10 18:04:05
|
On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote:
> Anyone know of an unresolved 4.6 bug that should be fixed before
> releasing 4.6.2? If not, I plan to put the usual source tarball
> on SourceForge later this week.
The one concern is the description for this new item:
> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
which seems to me like overselling things a bit. pm3d has always
occluded whatever is behind it, so that is not new. The example
actually has the pm3d surface on the bottom layer.
What's new is the invisible line type (-2) for hidden surface mesh. In
the example, the invisible line type partially covers up the axes which
doesn't look good. To see this, after the hidden2.dem demo, type
splot x*x-y*y with lines lt 1 lc rgb "#000000", \
f(x,y) with lines lt -2 notitle
Also, the meshes don't occlude the pm3d surfaces (the surfaces show
through the mesh), so that too isn't doing any type of occlusion. It's
like going backward from hidden3d. What would be nice (and something
I've wanted to work on but can't find the time) is an actual hidden 3D
surface feature using the mesh sectioning as a starting point.
I'm not saying that plot example isn't something that someone wouldn't
want to do. I realize gnuplot doesn't work this way, but there has been
discussion about making the range specification within the plot command
apply to just the plot that follows it. If that were the case, one
could create a plot similar to hidden2d.dem with the following
unset hidden3d
set zrange [-100:100]
splot [][][-110:0] x*x-y*y with lines lt 1 lc rgb "#000000", \
f(x,y) with pm3d, \
[][][0:100] x*x-y*y with lines lt 1 lc rgb "#000000" notile
But even that isn't the best solution (actually bad, but if needing a
plot from a particular angle, it would do) because if one were to rotate
the plot to look from a "underneath", the order of plots would no longer
be correct.
What would really be desirable is the ability to specify which surfaces
should occlude and which shouldn't. I actually think that is a very
useful feature to have. That way one could specify an interior surface
that should always show through, which is what the hidden2d example
effectively doing as observed. So, here might be how that works:
set hidden3d
f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5)
splot f(x,y) with pm3d solid, \
x*x-y*y with lines lt 1 lc rgb "#000000" transparent
Well, in summary, rather than describing this as a pm3d-related feature,
how about
* NEW hidden3d invisible lines for simulated surface occlusion (as in
hidden2.dem)
Dan
|
|
From: Ethan M. <eam...@gm...> - 2013-03-10 21:24:11
|
On Sunday, 10 March 2013, Daniel J Sebald wrote: > On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote: > > Anyone know of an unresolved 4.6 bug that should be fixed before > > releasing 4.6.2? If not, I plan to put the usual source tarball > > on SourceForge later this week. > > The one concern is the description for this new item: > > > * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem) > > which seems to me like overselling things a bit. pm3d has always > occluded whatever is behind it, so that is not new. That's not true. Up until now the non-pm3d lines handled by hidden3d ignored the pm3d surface altogether, so they would appear on top in the rendered image regardless of whether they should have been in front or behind the pm3d surface. Now the behind portions are correctly not drawn. [snip] > What would really be desirable is the ability to specify which surfaces > should occlude and which shouldn't. I actually think that is a very > useful feature to have. That would be the existing "nohidden" keyword, if I'm understanding you correctly. Ethan > That way one could specify an interior surface > that should always show through, which is what the hidden2d example > effectively doing as observed. So, here might be how that works: > > set hidden3d > f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5) > splot f(x,y) with pm3d solid, \ > x*x-y*y with lines lt 1 lc rgb "#000000" transparent > > > Well, in summary, rather than describing this as a pm3d-related feature, > how about > > * NEW hidden3d invisible lines for simulated surface occlusion (as in > hidden2.dem) > > Dan > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Daniel J S. <dan...@ie...> - 2013-03-10 22:20:34
|
On 03/10/2013 04:22 PM, Ethan Merritt wrote: > On Sunday, 10 March 2013, Daniel J Sebald wrote: >> On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote: >>> Anyone know of an unresolved 4.6 bug that should be fixed before >>> releasing 4.6.2? If not, I plan to put the usual source tarball >>> on SourceForge later this week. >> >> The one concern is the description for this new item: >> >>> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem) >> >> which seems to me like overselling things a bit. pm3d has always >> occluded whatever is behind it, so that is not new. > > That's not true. Up until now the non-pm3d lines handled by hidden3d > ignored the pm3d surface altogether, so they would appear on top in > the rendered image regardless of whether they should have been in front > or behind the pm3d surface. Now the behind portions are correctly > not drawn. But it is not the pm3d elements that are in the algorithm. It is the invisible lines that are forcing the behind portions to not be drawn. Was there something introduced to the hidden3d algorithm that uses the coordinate-set for the pm3d elements? After running the hidden2.dem demo, type: set hidden3d back replot and it is clear that the difference is the order in which pm3d surface and hidden3d elements are drawn. It's a creative way of simulating what we actually want, which is true hidden surface behavior. But if it becomes too manually configurable and meticulous, the user will likely find other ways to accomplish the same thing via function definitions or whatnot. All I'm saying is that I think this is more of a hidden3d feature than it is a pm3d feature. The hidden3d -2 surface is creating a hole in the mesh to allow whatever is behind it to show through. It requires the user to think through things a bit. > [snip] >> What would really be desirable is the ability to specify which surfaces >> should occlude and which shouldn't. I actually think that is a very >> useful feature to have. > > That would be the existing "nohidden" keyword, if I'm understanding > you correctly. Maybe, I'm not sure. I type "help nohidden" which displays the help for "set hidden3d". So "hidden" is the same as "hidden3d"? And "set nohidden3d" means to turn off hidden3d? I would say it is not the same. "nohidden3d" will just show every mesh line. What I'm suggesting is that each plot "surface" or "mesh" can have its hiding capability controlled separately. That would be doable if we have full and complete hidden 3D capability. This raises another interesting question. Say we were to integrate surfaces into the hidden3d capability. Right now hidden3d removes the mesh pieces that are hidden. Could it be possible to keep those mesh pieces and somehow combine them with the alpha-mixing of the surface elements? Might make for an interesting plot. Dan > > Ethan > > > >> That way one could specify an interior surface >> that should always show through, which is what the hidden2d example >> effectively doing as observed. So, here might be how that works: >> >> set hidden3d >> f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5) >> splot f(x,y) with pm3d solid, \ >> x*x-y*y with lines lt 1 lc rgb "#000000" transparent >> >> >> Well, in summary, rather than describing this as a pm3d-related feature, >> how about >> >> * NEW hidden3d invisible lines for simulated surface occlusion (as in >> hidden2.dem) >> >> Dan >> >> ------------------------------------------------------------------------------ >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >> endpoint security space. For insight on selecting the right partner to >> tackle endpoint security challenges, access the full report. >> http://p.sf.net/sfu/symantec-dev2dev >> _______________________________________________ >> gnuplot-beta mailing list >> gnu...@li... >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta >> > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com |
|
From: Ethan A M. <eam...@gm...> - 2013-03-10 23:10:48
|
On Sunday, 10 March 2013, Daniel J Sebald wrote: > On 03/10/2013 04:22 PM, Ethan Merritt wrote: > > On Sunday, 10 March 2013, Daniel J Sebald wrote: > >> On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote: > >>> Anyone know of an unresolved 4.6 bug that should be fixed before > >>> releasing 4.6.2? If not, I plan to put the usual source tarball > >>> on SourceForge later this week. > >> > >> The one concern is the description for this new item: > >> > >>> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem) > >> > >> which seems to me like overselling things a bit. pm3d has always > >> occluded whatever is behind it, so that is not new. > > > > That's not true. Up until now the non-pm3d lines handled by hidden3d > > ignored the pm3d surface altogether, so they would appear on top in > > the rendered image regardless of whether they should have been in front > > or behind the pm3d surface. Now the behind portions are correctly > > not drawn. > > But it is not the pm3d elements that are in the algorithm. It is the > invisible lines that are forcing the behind portions to not be drawn. Correct. > Was there something introduced to the hidden3d algorithm that uses the > coordinate-set for the pm3d elements? Yes. The same work-around in the hidden2d demo (draw invisble lines for the same surface as the pm3d version) was moved into the code itself. > After running the hidden2.dem demo, type: The point is that the manual work-around in the the hidden2 demo is no longer required. The code does it for you. It is true that the work-around is still not perfect, whether manual or automatic. > set hidden3d back > replot > > and it is clear that the difference is the order in which pm3d surface > and hidden3d elements are drawn. The invisible lines approach only works for "set hidden3d front". > > [snip] > >> What would really be desirable is the ability to specify which surfaces > >> should occlude and which shouldn't. I actually think that is a very > >> useful feature to have. > > > > That would be the existing "nohidden" keyword, if I'm understanding > > you correctly. > > Maybe, I'm not sure. I type "help nohidden" which displays the help for > "set hidden3d". So "hidden" is the same as "hidden3d"? And "set > nohidden3d" means to turn off hidden3d? set hidden3d splot A, B nohidden, C means to include A and C in the hidden3d calculations but treat B without regard to hidden3d. Ethan > I would say it is not the same. "nohidden3d" will just show every mesh > line. What I'm suggesting is that each plot "surface" or "mesh" can > have its hiding capability controlled separately. That would be doable > if we have full and complete hidden 3D capability. > > This raises another interesting question. Say we were to integrate > surfaces into the hidden3d capability. Right now hidden3d removes the > mesh pieces that are hidden. Could it be possible to keep those mesh > pieces and somehow combine them with the alpha-mixing of the surface > elements? Might make for an interesting plot. > > Dan > > > > > > > Ethan > > > > > > > >> That way one could specify an interior surface > >> that should always show through, which is what the hidden2d example > >> effectively doing as observed. So, here might be how that works: > >> > >> set hidden3d > >> f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5) > >> splot f(x,y) with pm3d solid, \ > >> x*x-y*y with lines lt 1 lc rgb "#000000" transparent > >> > >> > >> Well, in summary, rather than describing this as a pm3d-related feature, > >> how about > >> > >> * NEW hidden3d invisible lines for simulated surface occlusion (as in > >> hidden2.dem) > >> > >> Dan > >> > >> ------------------------------------------------------------------------------ > >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > >> endpoint security space. For insight on selecting the right partner to > >> tackle endpoint security challenges, access the full report. > >> http://p.sf.net/sfu/symantec-dev2dev > >> _______________________________________________ > >> gnuplot-beta mailing list > >> gnu...@li... > >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > >> > > > > > > ------------------------------------------------------------------------------ > > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > > endpoint security space. For insight on selecting the right partner to > > tackle endpoint security challenges, access the full report. > > http://p.sf.net/sfu/symantec-dev2dev > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > -- Tradition is not the worship of ashes, but the preservation of fire. - Gustav Mahler |
|
From: Bastian M. <bma...@we...> - 2013-03-22 18:34:27
|
Please find a release candidate of a Windows installer and a zip package at http://www.gnuplot.info/development/binaries/ Please test them thoroughly so that we can make them available to the public. Bastian Am 10.03.2013 07:14, schrieb sfeam (Ethan Merritt): > Anyone know of an unresolved 4.6 bug that should be fixed before > releasing 4.6.2? If not, I plan to put the usual source tarball > on SourceForge later this week. > > Any volunteers to prepare a Windows install package? > > Ethan > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > NEWS file for 4.6.2 > > New features, changes and fixes since gnuplot version 4.6.1 > =========================================================== > > * NEW Allow the "bind" command to attach a user command to mouse button 1 > * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem) > * NEW -d option from command line skips ~/.gnuplot initialization file > * NEW plot '<&N' plots from file descriptor N opened during shell invocation > * CHANGE "unset term" restores original default terminal (GNUTERM) > * CHANGE ignore extraneous trailing comma in a plot command > * CHANGE special case code for faster input of uniform binary matrix data > * CHANGE test for whether the session should be interactive or non-interactive > * CHANGE draw zeroaxis lines in the same layer as the grid and border > * CHANGE allow 2-column-only variant of yerrorbars (implicit x coord) > * FIX aquaterm rendering of rgbimage plot type > * FIX gd terminal fontsize change requested by set_font(",newsize") > * FIX qt terminal font metrics > * FIX qt terminal mouse tracking and resize events for persistent plots > * FIX x11 terminal sometimes failed to reset the line width > * FIX -persist mode continued mousing of 3D "set view map" plots > * FIX reset parsing state after error in parsing string input > * FIX buffer overflow from very long tic label formats > * FIX broken handling of formatted input via 'using 1:2 "<format>"' > * FIX exit current command file from inside bracketed clause > * FIX estimation of space required for rotated x-axis tic labels > * FIX partial axis ranges (e.g. xrange [*:MAX]) when refreshing volatile data > * FIX -persist option broken if configured without x11 > |
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-01 19:57:48
|
On Friday, March 22, 2013 11:34:33 am Bastian Märkisch wrote: > Please find a release candidate of a Windows installer and a zip package at > http://www.gnuplot.info/development/binaries/ > > Please test them thoroughly so that we can make them available to the > public. What's the status on this - should it be moved/copied to the SourceForge download site? Ethan > > Bastian > > > Am 10.03.2013 07:14, schrieb sfeam (Ethan Merritt): > > Anyone know of an unresolved 4.6 bug that should be fixed before > > releasing 4.6.2? If not, I plan to put the usual source tarball > > on SourceForge later this week. > > > > Any volunteers to prepare a Windows install package? > > > > Ethan > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > NEWS file for 4.6.2 > > > > New features, changes and fixes since gnuplot version 4.6.1 > > =========================================================== > > > > * NEW Allow the "bind" command to attach a user command to mouse button 1 > > * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem) > > * NEW -d option from command line skips ~/.gnuplot initialization file > > * NEW plot '<&N' plots from file descriptor N opened during shell invocation > > * CHANGE "unset term" restores original default terminal (GNUTERM) > > * CHANGE ignore extraneous trailing comma in a plot command > > * CHANGE special case code for faster input of uniform binary matrix data > > * CHANGE test for whether the session should be interactive or non-interactive > > * CHANGE draw zeroaxis lines in the same layer as the grid and border > > * CHANGE allow 2-column-only variant of yerrorbars (implicit x coord) > > * FIX aquaterm rendering of rgbimage plot type > > * FIX gd terminal fontsize change requested by set_font(",newsize") > > * FIX qt terminal font metrics > > * FIX qt terminal mouse tracking and resize events for persistent plots > > * FIX x11 terminal sometimes failed to reset the line width > > * FIX -persist mode continued mousing of 3D "set view map" plots > > * FIX reset parsing state after error in parsing string input > > * FIX buffer overflow from very long tic label formats > > * FIX broken handling of formatted input via 'using 1:2 "<format>"' > > * FIX exit current command file from inside bracketed clause > > * FIX estimation of space required for rotated x-axis tic labels > > * FIX partial axis ranges (e.g. xrange [*:MAX]) when refreshing volatile data > > * FIX -persist option broken if configured without x11 > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742 |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2013-04-01 20:12:20
|
On 01.04.2013 21:52, Ethan Merritt wrote: > On Friday, March 22, 2013 11:34:33 am Bastian Märkisch wrote: >> Please find a release candidate of a Windows installer and a zip package at >> http://www.gnuplot.info/development/binaries/ >> >> Please test them thoroughly so that we can make them available to the >> public. > > What's the status on this - should it be moved/copied to the SourceForge > download site? FWIW, it works just fine on my Windows box here. |
|
From: Bastian M. <bma...@we...> - 2013-04-04 18:56:23
|
Am 01.04.2013 21:52, schrieb Ethan Merritt: > On Friday, March 22, 2013 11:34:33 am Bastian Märkisch wrote: >> Please find a release candidate of a Windows installer and a zip package at >> http://www.gnuplot.info/development/binaries/ >> >> Please test them thoroughly so that we can make them available to the >> public. > > What's the status on this - should it be moved/copied to the SourceForge > download site? > > Ethan > The only feedback so far was from Hans-Bernhard. I am reluctant to proceed with the release because the "-persist" mode is broken in current CVS and 4.6.2 on Windows in two ways: First of all it is not working at all. Apparently a code snippet for Windows got removed by accident on Feb 3rd. Second, even if it would work, it would still create zombie processes if the wxt terminal is used, see bug #1103. This bug has been fixed in CVS and I am working on backporting it together with some other fixes to the 4.6 tree. Bastian |
|
From: Bastian M. <bma...@we...> - 2013-04-05 19:07:58
|
Am 04.04.2013 20:56, schrieb Bastian Märkisch: > Am 01.04.2013 21:52, schrieb Ethan Merritt: >> On Friday, March 22, 2013 11:34:33 am Bastian Märkisch wrote: >>> Please find a release candidate of a Windows installer and a zip package at >>> http://www.gnuplot.info/development/binaries/ >>> >>> Please test them thoroughly so that we can make them available to the >>> public. >> >> What's the status on this - should it be moved/copied to the SourceForge >> download site? >> >> Ethan >> > > The only feedback so far was from Hans-Bernhard. I am reluctant > to proceed with the release because the "-persist" mode is broken in > current CVS and 4.6.2 on Windows in two ways: First of all it is not > working at all. Apparently a code snippet for Windows got removed by > accident on Feb 3rd. Second, even if it would work, it would still > create zombie processes if the wxt terminal is used, see bug #1103. > This bug has been fixed in CVS and I am working on backporting it > together with some other fixes to the 4.6 tree. > > Bastian > I just uploaded new binaries which include a few fixes backported from 4.7. The -persist mode (Bugs #1103 and #1145) should now be fixed. Happy testing! Bastian |
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-11 20:12:16
|
On Friday, April 05, 2013 12:08:04 pm Bastian Märkisch wrote: > > I just uploaded new binaries which include a few fixes backported from > 4.7. The -persist mode (Bugs #1103 and #1145) should now be fixed. Happy > testing! I have just bumped the 4.6 cvs repository to patchlevel 3. Yes it's only been a month since the 4.6.2 release, but Bastian has updated the Windows support in order to prepare Windows distribution packages and I don't like the idea of having the linux and windows package contents be out of sync. Also there were a couple of regressions in 4.6.2 having to do with color handling ( monochrome option not always respected, fill and text colors out of sync in some of the latex terminals ) that we might as well take the opportunity to fix. Bastian: Can you re-run your packaging scripts with the current (i.e. 4.6.3) CVS source? Then we can put both an updated tarball and the windows packages on SourceForge labelled as 4.6.3. Ethan -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742 |
|
Re: 4.6.3 to include windows update [was: Any last-minute fixes or
requests for inclusion in 4.6.2?]
From: Bastian M. <bma...@we...> - 2013-04-12 16:42:17
|
Am 11.04.2013 22:11, schrieb Ethan Merritt: > On Friday, April 05, 2013 12:08:04 pm Bastian Märkisch wrote: >> >> I just uploaded new binaries which include a few fixes backported from >> 4.7. The -persist mode (Bugs #1103 and #1145) should now be fixed. Happy >> testing! > > I have just bumped the 4.6 cvs repository to patchlevel 3. > Yes it's only been a month since the 4.6.2 release, but Bastian has updated > the Windows support in order to prepare Windows distribution packages and I > don't like the idea of having the linux and windows package contents be out > of sync. > > Also there were a couple of regressions in 4.6.2 having to do with > color handling ( monochrome option not always respected, > fill and text colors out of sync in some of the latex terminals ) > that we might as well take the opportunity to fix. > > Bastian: > > Can you re-run your packaging scripts with the current (i.e. 4.6.3) > CVS source? Then we can put both an updated tarball and the > windows packages on SourceForge labelled as 4.6.3. > You can now find Windows binary packages for 4.6.3 at http://www.gnuplot.info/development/binaries/ Bastian |
