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

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

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

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.

> Do you think that anybody will take care about looking to the frozen
> code of gnuplot for months?

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.  It's
about concentrating entirely on bug fixes, while setting aside work on new
features for the time being.
 
> 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 --- all the
major Linux distros have 3.7.3 or older.  The point of a 3.8k release and
a couple of weeks' wating is to get as many of the dormant bugs out into
the light before the actual release version as possible.  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'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.

> And release gnuplot-3.8k today.

Let's leave that to Lars, shall we?

-- 
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

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

On Thursday 19 February 2004 07:01 am, Petr Mikulik wrote:
> > > > 3.8k ASAP, and a release of 4.0 on, say, Easter (mid-April).
> > >
> > >  No objections. Altough I think code freezes have never worked
> > > around here ...
> >
> > 	6) release the 4.0 version in April
>
> Why should we wait till April? Do you think that anybody will take care
> about looking to the frozen code of gnuplot for months?

I only said April because I was responding to a proposal that mentioned
April.  I agree with you that sooner is better.







>
> As I've noticed, there were no (serious) bug reports for some months.
>
> 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.
>
> > The 1000th changelog entry for the trunk!  If that's not something to
> > be celebrated by a release, what could be?
>
> I propose to release 4.0 on February 27.
> Or even better on Sunday February 29, which better follows gnuplot's
> release timescales :-))
>
>
> With this strict deadline, people (at least on this list) will be
> strongly motivated to make fastly all tests. I fear that for April,
> nobody will have enough motivation.
>
> And release gnuplot-3.8k today.
>
> ---
> Petr Mikulik
>
>
>
> -------------------------------------------------------
> 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

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

release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

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

> > > 3.8k ASAP, and a release of 4.0 on, say, Easter (mid-April).
> >
> >  No objections. Altough I think code freezes have never worked around
> > here ...
>
> 	6) release the 4.0 version in April

Why should we wait till April? Do you think that anybody will take care
about looking to the frozen code of gnuplot for months?

As I've noticed, there were no (serious) bug reports for some months.

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.


> The 1000th changelog entry for the trunk!  If that's not something to
> be celebrated by a release, what could be?

I propose to release 4.0 on February 27.
Or even better on Sunday February 29, which better follows gnuplot's release
timescales :-))


With this strict deadline, people (at least on this list) will be strongly
motivated to make fastly all tests. I fear that for April, nobody will have
enough motivation.

And release gnuplot-3.8k today.

---
Petr Mikulik

Gnuplot release (was Re: GP_ISVAR, GP_FIT_ERRVARS)

[Dmitri A. S. <dm...@un...>]

Ethan Merritt wrote:

> Is it possible to proceed in the following stages?
> 	1) release 3.8k

	Call it 4.0 _now_, please?

> 	2) branch off a clean tree for a code-frozen 4.0
> 	3) rename the main CVS development tree 4.1a
> 	4) allow development work to continue in the 4.1a tree
> 	5) bug-fixs (only) get applied also to the frozen 4.0 copy


The rational for this is that having 4.0 "stable" release put
pressure on distributions to include it.
And by distributions I do not mean only Linux (yes, I know,
Debian and Conectiva had gnuplot-3.8 included), but also
things like sunfreeware.com etc...

That will expose gnuplot to significantly large pool
of different environments and will facilitate bug
discovery.

Consider it as a plea.

Sincerely,

Dmitri.

Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Wed, 18 Feb 2004, Lars Hecking wrote:

>  
> > In other words: I would propose an immediate code freeze of all the C
> > sources (only bug-fixes, and then only if they're small), a release of
> > 3.8k ASAP, and a release of 4.0 on, say, Easter (mid-April).
>  
>  No objections. Altough I think code freezes have never worked around here ...

I've just checked in the respective changes about GP_ISVAR and 
GP_FIT_ERRVARS.  And hit a nice round anniversary, too, look:

Checking in ChangeLog;
/cvsroot/gnuplot/gnuplot/ChangeLog,v  <--  ChangeLog
new revision: 1.1000; previous revision: 1.999
done

The 1000th changelog entry for the trunk!  If that's not something to 
be celebrated by a release, what could be? 

;->

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

Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Wednesday 18 February 2004 10:00 am, Lars Hecking wrote:
> > In other words: I would propose an immediate code freeze of all the C
> > sources (only bug-fixes, and then only if they're small), a release of
> > 3.8k ASAP, and a release of 4.0 on, say, Easter (mid-April).
>
>  No objections. Altough I think code freezes have never worked around
> here ...

Is it possible to proceed in the following stages?
	1) release 3.8k
	2) branch off a clean tree for a code-frozen 4.0
	3) rename the main CVS development tree 4.1a
	4) allow development work to continue in the 4.1a tree
	5) bug-fixs (only) get applied also to the frozen 4.0 copy
	6) release the 4.0 version in April 

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

Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Wed, 18 Feb 2004, Petr Mikulik wrote:

> What about:
> 
> - GP_ISVAR: not have flag "EXPERIMENTAL"
> 
> - GP_FIT_ERRVARS: not have flag "EXPERIMENTAL", and define this feature by
> default?

Assuming we agree on these two, that will leave only a single group of
features currently declaring themselves EXPERIMENTAL: the GGI terminal
driver with its sub-option xmi.

Anybody got an opinion about that one?  This was mostly done by Johannes
Zellner, who seems to have vanished.  Are you still out there reading 
this, joze?

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

Re: GP_ISVAR, GP_FIT_ERRVARS

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

 
> In other words: I would propose an immediate code freeze of all the C
> sources (only bug-fixes, and then only if they're small), a release of
> 3.8k ASAP, and a release of 4.0 on, say, Easter (mid-April).
 
 No objections. Altough I think code freezes have never worked around here ...

Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Wed, 18 Feb 2004, Ethan Merritt wrote:

> On Wednesday 18 February 2004 12:34 am, Petr Mikulik wrote:
> 
> > What about:
> >
> > - GP_ISVAR: not have flag "EXPERIMENTAL"
> 
> It's been in by default since last July.  There have been no
> bug reports, and anyway it's harmless if you don't use it.

If you didn't happen to use a function strangely named 'isvar()' in your
scripts, that is ;-P An off chance, sure, but still not a negligible one.

> I propose to make them both permanent by removing the
> #ifdef/#endif pairs. This would contribute to general code
> cleanup and simplification.  Any objections?

Objection, y'ronner.

We have a reasonably trusted code base right now.  Let's avoid making any
modifications that aren't strictly needed to get important things done.  
I don't think removing options from ./configure is important.

In other words: I would propose an immediate code freeze of all the C
sources (only bug-fixes, and then only if they're small), a release of
3.8k ASAP, and a release of 4.0 on, say, Easter (mid-April).

... Lars?

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

Re: bidirectional communication

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

On Wednesday 18 February 2004 01:52 am, Petr Mikulik wrote:
>
> Well, ad to the above problem with fifo in Octave -- why the following
> in bash does not work?
>
> bash$ mkfifo cau
> bash$ tail -f cau
>
> and in another xterm:
> gnuplot> set print "cau"
> gnuplot> print "hello"

I think that "tail -f" does not behave as expected for pipes.
Maybe it tries to use fstat() to see if the file has been extended?

Anyhow the same sequence works for me if I use "cat"
rather than "tail -f". 

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

Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Wednesday 18 February 2004 12:34 am, Petr Mikulik wrote:
> What about:
>
> - GP_ISVAR: not have flag "EXPERIMENTAL"

It's been in by default since last July.  There have been no
bug reports, and anyway it's harmless if you don't use it.

That one and the --disable-relative-boxwith option involve
such a trivial amount of code that I don't see the need to have
them conditionally compiled.

I propose to make them both permanent by removing the
#ifdef/#endif pairs. This would contribute to general code
cleanup and simplification.  Any objections?

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

Re: bidirectional communication

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

> > Well, ad to the above problem with fifo in Octave -- why the following in
> > bash does not work?
> >
> > bash$ mkfifo cau
> > bash$ tail -f cau
> >
> > and in another xterm:
> >
> > gnuplot> set print "cau"
> > gnuplot> print "hello"
> >
> > Only sometimes the text appears in the "tail", but always it gets flushed
> > after "set print" (closing print file) or quitting gnuplot -- and why it
> > works in the C demo without closing "set print"?
>
> This may well be a problem of buffering.  FIFOs are fully buffered by
> default, I think, whereas stderr, the default 'set print' output channel,
> is always completely unbuffered by C standard requirements.  I.e. it
> should help to explicitly setbuf() the channel 'set print' opened to
> unbuffered.

I've tried to put
   setvbuf(print_out, (char *) NULL, _IONBF, 0);
into print_command(), but it does not help either.

Also, when restarting gnuplot for the 2nd time and go to print to "cau",
then tail -f will not show the new text any longer.

---
Petr Mikulik

Re: GP_ISVAR, GP_FIT_ERRVARS

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

> I.e., turning this on by default could well create a new FAQ entry all by
> itself.

Otherwise there have to be FAQ how to get this feature on...

> OTOH, if any time is right for introducing such a change, the release
> of 4.0 is.  Hmmm....
>
> What the heck, let's do it.  I'm patching ./configure and relevant files
> right away.

Fine with me, let's have this feature in 4.0.

---
pm

Re: bidirectional communication

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

On Wed, 18 Feb 2004, Petr Mikulik wrote:

> And a demo for Java?

I have the (very crude) beginnings of a gpjava GUI interface.  
Interfacing the gnuplot process via a pair of pipes works, but that's
about all it does.

> ***
> 
> Well, ad to the above problem with fifo in Octave -- why the following in
> bash does not work?
> 
> bash$ mkfifo cau
> bash$ tail -f cau
> 
> and in another xterm:
> 
> gnuplot> set print "cau"
> gnuplot> print "hello"
> 
> Only sometimes the text appears in the "tail", but always it gets flushed
> after "set print" (closing print file) or quitting gnuplot -- and why it
> works in the C demo without closing "set print"?

This may well be a problem of buffering.  FIFOs are fully buffered by
default, I think, whereas stderr, the default 'set print' output channel,
is always completely unbuffered by C standard requirements.  I.e. it
should help to explicitly setbuf() the channel 'set print' opened to
unbuffered.


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

Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Wed, 18 Feb 2004, Petr Mikulik wrote:

> What about:
> 
> - GP_ISVAR: not have flag "EXPERIMENTAL"

That one can probably go in right away.

> - GP_FIT_ERRVARS: not have flag "EXPERIMENTAL", and define this feature by
> default?

I'm not really convinced about this.  We had no explicit surprise
comment about it (probably because it was disabled by default, and a 
significant fraction of our "beta-testers" actually use pre-built 
binaries, so they never ran across that option in ./configure in the
first place...), but this feature does run a significant risk of
breaking people's scripts by introducing new variables with names they
may have been using for different purposes before.

I.e., turning this on by default could well create a new FAQ entry all by
itself.

OTOH, if any time is right for introducing such a change, the release
of 4.0 is.  Hmmm....

What the heck, let's do it.  I'm patching ./configure and relevant files
right away.

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

bidirectional communication

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

I've put to the "web page" section about bidirectional communication your
program <=> gnuplot: there is C, python and m with links to files with demo
implementations.

Interestingly, the C program cannot be exactly copied into m. See those
there scripts there -- mkfifo blocks, and "set print" must be closed after
reading MOUSE_* variables from fifo. Someone has an idea?

BTW, it would be nice to have a "ginput.m" implementation for Octave --
somebody can do it?

And a demo for Java?

***

Well, ad to the above problem with fifo in Octave -- why the following in
bash does not work?

bash$ mkfifo cau
bash$ tail -f cau

and in another xterm:

gnuplot> set print "cau"
gnuplot> print "hello"

Only sometimes the text appears in the "tail", but always it gets flushed
after "set print" (closing print file) or quitting gnuplot -- and why it
works in the C demo without closing "set print"?

---
pm

Re: Release plan for gnuplot 4.0

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

> > > And is there an archive of gnuplot-beta?
>
> On closer look, we appear to have more archives than we can possibly
> use ;-)

Ok, I've released "web page" version 003:
     new script: gpsavediff
     corrected link to http://gnuplot.sourceforge.net/demo/
     links to gnuplot mailing lists archives
     section about bidirectional communication your program <=> gnuplot

---
Petr Mikulik

GP_ISVAR, GP_FIT_ERRVARS

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

What about:

- GP_ISVAR: not have flag "EXPERIMENTAL"

- GP_FIT_ERRVARS: not have flag "EXPERIMENTAL", and define this feature by
default?

---
pm

Re: faq: which terminal for OpenOffice.org

[Dmitri A. S. <dm...@un...>]

Petr Mikulik wrote:

> 
> Ad emf: here is something wrong with your fonts. On my OO-1.1 (SuSE 9.0) it
> is fine (I'm sending you printed pdf separately). (Maybe you should install
> truetype fonts?)
> 

You are right. I just tried open .sxw on another computer with TT installed
and it looked the same as yours.
So, perhaps EMF should be a recommended format for OO.org.

Thanks.

> ---
> Petr Mikulik
> 
> 

Dmitri.

Re: faq: which terminal for OpenOffice.org

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

> Then I imported them into OO.org-1.1.0 (as it came with
> Fedora Core 1 linux).
>
> All those files available at:
> http://coffee.phys.unm.edu/dima/gnuplot/
>
> I would say dxf and emf results are not acceptable.

Ad emf: here is something wrong with your fonts. On my OO-1.1 (SuSE 9.0) it
is fine (I'm sending you printed pdf separately). (Maybe you should install
truetype fonts?)

---
Petr Mikulik

Re: faq: which terminal for OpenOffice.org

[Dmitri A. S. <dm...@un...>]

Using today's (Feb 16, 2004) cvs snapshot of gnuplot I made
a plot sin(x) and cos(x) (two plots) with default parameters
for dxf (test1.dxf) and emf (test1.emf) terminals.
Then I imported them into OO.org-1.1.0 (as it came with
Fedora Core 1 linux).
I also did ps2epsi conversion of tiger.ps (from ghostscript)
and imported into the same OO.org document (test1-gnuplot.sxw).
I printed the document into file test1-gnuplot.ps.

All those files available at:
http://coffee.phys.unm.edu/dima/gnuplot/

I would say dxf and emf results are not acceptable.
I do not have any other dxf and emf viewrs, so I cannot
say wheather the problem with emf due to gnuplot or
OO.org.

Also tiger is visitable in the original .sxw document,
so OO.org does interpret bitmap correctly -- it
is just such a low resolution that makes it
unusable for ps figures with a few thin lines
(such as produced by gnuplot).


Sincerely,

Dmitri.

Re: Release plan for gnuplot 4.0

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

On Fri, 13 Feb 2004, Hans-Bernhard Broeker wrote:

> > And is there an archive of gnuplot-beta?
> 
> There used to be one, but I forgot where, 

On closer look, we appear to have more archives than we can possibly
use ;-)

