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

Re: defined and functions

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

Hans-Bernhard Broeker wrote:

>>"help function" is quite different from "help data" -- I would expect "help
>>fun" to go to "help functions" which lists functions, not "help style func"
>>    
>>
>
>The way gnuplot online help is organized, things like this are bound to
>happen, esp. as doc authors write "?" line carelessly.
>
>The basic problem is that people want to type 'help foo' when the node
>they actually want to see is correctly called 'help commands set foo'.
>
>Requiring not just incomplete, but also *abbreviated* searches to always
>yield the expected result is futile.  That just can't work.  In the case
>of 'help fun', there are at at least three nodes eligible for display,
>given here with their "full" names:
>
>gnuplot expressions functions
>commands show functions
>commands set function style     # deprecated syntax for 'set style function'
>

But even that would be somewhat helpful, i.e., if gnuplot  finds 
multiple entries and none of them are the highest node then display a 
list of node entries.  There are times I remember a certain qualifier 
but not the command that it is under.  The abbreviated help you describe 
above would at least get you in the right area.  A way for enhancing 
what you describe might be to have a "help memory".  That is, display 
all the categories with a number beside, i.e.,

1) gnuplot expressions functions
2) commands show functions
3) commands set function style

and the next time one calls help they could type

gnuplot>  help 2

and the "commands show functions" category will be displayed.

Another enhancement could possibly be a true "search" routine that will 
search through all the help text for the word or words the user specifies.

Dan

Re: gnuplot-4.0.0 fails to link on Digital UNIX V4.0E

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

On Sunday 25 April 2004 12:56 pm, Hans-Bernhard Broeker wrote:
> On Sat, 24 Apr 2004, Bernhard Simon wrote:
> > Environment: Digital UNIX V4.0E, cc, gnuplot-4.0.0
> >
> >  * cc -std1 -O -o gnuplot alloc.o ... version.o \
> >  -lz -lpng -lm 
     ^^^^^^^^^^^^^                                                             
> >    ld:
> >    Unresolved:
> >    deflate
> >    deflateEnd
> >    inflateReset
> >    crc32
> >    deflateReset
> >    deflateInit2_
> >    [ Fix: link with ... -lpng -lz -lm ]
                            ^^^^^^^^^^^^^
>
> That's not the right way of fixing this, of course.  The actual
> bug is in configure.in, where linking against -lgd and -lpng is
> tested and the variables used in the link command are set up.
>
> Ethan: I'm CCing you on this because if memory serves, it was you who
> claimed that the tests in their current shape are the only way to get
> this to work on some platforms.  

I have vague recollections of saying that, but the only thing I can
find in the mailing list archive (from Jan 2003) is a slightly 
different issue. I was making the point that (at least under linux) 
if ./configure tests for libpng and finds it, it will be finding the 
most current installed version.  But this version may not
match the one that, say, libgd was linked against.  In this case you get
incompatibility warnings at link time.  So I was arguing against 
specifying "-lpng -lz" explicitly if libgd was already being included.
I honestly do not know if these are ever fatal errors, but they certainly
appear in the  make output.  I am, for instance, currently getting such
warnings because libgd and libpdf were themselves built against different
versions of libpng:
	/usr/bin/ld: warning: libpng.so.2, needed by /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../../libpdf.so, may conflict with libpng.so.3
This one has caused me no problems so far, and I could get rid of it by
rebuilding libpdf. 

Regardless of all that, the current report looks to me to be a different
issue.  He had to change the order of the libraries in the link statement.
Apparently ./configure places them in the wrong order.
If I ever had a reason for wanting -lz to come before -lpng I can no longer
remember what it might have been.  So if moving the tests on libz to after
the png tests fixes the problem, I have no objection (but we should test
it first, of course).

> Can we please clean this up soon?

I have not done development under DU for a couple of years now.
My recollection of little tricks and gotchas is fading.  But, as I say,
the current version 4 ./configure file does work for me under DU 4.0D
That may be because I am linking against libgd also. Maybe.


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

Re: emf woes

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

On Fri, 23 Apr 2004, Ethan Merritt wrote:

> On Friday 23 April 2004 03:31 am, Hans-Bernhard Broeker wrote:
> > I does seem to have a problem with gnuplot's EMF files, though.  In
> > particular, its 'printemf' tool complains
> >
> > GetEnhMetaFileW warning: read unknown record type 84 of size 80
> > GetEnhMetaFileW warning: read unknown record type 84 of size 84
> > [... several more ...]
> 
> Strange.  My (admittedly outdated) spec for EMF says record type 84
> is	EMR_EXTTEXTOUTW
> 
> > Seems like that is about our EMF_put_text() calling
> >
> >     EMF_write_emr(84, 76 + len * 2);    /* exttextoutw, yes it's the 16bits char version! */
> 
> which is consistent with that comment.

The warning is about the fact that libEMF doesn't support ExtTextOutW.
Which is the "wide character" (i.e.: Microsoft's idea of Unicode) version
of ExtTextOutA.

What I really don't understand well is why our emf.trm would want to use
the wide-character version.

> > Note that this little snippet from libEMF also contains a valuable hint
> > at the actual EMF definition.  Google finds:
> >
> > http://www.ecma-international.org/publications/standards/Ecma-234.htm
> 
> From a quick look at the pdf docs there, they seem to be specs for
> Windows 3.1 APIs. That's even older than the spec I already have.

It started off as the Win16 API alright, but it's apparently outgrown that
heritage --- otherwise, EMF wouldn't be part of it at all: AFAIK Win16
can't for the life of it handle EMF.

But it has the benefit of coming from an official standardization body,
instead of directly out of Microsoft Press.  I.e. it's less likely to be
revised whenever somebody in Redmond has an itch to scratch.

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

Re: defined and functions

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

On Sat, 24 Apr 2004, Petr Mikulik wrote:

> Could someone review help (in gnuplot.doc) for "defined", "function",
> "variable"?
> 
> I searched "what's the name of the function returning 0/1 if given variable
> exists".
> 
> "help variable" -- it does not mention existence of such function
> 
> "help defined" -- goes to "help palette defined" ... but actually
>   "help pal defined" itself cannot be called like that

	help palette defined

works, though.  Abbreviation doesn't work for sub-node queries, I think.
At least not in all our online-help systems.

> "help function" is quite different from "help data" -- I would expect "help
> fun" to go to "help functions" which lists functions, not "help style func"

The way gnuplot online help is organized, things like this are bound to
happen, esp. as doc authors write "?" line carelessly.

The basic problem is that people want to type 'help foo' when the node
they actually want to see is correctly called 'help commands set foo'.

Requiring not just incomplete, but also *abbreviated* searches to always
yield the expected result is futile.  That just can't work.  In the case
of 'help fun', there are at at least three nodes eligible for display,
given here with their "full" names:

gnuplot expressions functions
commands show functions
commands set function style     # deprecated syntax for 'set style function'

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

Re: call: how many parameters?

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

On Sat, 24 Apr 2004, Petr Mikulik wrote:

> Currently, inside bla.gp called like
> 
> 	call "bla.gp" one two 3 4
> 
> it is not possible to determine how many parameters were passed into it.
> The only way seems to be a global variable like
> 
> 	params=4; call "bla.gp" one two 3 4
> 
> and to use
> 
> 	if (defined(params) && params==4) ...

Why that complicated?  What's wrong with making the number of parameters
the first parameter, i.e.

	call "bla.gp" 4 one two 3 4

?

OTOH, what you really need would be a "was parameter number <n> passed
in by the caller?" kind of test, i.e. the equivalent of the Bourne 
shell standard phrase

	if [ "x$5" != "x" ] 

I.e. a mix between the 'defined' and 'valid' operators, but for 'call'
parameters instead of user-defined variables or data file column values,
respectively.  Arguably valid() itself might be the one that should be
offering this.

> I propose to add "variable"  $#  which will be set to number of available
> $0, $1, ...

Please keep in mind that '#' is our comment character.  

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

Re: defined and functions

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

On Saturday 24 April 2004 12:33 am, Petr Mikulik wrote:
> Could someone review help (in gnuplot.doc) for "defined", "function",
> "variable"?

Right now all this stuff is under
	help expressions

In this case
	help expressions functions defined

I agree that this is not an obvious way of finding functions,
but I don't have a better suggestion short of moving definitions
back up to the top level of help.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

call: how many parameters?

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

Currently, inside bla.gp called like

	call "bla.gp" one two 3 4

it is not possible to determine how many parameters were passed into it.
The only way seems to be a global variable like

	params=4; call "bla.gp" one two 3 4

and to use

	if (defined(params) && params==4) ...

supposing caller set the value correctly.

I propose to add "variable"  $#  which will be set to number of available
$0, $1, ...

What do you think about? Could someone add it?


---
PM

defined and functions

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

Could someone review help (in gnuplot.doc) for "defined", "function",
"variable"?

I searched "what's the name of the function returning 0/1 if given variable
exists".

"help variable" -- it does not mention existence of such function

"help defined" -- goes to "help palette defined" ... but actually
  "help pal defined" itself cannot be called like that

"help function" is quite different from "help data" -- I would expect "help
fun" to go to "help functions" which lists functions, not "help style func"

---
PM

Re: emf woes

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

On Friday 23 April 2004 09:18 am, Ethan Merritt wrote:
> On the other
> hand, if this library or some equivalent one has been adopted into
> the OpenOffice source tree, then maybe we should look there to
> see if we can use it.

And indeed, in the OpenOffice source tree (750MB, ugh!) is a
filter module for emf
	oo_1.1_src/svtools/source/filter.vcl/wmf/emfwr.cxx

It states at the top of the source that it is usable under either
LGPL or "Sun Industry Standards Source License Version 1.1"

I don't know that it's worth trying to adapt it as a separate 
library module, but if nothing else we should be able to look
inside to see how they handle strings or other object types
that Windows is griping about in our current version.


As to WIN_EMR_EXTTEXTOUTW (record type 84) in particular -
as I feared, it looks like they deal with Unicode conversion
for each character as the string is stored. But I haven't
chased through the code to see if this is essentially a no-op
in the case of "normal" text strings.

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

Web Site

[Justace C. <pro...@co...>]

Hey guys,

	I went to the web site to check it out.  I knowticed that the
background is such that I can see it regenerate on the right side of the
screen.  My resolution is 1920.  A screen shot is at the following
address. 

	http://math.smsu.edu/~prophecy/gnuplot_homepage.jpg

	I am not sure if it is the look that you were going for, with the grid
boarders on both sides of the window but I hacked up a version of the
grid that is 3000 pixels wide with no right border.  The border would
still be on the left hand side.  This image is at:

	http://math.smsu.edu/~prophecy/grid_wide.jpg

	What do you all think?

Justace

Re: emf woes

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

On Friday 23 April 2004 03:31 am, Hans-Bernhard Broeker wrote:
> On Thu, 22 Apr 2004, Ethan Merritt wrote:
> > Can you tell me where you found a copy of the current EMF spec?
>
> Maybe we don't need one.  Look what I just came across on my Linux box,
> in file /usr/share/doc/packages/libEMF/README:

Hoho. I don't have any such libEMF on my machines, but a brief search
turns up
	http://libemf.sourceforge.net/
which contains this fascinating statement:

"My general interest in this library is for making scientific plots with 
 gnuplot and Grace(forthcoming). Therefore, this software includes 
 patches to those programs to add the EMF as an output option."

But I see no such patches on SourceForge or in the libemf tarball,
and the project seems to have been moribund since Jan 2002.
It is not clear to me that it would be a good idea to switch over
to building emf.trm on top of an unsupported library.  On the other
hand, if this library or some equivalent one has been adopted into
the OpenOffice source tree, then maybe we should look there to
see if we can use it. 

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

Re: emf woes

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

On Friday 23 April 2004 03:31 am, Hans-Bernhard Broeker wrote:
> I does seem to have a problem with gnuplot's EMF files, though.  In
> particular, its 'printemf' tool complains
>
> GetEnhMetaFileW warning: read unknown record type 84 of size 80
> GetEnhMetaFileW warning: read unknown record type 84 of size 84
> [... several more ...]

Strange.  My (admittedly outdated) spec for EMF says record type 84
is	EMR_EXTTEXTOUTW

> Seems like that is about our EMF_put_text() calling
>
>     EMF_write_emr(84, 76 + len * 2);    /* exttextoutw, yes it's the 16bi=
ts char version! */

which is consistent with that comment.

I did worry a little that the spec refers to all text handling in terms
of Unicode strings.  Gnuplot is not unicode-ready.


> Note that this little snippet from libEMF also contains a valuable hint
> at the actual EMF definition.  Google finds:
>
> http://www.ecma-international.org/publications/standards/Ecma-234.htm

=46rom a quick look at the pdf docs there, they seem to be specs for
Windows 3.1 APIs. That's even older than the spec I already have.

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

Re: emf woes

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

On Thu, 22 Apr 2004, Ethan Merritt wrote:

> Can you tell me where you found a copy of the current EMF spec?

Maybe we don't need one.  Look what I just came across on my Linux box,
in file /usr/share/doc/packages/libEMF/README:

libEMF is a library for generating Enhanced Metafiles on systems which
don't natively support the ECMA-234 Graphics Device Interface
(GDI). The library is intended to be used as a driver for other
graphics programs such as Grace or gnuplot. Therefore, it implements a
very limited subset of the GDI.

I wonder, if he's seeing gnuplot as part of his intended target audience,
why we never heard of this. Or did we, and I just forgut.

I does seem to have a problem with gnuplot's EMF files, though.  In
particular, its 'printemf' tool complains 

GetEnhMetaFileW warning: read unknown record type 84 of size 80
GetEnhMetaFileW warning: read unknown record type 84 of size 84
[... several more ...]

Seems like that is about our EMF_put_text() calling

    EMF_write_emr(84, 76 + len * 2);    /* exttextoutw, yes it's the 
16bits char version! */

Note that this little snippet from libEMF also contains a valuable hint
at the actual EMF definition.  Google finds:

http://www.ecma-international.org/publications/standards/Ecma-234.htm


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

Re: emf woes

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

In article <c64t60$2c5k$1...@f1...> Allin Cottrell writes:
>
>Yes, that would be nice!  As for bugs in gnuplot's EMF files, a quick
>check suggests there may be some.  I looked at a sample EMF generated
>on Windows, and the byte size written in the EMF header did not agree
>with the actual size of the file; also one field of the current EMF
>header structure is missing (I'm not sure how important that is).

Can you tell me where you found a copy of the current EMF spec?
The copy I have is probably out of date (it claims version 1.0),
since it actually describes 3 fewer records in the header than
gnuplot puts there currently.

But the emf files I generate under linux have the correct file size in
the header.  Can you reproduce the plot commands that generated a
mis-match so that I can try them here also?

I do see a few other minor discrepancies with the copy of the
version 1.0 spec:
- The version string doesn't match (probably correct)
- EMF_HANDLE_MAX is stored, but the standard says this
  field should always be 0 for disk files
- There is no Unicode description string. This identifier was
  optional in version 1.0 but it may now be required. The comment in
  the spec is that providing such a string in a particular format
  "guarantees that standard information may be obtained from an EMF
   file".

Back to your original query about alternatives -
I spent some time leading up to Version 4  making sure that output
from the SVG terminal was compatible with the various browsers
and viewers I could test.  I don't know what the state of support is
for SVG under Windows, however.  Is that maybe a possible alternative
for you? 

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

New Gnuplot Page in Portuguese (fwd)

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

Forwarded from private mail since I don't work on the web pages...

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

---------- Forwarded message ----------
Date: Thu, 22 Apr 2004 11:41:12 -0300 (BRT)
From: ga...@pr...
To: br...@ph...
Subject: New Gnuplot Page in Portuguese

Dear Hans-Bernhard Broeker

First of all, congratulations for the new version of Gnuplot.

I am a Gnuplot user since 1997-1998 and recently I construct one web page
were I include some examples (with scripts), one tutorial (in Portuguese)
and links to the official gnuplot page (http://www.gnuplot.info). In some
scripts, commands as pm3d (included in the new Gnuplot 4.0 version), is
used.

This page is located at URL
http://www.prudente.unesp.br/dcartog/galo/gnuplot. If it is possible,
send your comments about the content of this page. In case this page is
considered useful, I suggest you to evaluate the inclusion it as a
"Gnuplot pages in Portuguese" or thinks like that in official page.

Thanks a lot

 Mauricio Galo
-------------------------------------------
 UNESP / FCT - Departamento de Cartografia
     Rua Roberto Simonsen 305, CP 468
  CEP 19060-900, Presidente Prudente, SP
   http://www.prudente.unesp.br/dcartog
 (Tel.)55 18 229 5388 (Fax)55 18 223 1534
-------------------------------------------

Re: updated wgnuplot.hlp

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

On Thu, 22 Apr 2004, Hans-Bernhard Broeker wrote:

> On Thu, 22 Apr 2004, Petr Mikulik wrote:
> 
> > So, users of MSW 2000 reports that only
> > 	wgnuplot-XP_EN.hlp
> > from the 3 different hlp's works on their system. Thus, what to do with
> > that? I propose:
> > 
> > 1. refresh gp400win32.zip with the new .hlp file
> >    (new users would not be affected)
> 
> Definitely.  And write a "News" to our SourceForge page and a followup
> to the Announcement to at least the major places.

Done that.

Petr: I think you can add a comment explaining this and close that 
bug report.

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

Re: updated wgnuplot.hlp

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

On Thu, 22 Apr 2004, Petr Mikulik wrote:

> So, users of MSW 2000 reports that only
> 	wgnuplot-XP_EN.hlp
> from the 3 different hlp's works on their system. Thus, what to do with
> that? I propose:
> 
> 1. refresh gp400win32.zip with the new .hlp file
>    (new users would not be affected)

Definitely.  And write a "News" to our SourceForge page and a followup
to the Announcement to at least the major places.

> 2. put wgnuplot_hlp_w2k_update.zip with the regenerated help file for
> download

I don't think that's really needed.  The gnuplot download isn't all that
huge.

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

updated wgnuplot.hlp

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

So, users of MSW 2000 reports that only
	wgnuplot-XP_EN.hlp
from the 3 different hlp's works on their system. Thus, what to do with
that? I propose:

1. refresh gp400win32.zip with the new .hlp file
   (new users would not be affected)

2. put wgnuplot_hlp_w2k_update.zip with the regenerated help file for
download

Maybe only the 1st as a refresh (i.e., no change of name) is sufficient?

Both files are on gnuplot's sf web directory test/ to be released (at
least 1.) asap.

Petr

Gnuplot 4.0 makes the news

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

Congrats, guys.

Gnuplot 4.0 is the lead story in the Development section of 
this week's Linux Weekly News

	http://lwn.net/Articles/80603/

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: pdf library for gnuplot

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

[...]
> >For the issue at hand, the opinion, actually even the very existence, of
> >the OSI is a complete non-issue.

> But isn't the requirement for PDF  code in the binaries (by that 
> company) that the Gnuplot license be OSI certified?  Then there are not 
> problems?

The discussion has drifted from that topic to Gnuplot vs. GPLed libraries
since.

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

Re: pdf library for gnuplot

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

Hans-Bernhard Broeker wrote:

>On Wed, 21 Apr 2004, Daniel J Sebald wrote:
>
>  
>
>>Hans-Bernhard Broeker wrote:
>>    
>>
>
>  
>
>>>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.
>>>
>>>      
>>>
>>You are identifying, then, the difference between the Gnuplot license 
>>and an existing license.  This is one of the items that the Open Source 
>>Initiative is asking for  so that they can discuss things.
>>
>>However, are you thinking that this particular sentence is a significant 
>>enough variation that it would cause the OSI to not allow it?  
>>    
>>
>
>For the issue at hand, the opinion, actually even the very existence, of
>the OSI is a complete non-issue.
>

But isn't the requirement for PDF  code in the binaries (by that 
company) that the Gnuplot license be OSI certified?  Then there are not 
problems?

