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

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