gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Gnuplot and Octave.

[Daniel J S. <dan...@ie...>]

Ole Jacob Hagen wrote:

> Hi, again.
>
> I know Octave can get some parameters from gnuplot using gshow, which 
> will run show in Gnuplot.
> And a lot of types, parameters and properties related to current plot 
> is available here.
> All these could be collected from Octave.
>
> There is a lot of builtin functionality inside gnuplot to be used 
> within Octave, and could be interpreted as handle graphics.
> Remark that gnuplot doesn't have to support a core handle graphics. 
> Handle graphics of Matlab is very restrictive,
> and should be interpreted as some sort of Mathworks attempt to 
> generalize properties of a visualisation. 


I will agree with that.

> Gnuplot should continue in it's development regardless of handle 
> graphics.
>
> The question is whether Gnuplot is doing some housekeeping of 
> curve-data (2D & 3D), and this is retrievable in an easy way.
>
> It would be nice to be able to retrieve the curve_data which is 
> visualised. That would be perfect.
>
> I know that Octave is able to use a gshow, which will list out 
> properties as in show.  I believe I can get labels, ticks, colour and 
> format, but not the curve_data, which could be quite useful.... 


(Brainstorming questions, not proposals:)

So that would perhaps mean a set/show combination?  Hmm.  "show" used to 
display the data (i.e., transfer back to Octave) would mean putting 
things in ASCII floating point or something.  Some datasets for plots 
can get very large.

There isn't anyway to create a special terminal type that would send the 
data back to Octave somehow, is there?

In any case, from Octave's perspective it would still be better if 
Gnuplot had an internal record of _each_ plot rather than just the 
current plot, right?

Dan

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Lars H. <lhe...@us...>]

> I've updated the gnuplot.sourceforge.net/demo/ directory contents also.
> They are now html 4.0.1 transitional compliant (well almost), and can 
> should even be viewable in broken browsers like IE5.
 
 Could you also please go through the permissions of all the files you created
 (I have moved demo to demo.old, couldn't do much more with it), and make
 sure that all directories are chmod 755 (maybe 775 is better), all files
 are 664, and group ownership is always gnuplot. This will insure that all
 developers in the gnuplot group have full access to all files.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Ethan M. <merritt@u.washington.edu>]

On Friday 20 February 2004 12:18 pm, Lars Hecking wrote:
> > You could even do it yourself.  You have ssh and scp access to a shell
> > at sourceforge, and the Web site gnuplot.sf.net is writable from
> > there.  Try to work extra carefully if you decide to do that ---
> > you're working on the live site data!
>
>  I've done it.
>
>  Excellent work, Petr!

Yes. It's shaping up nicely.

I've updated the gnuplot.sourceforge.net/demo/ directory contents also.
They are now html 4.0.1 transitional compliant (well almost), and can 
should even be viewable in broken browsers like IE5.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Gnuplot and Octave.

[Ole J. H. <wat...@ya...>]

Hi, again.

I know Octave can get some parameters from gnuplot using gshow, which 
will run show in Gnuplot.
And a lot of types, parameters and properties related to current plot is 
available here.
All these could be collected from Octave.

There is a lot of builtin functionality inside gnuplot to be used within 
Octave, and could be interpreted as handle graphics.
Remark that gnuplot doesn't have to support a core handle graphics. 
Handle graphics of Matlab is very restrictive,
and should be interpreted as some sort of Mathworks attempt to 
generalize properties of a visualisation.

Gnuplot should continue in it's development regardless of handle graphics.

The question is whether Gnuplot is doing some housekeeping of curve-data 
(2D & 3D), and this is retrievable in an easy way.

It would be nice to be able to retrieve the curve_data which is 
visualised. That would be perfect.

I know that Octave is able to use a gshow, which will list out 
properties as in show.  
I believe I can get labels, ticks, colour and format, but not the 
curve_data, which could be quite useful....


Cheers

Ole J.




Daniel J Sebald wrote:

>
>
> Hans-Bernhard Broeker wrote:
>
>> On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:
>>
>>  
>>
>>> Gnuplot has visualisation properties, which could be interpreted, and
>>> used by Octave by our package. But, there is always a but. We need to
>>> make duplicate copies of datasets, which are plotted in Gnuplot, since
>>> Gnuplot doesnt send it's dataset of visualisation back.
>>>   
>>
>>
>> I don't think I see what that "dataset of visualization" you're talking
>> about is.
>>
>> Anyway: is this about 3D or 2D plots?  Or colour maps?
>>
>>  
>>
>>> This is the curve/surface data, such as X, Y and Z.
>>>   
>>
>>
>> How would these differ from the data sent from octave to gnuplot?
>>
>
> Probably most on this list are familiar with Matlab's handle graphics 
> objects, but just in case I'll summarize.  Matlab extends the concept 
> of matrices to the plot realm by associating elements of a plot to an 
> elements in a vector.  Think of these elements as "handles".  Using 
> "get" will get the vector of handles associated with a particular 
> figure.  For example, here is a short segment of code to change the 
> line width of a plot:
>
>  H = get(get(gcf,'Children'),'Children');
>  set(H(1),'LineWidth',2.0);
>
> You'll notice to use of "get" twice.  The reason is that there is a 
> hierarchy of plot elements.  For example, an axis will be an element, 
> and then under that will be other elements for the axis like text. 
> "get" alone without assignment will display all the information about 
> a handle object such as the actual text, the font type, the size of 
> the font, etc.  The sub-objects are called children.
>
> Naturally, this requires a storing of all information about the plot 
> elements.  Or, it requires some way of inquiring such information from 
> Gnuplot, if Gnuplot keeps a record of such things.  A plot line is 
> also an object and part of its characteristics is all the data points 
> associated with it.  So, this is what the original question is about. 
> Is it possible to get back the (x,y,z) information that Petr is 
> referring to from Gnuplot.
>
> A few things:
>
> 1)  This would mean that somehow information about plot data would 
> need to be sent back to Octave through the pipe so that Octave could 
> interpret it and use it in a handle graphics fashion.  I'm not sure if 
> Gnuplot is set up to do such a thing.
>
> 2)  It would then seem that to do this would require the strategy 
> that, I think it was, Hans has mentioned about each Gnuplot plot 
> storing all information so that it can be retrieved.  (I assume same 
> goes for all other elements like labels, etc.)  From Gnuplot's 
> perspective, this was for allowing the mouse to zoom on not only the 
> most recent plot, but all plots in X11.  But here would be an example 
> of another use.
>
> 3)  I don't know what Ole has in mind, but I assume that this concept 
> has to be extended to all other graph objects, i.e., labels and so on. 
> That is, either Gnuplot is the one to keep track of all the 
> retrievable information, or Octave is the one.
>
> You may be wondering, how does one know what the hierarchy is Matlab? 
> That is, how did I know to use "get" twice in the above script example 
> and then select element H(1) from the array of handle objects?  Well, 
> one has to simply display the information, following the hierarchy of 
> children down to the object of interest.  It isn't the most apparent 
> logic as to how things are grouped, but perhaps once you get used to 
> it, things become easier.
>
> However, I'm going to give my experience about this, and keep in mind 
> that this is opinion.  (Repeat OPINION!)  I was exposed to Matlab 
> before Octave so the handle object approach is what I first used to 
> customize plots.  I never found it easy to use; quite arduous 
> actually.  The searching through children of children of children part 
> is what gets to one after while.  Switching over to Octave, I found 
> that using "gset" and the Gnuplot customizing commands a bit easier to 
> use.  The handle graphics approach is to create the graphics objects 
> and then go back and modify them (going through the handle hierarchy 
> in the process).  The Gnuplot approach is to set the object property 
> at the same time the object is created, and be done with it.  In 
> Gnuplot, setting a default property is often very easy as well.
>
> I could say more here, but I will leave it open for further comment 
> from others.
>
> Dan
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Lars H. <lhe...@us...>]

 
> > If you agree, and who has the rights, please unzip that creature at the
> > appropriate place.
> 
> You could even do it yourself.  You have ssh and scp access to a shell at
> sourceforge, and the Web site gnuplot.sf.net is writable from there.  Try
> to work extra carefully if you decide to do that --- you're working 
> on the live site data!
 
 I've done it.

 Excellent work, Petr!