Dan

Re: pdf library for gnuplot

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

On Wed, 21 Apr 2004, Daniel J Sebald wrote:

> Hans-Bernhard Broeker wrote:

> >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.
> >
> 
> You are identifying, then, the difference between the Gnuplot license 
> and an existing license.  This is one of the items that the Open Source 
> Initiative is asking for  so that they can discuss things.
> 
> However, are you thinking that this particular sentence is a significant 
> enough variation that it would cause the OSI to not allow it?  

For the issue at hand, the opinion, actually even the very existence, of
the OSI is a complete non-issue.  We're talking about GPL compatibility
here, for which the only relevant documents are our own license and the
text of the GPL.

> I guess in principle this is saying that someone can't create their own
> "developer" version of the software, that is bifurcate so there are two
> versions floating about.

Among other things.  It also means Linux distributors can't just
distribute patched source tarballs.  Most don't do that anyway, but our
statement says they're not *allowed* to.  And that is at odds with the
GPL.

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

Re: pdf library for gnuplot

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

Hans-Bernhard Broeker wrote:

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

You are identifying, then, the difference between the Gnuplot license 
and an existing license.  This is one of the items that the Open Source 
Initiative is asking for  so that they can discuss things.

However, are you thinking that this particular sentence is a significant 
enough variation that it would cause the OSI to not allow it?  I guess 
in principle this is saying that someone can't create their own 
"developer" version of the software, that is bifurcate so there are two 
versions floating about.  The Gnuplot notice does go on to very 
explicitly discuss that it is allowable to distribute modified programs 
in the form of binaries and how that can be done.

 I think that the easiest route might be for someone to assemble the 
