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

Re: How does ./configure interact with the demo directory?

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

On Wed, 21 Apr 2004, Petr Mikulik wrote:

> > 	wgnuplot c:\config.sys
> 
> Not like that, but
> wgnuplot
> gnuplot> load 'all.dem'
> gnuplot> load "test-me.dem'

But that's not a way we can run 'make check'.  The checks are, and have to
be, non-interactive (even the 'make check-interactive' one is), as far as
the gnuplot engine is concerned, simply because they pass filenames to
gnuplot.  And as far as wgnuplot is concerned, that means all screen
messages end up in /dev/null.

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

Re: How does ./configure interact with the demo directory?

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

> 	wgnuplot c:\config.sys

Not like that, but
wgnuplot
gnuplot> load 'all.dem'
gnuplot> load "test-me.dem'

> There *is* no stderr to be redirected, in the full GUI versions for
> Windows.  wgnuplot_pipe.exe might work, if run from a console window.
>
> > The message could use "set print" file.
>
> I don't think stderr goes there, and for a good reason, too.  We'ld need a
> special 'set error' or so to redirect error messages to a file.

Or a command line option be a solution:
  wgnuplot --stderr=log.err

--
PM

Re: pdf library for gnuplot

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

On Wed, 21 Apr 2004, Petr Mikulik wrote:

> > GPL would be out, I think --- gnuplot's license is incompatible enough
> > with the GPL that we can't distribute binaries linked to GPL code.  LGPL
> > should work, though.
> 
> What about GNU readline? Gnuplot cannot distribute binaries with that
> library? 

As I (and some rather more important other people) read the GPL: I don't
think so.  Not unless we can present legally solid analysis that proves
our license compatible with the GPL.  I don't think it is, because of
this clause in our license:

 * Permission to modify the software is granted, but not the right to
 * distribute the complete modified source code.  Modifications are to
 * be distributed as patches to the released version.

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

Re: How does ./configure interact with the demo directory?

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

On Wed, 21 Apr 2004, Petr Mikulik wrote:

> > As I recall, the objection was raised that Windows does not provide
> > any reasonable place to print such a message.
> 
> It would print it on screen.

No, it wouldn't.  Try it:
	
	wgnuplot c:\config.sys

(or whatever text file you happen to have lying around that should be
guaranteed to fail as a gnuplot script).

You'll find that nothing gets printed anywhere.  The problem is that
wgnuplot runs its own "xterm" equivalent (the text window), and that
vanishes as soon as the program exits, and isn't even made visible in
non-interactive execution.

> You mean stderr cannot be redirected to a file?

There *is* no stderr to be redirected, in the full GUI versions for 
Windows.  wgnuplot_pipe.exe might work, if run from a console window.

> The message could use "set print" file.

I don't think stderr goes there, and for a good reason, too.  We'ld need a
special 'set error' or so to redirect error messages to a file.

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

Re: pdf library for gnuplot

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

> GPL would be out, I think --- gnuplot's license is incompatible enough
> with the GPL that we can't distribute binaries linked to GPL code.  LGPL
> should work, though.

What about GNU readline? Gnuplot cannot distribute binaries with that
library? (No, it is not used in the OS/2 build.)

--
PM

Re: How does ./configure interact with the demo directory?

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

> As I recall, the objection was raised that Windows does not provide
> any reasonable place to print such a message.

It would print it on screen.
You mean stderr cannot be redirected to a file?
The message could use "set print" file.

---
PM

Re: pdf library for gnuplot

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

On Tue, 20 Apr 2004, Xiaodong Zhou wrote:

> There is another pdf lib with both GPL and LGPL license
> 
> http://www.stillhq.com/cgi-bin/getpage?area=panda

GPL would be out, I think --- gnuplot's license is incompatible enough
with the GPL that we can't distribute binaries linked to GPL code.  LGPL
should work, though.

> Could it be helpful?

Sure.  If we can find a volunteer to rewrite pdf.trm to use it instead of
PDFLib, that is, and if the parts they took out to make the whole thing
LGPL-able don't make it unuseable.

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

Re: How does ./configure interact with the demo directory?

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

On Wed, 21 Apr 2004, Lars Hecking wrote:

> Ethan Merritt writes:
> > While the dust is settling from the version 4 release,
> > I thought I'd have a go at adding a couple of new demos
> > and cleaning up the auto-generation of html demos.
> > 
> > Is there there some way to make the generation of
> > demos (e.g. their inclusion in 'all.dem' or 'make html')
> > depend on the options selected in ./configure?
> > 
> > For example, if you say
> > 	./configure --disable-filledboxes
> > then it should not try to exercise fillstyle.dem
>  
>  gnuplot does not have a proper test suite as such. A proper test suite,
>  GNU auto* style, would exercise gnuplot features, and print PASS/FAIL,
>  no graphics. I am not sure this can be done with gnuplot in the first place.

The "obvious" way would be a regression suite.  E.g. run each demo
through

	GNUTERM=postscript gnuplot foo.dem \
	  | filter_out_times_and_dates \
          | diff -q - foo_ref.ps 

and check the return status of diff to print PASS/FAIL.

>  Using the demos for 'make check' was my original attempt at something
>  that closely resembles a test suite.

I thought so.

> Hans-Bernhard Broeker writes:
> > On Mon, 19 Apr 2004, Ethan Merritt wrote:
> [...]
> > For html, you can quite certainly use automake conditionals to change the
> > list of html files being run.
> 
>  I believe this might unnecessarily complicate matters. The all-local.dem.in
>  approach can easily be done with configure, once the demo that require
>  specific configure options have been identified.

If we insert some more settings into configure.in, right.  config.status
itself doesn't do conditionals on translating .in files into something
else, it just does replacements. 

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

Re: How does ./configure interact with the demo directory?

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

Ethan Merritt writes:
> While the dust is settling from the version 4 release,
> I thought I'd have a go at adding a couple of new demos
> and cleaning up the auto-generation of html demos.
> 
> Is there there some way to make the generation of
> demos (e.g. their inclusion in 'all.dem' or 'make html')
> depend on the options selected in ./configure?
> 
> For example, if you say
> 	./configure --disable-filledboxes
> then it should not try to exercise fillstyle.dem
 
 gnuplot does not have a proper test suite as such. A proper test suite,
 GNU auto* style, would exercise gnuplot features, and print PASS/FAIL,
 no graphics. I am not sure this can be done with gnuplot in the first place.

 Using the demos for 'make check' was my original attempt at something
 that closely resembles a test suite.

Hans-Bernhard Broeker writes:
> On Mon, 19 Apr 2004, Ethan Merritt wrote:
[...]
> For html, you can quite certainly use automake conditionals to change the
> list of html files being run.

 I believe this might unnecessarily complicate matters. The all-local.dem.in
 approach can easily be done with configure, once the demo that require
 specific configure options have been identified.

Re: pdf library for gnuplot

[<xia...@so...>]

> 
> On Tue, 20 Apr 2004, Xiaodong Zhou wrote:
> 
> > I checked the previous discussion about pdf lib. It seems to
> > me that the pdflib from http://www.pdflib.com cannot be used
> > for gnuplot. 
> 
> But it can!  We just don't see that we can distribute precompiled binaries
> with PDFLib built in, given the terms of the PDFLib Lite licence.


You are right that pdflib can be compiled with gnuplot.

Even though PDFLib Lite license is less restrictive than ClibPDF lib,
the result is the same for gnuplot. Precompiled binary cannot have built-in
support for pdf.

There is another pdf lib with both GPL and LGPL license

http://www.stillhq.com/cgi-bin/getpage?area=panda

Could it be helpful?

Xiaodong Zhou
Ch: free C/C++ interpreter
http://www.softintegration.com

> 
> > There is a another pdf lib from http://www.fastio.com/.
> > Here is the quote for its license, 
> > 
> > "
> >  ClibPDF is a library of ANSI C functions, distributed as source code,
> > for creating PDF files directly via C language programs without relying
> > on any Adobe Acrobat(R) tools and related products.  It is free for
> > private, non-profit use, but a commercial license is required for
> > for-profit applications"
> 
> That's considerably more restrictive than the PDFlib Lite license.  If we
> can't use PDFlib Lite, we certainly can't use a library with the above
> terms.
> 
> > Could it be possible to bundle it with gnuplot? or the gnuplot
> > supports only pdf lib from http://www.pdflib.com?
> 
> As of now, only PDFLib is supported.
> 
> -- 
> Hans-Bernhard Broeker (br...@ph...)
> Even if all the snow were burnt, ashes would remain.
> 
> 