Re: New bug :-( Re: Release plan for gnuplot 4.0

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Ethan Merritt wrote:

> I am pretty sure that the negative values are themselves a
> result of some upstream error that I haven't found yet.

The key to this error is that the key is positioned like this, throughout
this script:

> grep key ../../demo/electron.dem
set key box
set key .2,.0045
unset key
set key on

The values .2 and .0045 are still stored at the time the third plot
is made, and they're way out of range.  Actually, you won't see any
key in the third plot if you actually plot it.

> Maybe someone else can spot it?

I.e. it's either an outright error in the demo script, or an oversight
in the implementation of 'set key on'.  I would say it's the former.

I'm checking in a change to electron.dem to make that a 'set key default'.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Petr Mikulik wrote:

> I think that
> 	gnuplot.sourceforge.net
> can be replaced by my creature
> 	gpweb-004.zip

If I hadn't misplaced my reference as where you have it, it could ;-)

> If you agree, and who has the rights, please unzip that creature at the
> appropriate place.

You could even do it yourself.  You have ssh and scp access to a shell at
sourceforge, and the Web site gnuplot.sf.net is writable from there.  Try
to work extra carefully if you decide to do that --- you're working 
on the live site data!

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Gnuplot and Octave

[Ole J. H. <wat...@ya...>]

Ok, lets clearify.
Sorry to be some unprecise for what I want to do.
If you are familiar with handle graphics of Matlab, you already know 
that using the following command:
h = plot3(x,y,z); // a plot appear.
Let's say you are using x and y to something else later on, and want to 
get the dataset used for generation of plot, then you'll can get these by:
X = get(h,'XData'); Y = get(h, 'YData') and Z = get(h, 'ZData')

I want to get these data from gnuplot, is this possible?
Now you are asking yourself, why would you get data from gnuplot, since 
you already got them?
Well, for two reasons:

1. There is visualisation application that can change the dataset and 
appearance used for visualisation runtime, and some of these might aim 
for Octave.
2. Matlab compatibility.


Cheers,

Ole J.

Re: Gnuplot and Octave.

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:
>
>  
>
>>Gnuplot has visualisation properties, which could be interpreted, and
>>used by Octave by our package. But, there is always a but. We need to
>>make duplicate copies of datasets, which are plotted in Gnuplot, since
>>Gnuplot doesnt send it's dataset of visualisation back.
>>    
>>
>
>I don't think I see what that "dataset of visualization" you're talking
>about is.
>
>Anyway: is this about 3D or 2D plots?  Or colour maps?
>
>  
>
>>This is the curve/surface data, such as X, Y and Z.
>>    
>>
>
>How would these differ from the data sent from octave to gnuplot?
>

Probably most on this list are familiar with Matlab's handle graphics 
objects, but just in case I'll summarize.  Matlab extends the concept of 
matrices to the plot realm by associating elements of a plot to an 
elements in a vector.  Think of these elements as "handles".  Using 
"get" will get the vector of handles associated with a particular 
figure.  For example, here is a short segment of code to change the line 
width of a plot:

  H = get(get(gcf,'Children'),'Children');
  set(H(1),'LineWidth',2.0);

You'll notice to use of "get" twice.  The reason is that there is a 
hierarchy of plot elements.  For example, an axis will be an element, 
and then under that will be other elements for the axis like text. 
 "get" alone without assignment will display all the information about a 
handle object such as the actual text, the font type, the size of the 
font, etc.  The sub-objects are called children.

Naturally, this requires a storing of all information about the plot 
elements.  Or, it requires some way of inquiring such information from 
Gnuplot, if Gnuplot keeps a record of such things.  A plot line is also 
an object and part of its characteristics is all the data points 
associated with it.  So, this is what the original question is about. 
 Is it possible to get back the (x,y,z) information that Petr is 
referring to from Gnuplot.

A few things:

1)  This would mean that somehow information about plot data would need 
to be sent back to Octave through the pipe so that Octave could 
interpret it and use it in a handle graphics fashion.  I'm not sure if 
Gnuplot is set up to do such a thing.

2)  It would then seem that to do this would require the strategy that, 
I think it was, Hans has mentioned about each Gnuplot plot storing all 
information so that it can be retrieved.  (I assume same goes for all 
other elements like labels, etc.)  From Gnuplot's perspective, this was 
for allowing the mouse to zoom on not only the most recent plot, but all 
plots in X11.  But here would be an example of another use.

3)  I don't know what Ole has in mind, but I assume that this concept 
has to be extended to all other graph objects, i.e., labels and so on. 
 That is, either Gnuplot is the one to keep track of all the retrievable 