presentation the OSI wants and attempt to get the Gnuplot license 
verified.  It is at least worth a try I would think.

Dan

Re: gnuplot-4.0.0 on SunOS 4

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

On Wed, 21 Apr 2004, Lars Hecking wrote:

>  This is mainly an exercise to test whether gnuplot 4 compiles with K&R
>  compilers - it should, with ansi2knr, but it doesn't. Any ideas?
> 
> make[3]: Entering directory `/tmp/gnuplot-4.0.0/src'
> cc -E -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.0\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.0/gnuplot.gih\" -I/usr/include/X11  `if test -f ./axis.c; then echo ./axis.c; else echo axis.c; fi` | sed 's/^# \([0-9]\)/#line \1/' | ./ansi2knr > axis_.c || rm -f axis_.c
> ./axis.h: 521: bad formal: \
> 
> ./axis.h: 576: bad formal: \

Hmmm... looks like that preprocessor can't cope with \ continuation in the
middle of a macro definition's argument list.   A look into _axis.c might 
tell, if it's not removed immediately.

> source='axis_.c' object='axis_.o' libtool=no \
> depfile='.deps/axis_.Po' tmpdepfile='.deps/axis_.TPo' \
> depmode=none /usr/local/gnu/bin/bash ../depcomp \
> cc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.0\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.0/gnuplot.gih\" -I/usr/include/X11   -g -c `test -f 'axis_.c' || echo './'`axis_.c
> "./axis.c", line 58: operands of = have incompatible types
> "./axis.c", line 58: operands of = have incompatible types
> "./axis.c", line 58: illegal initialization
> "./axis.c", line 58: operands of = have incompatible types
> "./axis.c", line 58: illegal initialization
> "./axis.c", line 58: too many initializers
> "./axis.c", line 58: too many initializers
[...]

Same here: I'll need a copy of _axis.c to see what's wrong here.

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

gnuplot-4.0.0 on SunOS 4

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

 This is mainly an exercise to test whether gnuplot 4 compiles with K&R
 compilers - it should, with ansi2knr, but it doesn't. Any ideas?

make[3]: Entering directory `/tmp/gnuplot-4.0.0/src'
cc -E -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.0\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.0/gnuplot.gih\" -I/usr/include/X11  `if test -f ./axis.c; then echo ./axis.c; else echo axis.c; fi` | sed 's/^# \([0-9]\)/#line \1/' | ./ansi2knr > axis_.c || rm -f axis_.c
./axis.h: 521: bad formal: \

./axis.h: 576: bad formal: \

source='axis_.c' object='axis_.o' libtool=no \
depfile='.deps/axis_.Po' tmpdepfile='.deps/axis_.TPo' \
depmode=none /usr/local/gnu/bin/bash ../depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.0\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.0/gnuplot.gih\" -I/usr/include/X11   -g -c `test -f 'axis_.c' || echo './'`axis_.c
"./axis.c", line 58: operands of = have incompatible types
"./axis.c", line 58: operands of = have incompatible types
"./axis.c", line 58: illegal initialization
"./axis.c", line 58: operands of = have incompatible types
"./axis.c", line 58: illegal initialization
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: too many initializers
"./axis.c", line 58: fatal error: too many errors
make[3]: *** [axis_.o] Error 1