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

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

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.