information, or Octave is the one.

You may be wondering, how does one know what the hierarchy is Matlab? 
 That is, how did I know to use "get" twice in the above script example 
and then select element H(1) from the array of handle objects?  Well, 
one has to simply display the information, following the hierarchy of 
children down to the object of interest.  It isn't the most apparent 
logic as to how things are grouped, but perhaps once you get used to it, 
things become easier.

However, I'm going to give my experience about this, and keep in mind 
that this is opinion.  (Repeat OPINION!)  I was exposed to Matlab before 
Octave so the handle object approach is what I first used to customize 
plots.  I never found it easy to use; quite arduous actually.  The 
searching through children of children of children part is what gets to 
one after while.  Switching over to Octave, I found that using "gset" 
and the Gnuplot customizing commands a bit easier to use.  The handle 
graphics approach is to create the graphics objects and then go back and 
modify them (going through the handle hierarchy in the process).  The 
Gnuplot approach is to set the object property at the same time the 
object is created, and be done with it.  In Gnuplot, setting a default 
property is often very easy as well.

I could say more here, but I will leave it open for further comment from 
others.

Dan

Re: New bug :-( Re: Release plan for gnuplot 4.0

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Ethan Merritt wrote:

> I am pretty sure that the negative values are themselves a
> result of some upstream error that I haven't found yet.
> Maybe someone else can spot it?

Here's what's happening (using the X11 terminal for simplicity, and
a conditional break point on negative results in map_position()):

#0  map_position (pos=0x810f028, x=0xbfffe49c, y=0xbfffe4a0,
    what=0x80ed754 "key") at ../../src/graphics.c:3813
#1  0x08065c8f in boundary (plots=0x812a738, count=2)
    at ../../src/graphics.c:909
#2  0x080666d1 in do_plot (plots=0x812a738, pcount=2)
    at ../../src/graphics.c:1189
#3  0x080850c4 in eval_plots () at ../../src/plot2d.c:1616
#4  0x08050d88 in command () at ../../src/command.c:511
#5  0x08050959 in do_line () at ../../src/command.c:368

(gdb) info loc
x = (unsigned int *) 0xbfffe49c
y = (unsigned int *) 0xbfffe4a0
xx = -13.5
yy = -4067.5

That call's coming from here:

907             } else {
908                 unsigned int x, y;
909                 map_position(&key->user_pos, &x, &y, "key");

followed immediately by the somewhat suspicious:

910     #if 0
911     /* FIXME!!!
912     ** pm 22.1.2002: if key->user_pos.scalex or scaley == first_axes 
or seco
...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

New bug :-( Re: Release plan for gnuplot 4.0

[Ethan M. <merritt@u.washington.edu>]

On Friday 13 February 2004 06:03 am, Petr Mikulik wrote:
> I think there is no serious bug for 3.8k -- bug please check it.

Just found one:

gnuplot> set term pdf
gnuplot> set output 'test.pdf'
gnuplot> load 'electron.dem'
Hit return to continue
Hit return to continue
PDFlib value error: floating point value too large in pdf_ftoa
<program exits>


I have not yet tracked down the true origin of the error, but
the specific trigger of the error is the following problematic
bit of code from graphics.c:

/*{{{  map_position, wrapper, which maps double to int */
void
map_position(pos, x, y, what)
struct position *pos;
unsigned int *x, *y;
const char *what;
{
    double xx, yy;
    map_position_double(pos, &xx, &yy, what);
    *x = xx;
    *y = yy;
}

The problem is that in this case map_position_double is returning
negative numbers in xx and yy.  These are then stored as unsigned
in x and y and nothing good can happen after that.

I am pretty sure that the negative values are themselves a
result of some upstream error that I haven't found yet.
Maybe someone else can spot it?

By the way, this error is in principle not specific to pdf output.
But the other terminal types that I have tried just ignore subsequent
moveto/lineto requests as being outside the plot boundaries, wheres
the pdflib complains and exits.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Petr M. <mi...@ph...>]

> > OK, so it'll have to be me, then.  I'll see if I can prepare a tarball
> > for upload to SF.net before the weekend.
>
> Done. Tarball's up at SF.net, announcement to newsgroup is out.

Very good!

I think that
	gnuplot.sourceforge.net