Re: How does ./configure interact with the demo directory?

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

Ethan Merritt wrote:

>On Tuesday 20 April 2004 02:29 pm, Daniel J Sebald wrote:
>  
>
>>That's a good idea.  "All" should contain all.  However, then 'all.dem'
>>will still not go all the way through.  
>>    
>>
>
>I don't so much care what "all.dem" contains specifically.
>What I am concerned about is that "make check" should not fail
>just because you disabled an option in ./configure.
>

Oh, I see.

>>Is there some small modification 
>>that can be made so that a syntax error does not cause gnuplot to stop
>>when inside a file script?  
>>    
>>
>
>That is similar to an idea I had some time ago -
>that when an option is disabled in ./configure there is still enough
>residual code generated so that the syntax is legal:
>

That is what I had in mind.

>#ifdef SOMETHING_FANCY
>   lots of code
>#else
>   int_error(NO_CARET, "Your gnuplot does not support this option");
>#endif
>
>As I recall, the objection was raised that Windows does not provide
>any reasonable place to print such a message.
>

Too bad.  It's nice to have gnuplot not act too differently depending 
upon platform.

Dan

Re: How does ./configure interact with the demo directory?

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

On Tuesday 20 April 2004 02:29 pm, Daniel J Sebald wrote:
>
> That's a good idea.  "All" should contain all.  However, then 'all.dem'
> will still not go all the way through.  

I don't so much care what "all.dem" contains specifically.
What I am concerned about is that "make check" should not fail
just because you disabled an option in ./configure.

> Is there some small modification 
> that can be made so that a syntax error does not cause gnuplot to stop
> when inside a file script?  

That is similar to an idea I had some time ago -
that when an option is disabled in ./configure there is still enough
residual code generated so that the syntax is legal:

#ifdef SOMETHING_FANCY
   lots of code
#else
   int_error(NO_CARET, "Your gnuplot does not support this option");
#endif

As I recall, the objection was raised that Windows does not provide
any reasonable place to print such a message.


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

Re: How does ./configure interact with the demo directory?

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

Hans-Bernhard Broeker wrote:

>On Tue, 20 Apr 2004, Petr Mikulik wrote:
>
>  
>
>>I prefer to keep "all.dem" as the main demo file.
>>Then we don't need to bother with its generation by all possible
>>config/makefile's.
>>
>>The "local" one, you wish to ./configure, could be called
>>all-local.dem, for example.
>>    
>>
>
>OTOH, it may be preferrable to have that generator, if we write one, write
>both 'all.dem' and 'all-local.dem'.  The idea being that there should be
>only one listing of all the demos in the source code, if possible.
>

That's a good idea.  "All" should contain all.  However, then 'all.dem' 
will still not go all the way through.  Is there some small modification 
that can be made so that a syntax error does not cause gnuplot to stop 
when inside a file script?  Or perhaps the second level of files?  That 
is "load all.dem" calls "load" from inside the loaded file.  If there is 
a syntax error at that second level, perhaps just continue on?

Dan

Re: How does ./configure interact with the demo directory?

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

On Tue, 20 Apr 2004, Petr Mikulik wrote:

> I prefer to keep "all.dem" as the main demo file.
> Then we don't need to bother with its generation by all possible
> config/makefile's.
> 
> The "local" one, you wish to ./configure, could be called
> all-local.dem, for example.

OTOH, it may be preferrable to have that generator, if we write one, write
both 'all.dem' and 'all-local.dem'.  The idea being that there should be
only one listing of all the demos in the source code, if possible.

The longer I look at this, the more it sounds like the GNU autogen tool
might be a good idea.

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

Re: How does ./configure interact with the demo directory?

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

> Is there there some way to make the generation of
> demos (e.g. their inclusion in 'all.dem' or 'make html')
> depend on the options selected in ./configure?
>
> For example, if you say
> 	./configure --disable-filledboxes
> then it should not try to exercise fillstyle.dem

