From: Hans-Bernhard B. <br...@ph...> - 2004-07-13 01:41:28
|
On Mon, 12 Jul 2004, Petr Mikulik wrote: > Gnuplot version cycle is at about 5 years. Where did you pick up that number? From where I stand, gnuplot has no version cycle expressable in terms of time to speak of. And it hasn't had one ever since Alex Woo's released his last 3.5 in 1993. Ever since the 3.6-beta phase, we've always stated that we do *not* plan ahead in terms of time, but rather release when we think the stuff is ready. > Well, Octave is a major application using gnuplot, and we should wait until > they get accustomed to new gnuplot Them getting accustomed is not the point --- them using our latest work-in-progress snapshot, while not willing to keep their own software at least roughly up to date, is. If they want to use bleeding-edge gnuplot without taking proper care: fine, let them cut themselves. Might teach them a lesson. > We could switch off the compatibility "by default" shortly before releasing > the current cvs as gnuplot 4.1. But not before. (I could not test it, for > example.) I disagree. Breaking down compatibility bridges is something that has to be done *early* in a development cycle, like right now. Shortly before an actual release would IMHO be exactly the wrong time to make such modifications. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-13 12:40:22
|
On Tue, 13 Jul 2004, Petr Mikulik wrote: > > > Gnuplot version cycle is at about 5 years. > > > > Where did you pick up that number? > > Because that did happen. Releasing 3.7 has taken 5 years, and the same for > 4.0 (1999 -- 2004). That was pure coincidence. > > least roughly up to date, is. If they want to use bleeding-edge gnuplot > > without taking proper care: fine, let them cut themselves. Might teach > > them a lesson. > Them is for example me, or Daniel -- we managed to get imagegp.m to work > fine with Octave. Not having the compatibility would be a stop-point for > using both nice apps. No it wouldn't. It would *only* mean that imagegp.m has to use a gnuplot 4.0 executable for as long as nobody gets round to teaching it to use 'unset' instead of 'set no...'. Which I honestly can't believe to be all that complicated. At the risk of sounding like my own echo: 4.1 is strictly work-in-progress code at this time. Nobody in their right mind should even think of using this in production environments unless they're willing to update all other parts equally quickly as gnuplot. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Petr M. <mi...@ph...> - 2004-07-13 13:58:17
|
> > > > Gnuplot version cycle is at about 5 years. > > > > > > Where did you pick up that number? > > > > Because that did happen. Releasing 3.7 has taken 5 years, and the same for > > 4.0 (1999 -- 2004). > > That was pure coincidence. One popular Czech movies says: "oops, it happens once per 10 years..." .... "oops, it happens twice per 10 years..." ... > > Them is for example me, or Daniel -- we managed to get imagegp.m to work > > fine with Octave. Not having the compatibility would be a stop-point for > > using both nice apps. > > No it wouldn't. It would *only* mean that imagegp.m has to use a gnuplot > 4.0 executable for as long as nobody gets round to teaching it to use > 'unset' instead of 'set no...'. Which I honestly can't believe to be > all that complicated. Octave has built-in command gset, e.g. gset log y Thus you can do comfortably gset nolog without any need for gunset log You cannot define "function/command" gunset to be called gunset log => you can call it as function gunset('log') It looks like "gset noXXX" => "graw('unset XXXX')" backwards (script...) compatibility would have to be dereferred to Octave -- that's something I really don't like. --- PM |
From: Petr M. <mi...@ph...> - 2004-07-13 08:33:54
|
> > Gnuplot version cycle is at about 5 years. > > Where did you pick up that number? Because that did happen. Releasing 3.7 has taken 5 years, and the same for 4.0 (1999 -- 2004). > > Well, Octave is a major application using gnuplot, and we should wait until > > they get accustomed to new gnuplot > > Them getting accustomed is not the point --- them using our latest > work-in-progress snapshot, while not willing to keep their own software at > least roughly up to date, is. If they want to use bleeding-edge gnuplot > without taking proper care: fine, let them cut themselves. Might teach > them a lesson. Them is for example me, or Daniel -- we managed to get imagegp.m to work fine with Octave. Not having the compatibility would be a stop-point for using both nice apps. Currently, I have no time to do pressure or coding on Octave sources to change for the new syntax of gnuplot. Until someone implements this, and it is released in Octave, then we can start to think about removing the compatibility layer. Not before. Thus, it needs "someone" to contribute the change for Octave, not "them". --- PM |