can be replaced by my creature
	gpweb-004.zip

It links to www.gnuplot.info for those who are not interested in this
prerelease. Similarly, it would be worth if www.gnuplot.info contains link
to the new 3.8k page.

If you agree, and who has the rights, please unzip that creature at the
appropriate place.

Then we can reference to the new page.

---
PM

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Thu, 19 Feb 2004, Hans-Bernhard Broeker wrote:

> On Thu, 19 Feb 2004, Lars Hecking wrote:
> 
> >  If you want to go ahead with a release, fine. I have _zero_ time for
> >  non-work stuff right now, and the situation will not improve in the
> >  short term.
> 
> OK, so it'll have to be me, then.  I'll see if I can prepare a tarball
> for upload to SF.net before the weekend.

Done. Tarball's up at SF.net, announcement to newsgroup is out.  

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Petr Mikulik wrote:

> > > - missing Windows et al terminal entries to be added, if contributed
> >
> > "missing terminal entries"?  I don't think I see what you're talking about
> > there.
> 
> Sorry, it was not exact -- there are several of the unimplemented --
> according to the TODO file:
> 
>   -- rotated text is not supported
>         demo/textrotate.dem does not pass correctly
>   -- palette colored text is not supported
>         demo/textcolor.dem does not pass correctly

There's nothing strictly wrong with optional features actually not
implemented by a particular driver.  As long as the demo doesn't break
(i.e. gnuplot all.dem exits), that's not a big deal.

> and some other items, like
>   -- update wgnuplot menus

They've been updated in 01'2003.  If you see any more badly missing
things, go ahead and add them --- the syntax is easy enough.

>   -- windows driver does not report font size to windows.trm, thus
>      character widht and height are quite useless numbers
> 
> These things, if someone contributes them, should be added, right?

*If*.  And if the changes aren't too massive to invalidate pretty 
much all the testing being done with the existing code.

> > You *do* seem pretty allergic to the word "April", Petr.... something
> > particular about it? ;-)
> 
> Maybe I like more winter than spring?

March 31st is in spring too. ;->

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

[Petr M. <mi...@ph...>]

> But, there is always a but. We need to make duplicate copies of
> datasets, which are plotted in Gnuplot, since Gnuplot doesnt send it's
> dataset of visualisation back.
> This is the curve/surface data, such as X, Y and Z.

These datasets are send to gnuplot via data files, so you can use those (=
their filenames), so you don't have to keep the data.

> Can Gnuplot do this today, and if it can how? I am unable to find any
> documentation about it.
> I am reading source-code, and tries to find out where to attack this
> problem.....

Gnuplot does not store data as
  double *x, *y;
but as
  struct gnuplot's_point_structure *pt
(for 3d organized in struct gnuplot's_iso_lines).

In principle, for future, gnuplot could be implemented for things like
reading from binary files like "/sharedmem/DataFromOctave" instead from
ascii data files (binary support is already in the "with image" patch by
Daniel).

---
PM

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Petr M. <mi...@ph...>]

> > - source code tarball
> > - binary releases for MSW 32bit, OS/2, (and some 16bit?), will full docs
> > - maybe some RPM package?
>
> No RPMs of 3.8k.

Ok, I just wanted we make "guideline" binary packages with all docs, demo et
al what should be inside.

> > - missing Windows et al terminal entries to be added, if contributed
>
> "missing terminal entries"?  I don't think I see what you're talking about
> there.

Sorry, it was not exact -- there are several of the unimplemented --
according to the TODO file:

  -- rotated text is not supported
        demo/textrotate.dem does not pass correctly
  -- palette colored text is not supported
        demo/textcolor.dem does not pass correctly

and some other items, like
  -- update wgnuplot menus
  -- windows driver does not report font size to windows.trm, thus
     character widht and height are quite useless numbers

These things, if someone contributes them, should be added, right?
(Some people can think of them as bugs, others missing features.)


> You *do* seem pretty allergic to the word "April", Petr.... something
> particular about it? ;-)

Maybe I like more winter than spring?
Well, the point is I though gnuplot 4.0 could be released in December, and
now I see how months are passing and passing...

---
PM

Re: Gnuplot and Octave.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:

> Gnuplot has visualisation properties, which could be interpreted, and
> used by Octave by our package. But, there is always a but. We need to
> make duplicate copies of datasets, which are plotted in Gnuplot, since
> Gnuplot doesnt send it's dataset of visualisation back.