I prefer to keep "all.dem" as the main demo file.
Then we don't need to bother with its generation by all possible
config/makefile's.

The "local" one, you wish to ./configure, could be called
all-local.dem, for example.

---
PM

Re: DONE.

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

> Don't know if anyone noticed, but there are other /pub directories; in
> particular gnuplot-historical, into which we should probably put something
> from the pre-4.0 [3.7 or 3.8-ish?] era.  If anyone has their favorite golden

Yes, please keep the historical archive of previous releases.

---
PM

Re: How does ./configure interact with the demo directory?

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

On Mon, 19 Apr 2004, Ethan Merritt wrote:

> While the dust is settling from the version 4 release,
> I thought I'd have a go at adding a couple of new demos
> and cleaning up the auto-generation of html demos.
> 
> Is there there some way to make the generation of
> demos (e.g. their inclusion in 'all.dem' or 'make html')
> depend on the options selected in ./configure?

The results of all those tests are available in ./configure itself, in the 
shape of shell variables.  To generate all.dem from configure, you would 
write an all.dem.in and process that by config.status, using separate
variables defined for the purpose.

Or maybe just write a little C program that reads config.h and writes
all.dem.

For html, you can quite certainly use automake conditionals to change the
list of html files being run.

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

Re: pdf library for gnuplot

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

On Tue, 20 Apr 2004, Xiaodong Zhou wrote:

> I checked the previous discussion about pdf lib. It seems to
> me that the pdflib from http://www.pdflib.com cannot be used
> for gnuplot. 

But it can!  We just don't see that we can distribute precompiled binaries
with PDFLib built in, given the terms of the PDFLib Lite licence.

> There is a another pdf lib from http://www.fastio.com/.
> Here is the quote for its license, 
> 
> "
>  ClibPDF is a library of ANSI C functions, distributed as source code,
> for creating PDF files directly via C language programs without relying
> on any Adobe Acrobat(R) tools and related products.  It is free for
> private, non-profit use, but a commercial license is required for
> for-profit applications"

That's considerably more restrictive than the PDFlib Lite license.  If we
can't use PDFlib Lite, we certainly can't use a library with the above
terms.

> Could it be possible to bundle it with gnuplot? or the gnuplot
> supports only pdf lib from http://www.pdflib.com?

As of now, only PDFLib is supported.

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

pdf library for gnuplot

[<xia...@so...>]

Hello,

I checked the previous discussion about pdf lib. It seems to
me that the pdflib from http://www.pdflib.com cannot be used
for gnuplot. There is a another pdf lib from http://www.fastio.com/.
Here is the quote for its license, 

"
 ClibPDF is a library of ANSI C functions, distributed as source code, 
for creating PDF files directly via C language programs without relying on 
any Adobe Acrobat(R) tools and related products.  It is free for private,
non-profit use, but
a commercial license is required for for-profit applications"

Could it be possible to bundle it with gnuplot? or the gnuplot
supports only pdf lib from http://www.pdflib.com?

I like the new features of gnuplot 4.0, and will integrate the gnuplot
engine with Ch next release. Thanks for your work.

Xiaodong Zhou
Ch: free C/C++ interpreter
http://www.softintegration.com

How does ./configure interact with the demo directory?

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

While the dust is settling from the version 4 release,
I thought I'd have a go at adding a couple of new demos
and cleaning up the auto-generation of html demos.

Is there there some way to make the generation of
demos (e.g. their inclusion in 'all.dem' or 'make html')
depend on the options selected in ./configure?

For example, if you say
	./configure --disable-filledboxes
then it should not try to exercise fillstyle.dem

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

Re: DONE.

[Clark G. <ga...@di...>]

Petr Mikulik wrote:
>>>Plese copy manualy gnuplot.sf.net/faq.html => to www.gnuplot.info/faq.html
>>>... it does not get mirrored
>>
>>not there on sf per wget.  it was accomplished before with a symlink.  my
>>preference would be to point the announcement to /faq than /faq.html
> 
> 
> The announcement has been already posted to many sites ... and the 1st
> reaction on comp.text.tex was about exactly this wrong link. So we must
> ensure it gets working.