http://groups.yahoo.com/group/info-gnuplot-beta/
   5001 entries, from (at least) 1997 to 2001

http://marc.theaimsgroup.com/?l=gnuplot-info-beta
   1998 to present, some double entries...

There's an ongoing archive of our current lists as part of SF.net

Geocrawler, the previous mail list archive provider for SF.net, still
keeps some archives from that time (switched over in 2002).


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

Re: faq: which terminal for OpenOffice.org

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

> >>png and bitmaps are fine; or vectorial formats, I've tried gnuplot + OO on
> >>Linux:
> >>- emf is OK, in colors
>
> Well, I have pretty recent cvs snapshot of gnuplot and emf terminal
> still screwy (or at least it looks screwy in OO.org1.1.0 on linux) --
> the "key" and the axis labels are all misplaced.

For me, emf is quite good, but:
- 'test' command ignores linewidth
- 'test' command fails character width, while "centre+d text" is centered
  almost fine?
- it ignores iso8859_2 for accented characters -- could this be changed?
- it does not support coloured filled polygons (pm3d)

> >>- dxf lacks many features
>
> Its default colors also quite off -- axes are yellow and graph is black.

Looking to dxf.trm -- there is no black color. Does dxf / AutoCad have it?

> > That "Unix ps tool" exists on all installations that have ghostscript, and
> > it's called ps2epsi.  But MS Word and others seem not to be able to
> > understand the preview image it embeds :-(
>
> The preview image has 72dpi resolution. You pretty much cannot see any default
> lines. So this method works if document is intended for printing or
> distribution as postscript/pdf.

And the embeded preview is not compressed -- the file is too big to be
useful. Aren't there some hidden options to ps2epsi?

---
Petr Mikulik

Re: Release plan for gnuplot 4.0

[James R. V. Z. <jr...@co...>]

Hans-Bernhard Broeker writes:
>On Fri, 13 Feb 2004, Petr Mikulik wrote:
>> I think there is no serious bug for 3.8k -- but please check it.
>
>Depends on what you call "serious".  I consider the log-axis ticking
>for short ranges pretty serious --- but it's a major endeavour to
>change that, which Jim van Zandt has just started to investigate.
>[BTW: any news on that, Jim?]

The current version of my program is at
   http://jrv.oddones.org/transform-0.8.tar.gz

I'd appreciate any comments.  I know there are too many unlabeled tics
at the top end of some axes.

       - Jim Van Zandt

Re: faq: which terminal for OpenOffice.org

[Dmitri A. S. <dm...@un...>]

Hans-Bernhard Broeker wrote:
> 
>>>In other words: the text, as it is right now, mostly fits OpenOffice.org.
>>
>>png and bitmaps are fine; or vectorial formats, I've tried gnuplot + OO on
>>Linux:
>>- emf is OK, in colors

Well, I have pretty recent cvs snapshot of gnuplot and emf terminal
still screwy (or at least it looks screwy in OO.org1.1.0 on linux) --
the "key" and the axis labels are all misplaced.

>>- dxf lacks many features

Its default colors also quite off -- axes are yellow and graph is black.


> That "Unix ps tool" exists on all installations that have ghostscript, and
> it's called ps2epsi.  But MS Word and others seem not to be able to
> understand the preview image it embeds :-(

The preview image has 72dpi resolution. You pretty much cannot see any default
lines. So this method works if document is intended for printing or
distribution as postscript/pdf.

Currently, my way of dealing with MSWord types is to send them postscript/pdf
and get them "cut-and-paste" thing. With OO.org on non-M$ platform, it is usually
end up being very high resolution bitmap (like 300dpi) courtesy of ghostscript.

Anyone knows if OO.org is planning to support SVG?

Sincerely,

Dmitri.