I don't think I see what that "dataset of visualization" you're talking
about is.

Anyway: is this about 3D or 2D plots?  Or colour maps?

> This is the curve/surface data, such as X, Y and Z.

How would these differ from the data sent from octave to gnuplot?

> 

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Petr Mikulik wrote:

> > allow at least a couple of weeks between 3.8k.0 release and 4.0, there's
> > no point doing a 3.8k in the first place.
> >
> > important platforms.  For the 16-bit DOS/Windows and part of the Win32
> >
> > We're talking about roughly 6 weeks, here, or 1.5 months.  That's not
> > exactly very much.  The code freeze is for *us* to worry about.
> 
> Ok, thus gnuplot-3.8k is released now, including:
> - source code tarball
> - binary releases for MSW 32bit, OS/2, (and some 16bit?), will full docs
> - maybe some RPM package?

No RPMs of 3.8k.  We'll leave that to the Linux distributors who 
integrate the actual release version, if and when they decide to do so.

> We want that
> - bugs are reported
> - missing Windows et al terminal entries to be added, if contributed

"missing terminal entries"?  I don't think I see what you're talking about
there.

> Announcement should go to all principal application groups -- Octave mailing
> list, maybe slashdot and similar? (in CZ, e.g. www.root.cz)

Slashdot: no.  But freshmeat should be updated.

I'll send an announcement gnuplot's own lists (including the newsgroup).
If some of you know other places that should receive an announcement,
forward it to them once I've posted it.

> Deadline for 4.0 should be specified. I would like March 31 (5 weeks) ..
> somehow I fear April is quite late. 

You *do* seem pretty allergic to the word "April", Petr.... something 
particular about it? ;-)

> (It would be great if new gnuplot goes
> into some important Linux distro, like SuSE 9.1. -- if not, it's about
> loosing half year then!)

It feels like there's an average of at least one major Linux distro being
updated every month. No matter when we release, we'll have missed the
release freeze of half of them by half a release interval.... that's
really nothing we should worry about.

> > What with the "ask Thomas Williams about it" business and all, an official
> > release cycle of gnuplot is difficult enough that we don't need the
> > additional complexity of a 4.0.1 fix-up release four weeks later.
> 
> I see. Does he (and other people) have to agree with 4.0 and with any of its
> further releases?

Yes. Tom Williams (and some others, for individual source files) has final
say over any "official" release --- that's what the gnuplot Copyright
statement says, like it or not.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Petr M. <mi...@ph...>]

> allow at least a couple of weeks between 3.8k.0 release and 4.0, there's
> no point doing a 3.8k in the first place.
>
> important platforms.  For the 16-bit DOS/Windows and part of the Win32
>
> We're talking about roughly 6 weeks, here, or 1.5 months.  That's not
> exactly very much.  The code freeze is for *us* to worry about.

Ok, thus gnuplot-3.8k is released now, including:
- source code tarball
- binary releases for MSW 32bit, OS/2, (and some 16bit?), will full docs
- maybe some RPM package?

We want that
- bugs are reported
- missing Windows et al terminal entries to be added, if contributed

New web page can be put on as well, saying about 3.8k as prerelease.

Announcement should go to all principal application groups -- Octave mailing
list, maybe slashdot and similar? (in CZ, e.g. www.root.cz)

Deadline for 4.0 should be specified. I would like March 31 (5 weeks) ..
somehow I fear April is quite late. (It would be great if new gnuplot goes
into some important Linux distro, like SuSE 9.1. -- if not, it's about
loosing half year then!)


> > As I've noticed, there were no (serious) bug reports for some months.
>
> But you don't seem to take into account that the vast majority of users
> out there are likely not using the 3.8 series to begin with

As I know, that majority refuses to use software not officially released.
So they won't care about 3.8k anyway.


> What with the "ask Thomas Williams about it" business and all, an official
> release cycle of gnuplot is difficult enough that we don't need the
> additional complexity of a 4.0.1 fix-up release four weeks later.

I see. Does he (and other people) have to agree with 4.0 and with any of its
further releases?

---
pm

Gnuplot and Octave.

[Ole J. H. <wat...@ya...>]

Hi, gnuplotters.