Yeah, sory I missed that in the announcement.  Should be working now; please 
confirm (be browser is being obstinate at the moment).

--ckg

Re: DONE.

[Clark G. <ga...@di...>]

Lars Hecking wrote:
>>>ftp://ftp.gnuplot.info/pub/gnuplot/faq/
>>>...it is still the old version
>>
>>I believe this is mirrored from lars's ftp repository.  Again, I'd be 
>>inclined to go with one-stop-shopping and point to
>> http://www.gnuplot.info/faq
> 
> 
>  Yep - the faq directory from the ftp site is gone; it wasn't quite up to
>  date anyway.
> 
>  I will remove the UCC web site; or should I instead set up a mirror from
>  SF/gnuplot.info? I need to keep the ftp site, though.

I'd prefer we not do mirrors of mirrors of non-canonicals.  [Only a native 
English speaker could murder the language thusly!]  I like the mirroring to 
canonical approach, as it gives us 0-30 minutes of staging to see if we 
broke something.  We should point other mirrors and users to gnuplot.info 
and use sf as a staging/testing area for ourselves [poor-man's change 
management].

I do have oldwww.gnuplot.info set up in case we need it for historical 
purposes.  I'll maintain this on a "best-effort" basis.

Since we do not have ftp from sf anymore, using your ftp as the staging area 
has been useful.  I would prefer that we get this on sf, perhaps in the 
/htdocs/files or /htdocs/ftp directory, then mirror that to 
ftp://ftp.gnuplot.info/pub/gnuplot.  I don't mind mirroring with http to the 
ftp repository.

Don't know if anyone noticed, but there are other /pub directories; in 
particular gnuplot-historical, into which we should probably put something 
from the pre-4.0 [3.7 or 3.8-ish?] era.  If anyone has their favorite golden 
pre-4.0 build they would care to nominate, I will be happy to throw it into 
-historical.  Take a look at what is there and see if you think there is any 
other build you consider so worthy.  Btw, if anyone would care to write a 
little "historical background" document with a synopsis of each of those 
builds, that would be a worthy contribution.  Similarly, we could add a FAQ 
item with a link to these historical releases.

--ckg

Re: Gnuplot for Windows V4.0 (fwd)

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

On Mon, 19 Apr 2004, Petr Mikulik wrote:

> > This has actually been reported by two other people in the Bug Tracker,
> > too.
> 
> New wgnuplot.hlp compiles are available at
>   http://gnuplot.sourceforge.net/test/
> 
> 
> >  Which reminds me: active developers should be subscribed to
> > gnuplot-developers, which will get you immediate notification of any
> > changes to the various Tracker pages at SF by mail.  At the moment it
> > appears only me and Clark Gaylord watch that at all.
> 
> I cannot find where I can switch it on...

Go to the "Lists" sub-page of the project website 
(sf.net/projects/gnuplot).  It should be one of the five mailing lists
you see listed there.  If it's not seen, I can make it visible.

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

Re: Gnuplot for Windows V4.0 (fwd)

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

> This has actually been reported by two other people in the Bug Tracker,
> too.

New wgnuplot.hlp compiles are available at
  http://gnuplot.sourceforge.net/test/


>  Which reminds me: active developers should be subscribed to
> gnuplot-developers, which will get you immediate notification of any
> changes to the various Tracker pages at SF by mail.  At the moment it
> appears only me and Clark Gaylord watch that at all.

I cannot find where I can switch it on...

Petr

Re: Gnuplot for Windows V4.0 (fwd)

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

On Mon, 19 Apr 2004, Petr Mikulik wrote:

> 	Hi all,
> 
> first bug report -- does anybody have an idea what does it mean?

This has actually been reported by two other people in the Bug Tracker,
too.  Which reminds me: active developers should be subscribed to
gnuplot-developers, which will get you immediate notification of any
changes to the various Tracker pages at SF by mail.  At the moment it
appears only me and Clark Gaylord watch that at all.

As to the problem: it looks like your wgnuplot.hlp build is somehow tied
to Czech.  I have no idea how that would happen.

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