Gnuplot is used as the visualisation application to Octave, pr. default.
There is a project going on, that will be compatible with Handle 
Graphics Objects of MATLAB.
To avoid any future copyright infringement, we've decided to make a new 
name for our package.

Gnuplot has visualisation properties, which could be interpreted, and 
used by Octave by our package.
But, there is always a but. We need to make duplicate copies of 
datasets, which are plotted in Gnuplot, since Gnuplot doesnt send it's 
dataset of visualisation back.
This is the curve/surface data, such as X, Y and Z.

It there any way to get this data, instead of keeping two copies inside 
Octave? There is two copies of the same dataset already, which resides 
in Octave and Gnuplot.

Can Gnuplot do this today, and if it can how? I am unable to find any 
documentation about it.
I am reading source-code, and tries to find out where to attack this 
problem.....


Cheers,

Ole J.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Thu, 19 Feb 2004, Daniel J Sebald wrote:
>
>  
>
>>Hans-Bernhard Broeker wrote:
>>    
>>
>
>  
>
>>>it's time for last-minute checking before 4.0 release, run their own
>>>tests, and report whatever showstoppers they might find.  If we don't
>>>      
>>>
>
>  
>
>>Who are the "people out there", other than the developers?  
>>    
>>
>
>I'm talking about a publicly announced release-candidate test here.
>I.e. we would post to all the relevant mailing lists and newsgroups
>that there's a release coming up, and whoever feels like it should
>get their package and try it out.  It may be necessary to provide at
>least some prebuilt binaries for platforms that don't routinely come 
>with a C compiler (DOS, Windows and OS/2, e.g.) at SF.net.
>  
>

<snip>

Sounds like a good plan, Hans.

>>3)  Make a release and let the large group of end users find any bugs.
>>    
>>
>
>That would be the usual approach in open-source projects, "Release early,
>release often".  Unfortunately, releases of gnuplot are tricky enough to
>organize to make this a non-option.
>  
>

Oh, that I'm not suggesting.  Yes, releasing a new version often is bad. 
 Neither is not often releasing a new version very good.

Dan

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Thu, 19 Feb 2004, Daniel J Sebald wrote:

> Hans-Bernhard Broeker wrote:

> >it's time for last-minute checking before 4.0 release, run their own
> >tests, and report whatever showstoppers they might find.  If we don't

> Who are the "people out there", other than the developers?  

I'm talking about a publicly announced release-candidate test here.
I.e. we would post to all the relevant mailing lists and newsgroups
that there's a release coming up, and whoever feels like it should
get their package and try it out.  It may be necessary to provide at
least some prebuilt binaries for platforms that don't routinely come 
with a C compiler (DOS, Windows and OS/2, e.g.) at SF.net.

> 1)  Wait a couple months while the "beta testers" try it out and find 
> some bugs before releasing to the large group of end users.

A couple of weeks will be enough to that, I guess.  Easter is in 6 weeks,
which is in about the right timeframe and a nicely memorizable date.

> 2)  Consider the group of developers to be the beta testers.

That would be pointless, I think. We've all been running this stuff
routinely for ages --- the remaining ugly bugs, if any, will now be hidden
in places where none of us ever looks.  We need external eyes and
exercises for that.

> 3)  Make a release and let the large group of end users find any bugs.

That would be the usual approach in open-source projects, "Release early,
release often".  Unfortunately, releases of gnuplot are tricky enough to
organize to make this a non-option.

> Approach 1 means a group of beta testers is required. Is there such a 
> group?  

No. We'll have to go public and call for volunteers for that.

> testing it for a couple weeks.  But I don't think we could ask them to 
> keep getting updates, so it would have to be fairly close to the actual 
> 4.0 release.  

I don't think we either should or can have more than one, maximum two such
release candidates.  I.e. we'll informally declare 3.8k (to be released
ASAP) as release candidate #1 and call to the user mailing list for
pre-release testing of that.  An RC #2 will only be made if we get so
swamped in bug reports that we must assume the fixes for them will break
something else or interact with each other.  Otherwise, we fix what is
found, and I bundle up a release tarball.

>  I doubt any beta tester would have found the bug, 

You just disproved yourself by counter-example.  You yourself were the
beta-tester who found it. ;-)  You may not have started out to do it with
the term "beta-test" in mind, but that's essentially what you did.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Thu, 19 Feb 2004, Lars Hecking wrote:

>  If you want to go ahead with a release, fine. I have _zero_ time for
>  non-work stuff right now, and the situation will not improve in the
>  short term.

OK, so it'll have to be me, then.  I'll see if I can prepare a tarball
for upload to SF.net before the weekend.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Thu, 19 Feb 2004, Petr Mikulik wrote:
>
>  
>
>>Why should we wait till April? 
>>    
>>
>
>The April timeline was essentially my invention.
>
>It's to give "4.0 release candidate 0" (that is, 3.8k) some time to
>settle: let people out there actually download it after we announce that
>it's time for last-minute checking before 4.0 release, run their own
>tests, and report whatever showstoppers they might find.  If we don't
>allow at least a couple of weeks between 3.8k.0 release and 4.0, there's
>no point doing a 3.8k in the first place.  Assuming we can fix all issues
>they find in a matter of days would be unprudent.
>
>We also have to organize and carry out binary package builds for all the
>important platforms.  For the 16-bit DOS/Windows and part of the Win32
>world, that usually means _I_ will be doing it, and I'm not in a position
>to rush things like that, right now.
>

Who are the "people out there", other than the developers?  I guess 
there are a few alternatives:

1)  Wait a couple months while the "beta testers" try it out and find 
some bugs before releasing to the large group of end users.
2)  Consider the group of developers to be the beta testers.
3)  Make a release and let the large group of end users find any bugs.
4)  Leave some bugs in so that people have to keep buying an upgrade.

Approach 4 isn't the name of the game here.  (Say no more.)

Approach 1 means a group of beta testers is required.  Is there such a 
group?  I could perhaps send a note to the Octave developers list and 
ask if one or two people would mind getting the latest release and 
testing it for a couple weeks.  But I don't think we could ask them to 
keep getting updates, so it would have to be fairly close to the actual 
4.0 release.  Unless there are some beta testers out there, I don't see 
the sense of this approach.  Approach 1 could be a false sense of security.

Approach 2 is what Petr was saying about no bugs being found lately. 
 That along with the fact that developers here are fairly conscientious 
about shaking bugs out means approaches 2 and 3 combined may be the best 
one can hope for.

I would argue that the best testing facility we have is to run all the 
demos in all the output terminals and verify they are correct.  I mean, 
last year through a demo I found a really obscure palette bug that took 
some while to explain to Petr because the scenario had to be just right. 
 I doubt any beta tester would have found the bug, or perhaps would have 
even realized it was a bug.  It seems that almost every new feature that 
comes along has an associated demo to go along with it.

>>I've noticed people (including some developers!) get very frustrated that
>>gnuplot gets releases in timescale of several years. That really makes
>>people disappointed. Let's don't do that.
>>    
>>
>
>Let me turn that around by looking at the facts.  3.7.3 is 14 months old
>right now.  That's neither so long ago that we absolutely have to release
>something new very soon now, nor is it so short that delaying for another
>month or even two would seem excessive in comparison.  
>
>We are in no hurry unless we impose one on ourselves.
>
>  
>
>>I propose to release 4.0 on February 27. Or even better on Sunday
>>February 29, which better follows gnuplot's release timescales :-))
>>    
>>
>
>No, that's definitely too early.
>

The one month, two month time frame is no problem.  However, I think it 
is a good idea to settle on a release date and stick to it.  This "let's 
release in this month" and then two months after that still nothing has 
happened is the problem.  It is nice to set some goals of what one would 
like to have in a certain release and by when it should be made 
available.  I realize this isn't a commercial software development 
venture, but it can be frustrating to work on something only to have it 
sit in a 3/4 finished state.

I'm not trying to sound alarmist, but my impression is that Octave 
developers may look at Gnuplot as having stagnated.  I think I relayed a 
note here from the Octave developers list a couple months back of 
someone asking when another major release would be done for Gnuplot. 
 Also, there has been a small degree of discussion on that list of other 
forms of graphics drivers for Octave.  Maybe I'm exagerating.  (Maybe an 
industry survey is in order so that we can provide more product value 
for the customer's dollar, etc.)

Dan

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Lars H. <lhe...@us...>]

 
> Let's leave that to Lars, shall we?
 
 If you want to go ahead with a release, fine. I have _zero_ time for
 non-work stuff right now, and the situation will not improve in the
 short term.