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

Re: loose plan (was Re: K&R C)

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

> >medium term:  discuss selection of patches, and integrate selected ones
> >              into 4.1


Currently, I build my gnuplot with these patch:
	raise
	with image
	set mouse key
	$#

I would see them in "regular development version of" gnuplot (soon?).

--
PM

Re: loose plan (was Re: K&R C)

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

Hans-Bernhard Broeker wrote:

>>Anyway, simple bug fixes usually can be handled by "patch" with
>>realignment, but something like ANSIfying the code would certainly cause
>>problems for a large percentage of the patches in SourceForge.
>>    
>>
>
>Most of them will require tweaking anyway.  The only real question is how
>much of it.
>
>  
>
>>This would be nice.  I'd opt for clearing the patch page over the course 
>>of a couple months.  Then ANSIfy and restructer code.
>>    
>>
>
>While clearing the known bugs is a viable goal, I don't see that for the
>patches tracker.  Some of those will simply not be integrated, or are too
>far out of date to be applied cleanly.  The patches tracker is as much a
>service to enterprising users as to us --- it's a means of collecting
>unofficial changes that won't go in the mainline source code, as much as
>one of collecting bugfixes that will have to be.
>

What I mean by clearing is to weed out those that, as you mention, will 
never get implemented because they are so out of date or are now 
irrelevant.  Discuss those that might be integrated, if yes then give 
the owner a chance to update the patch and hold cvs stable for a few 
days.  (Not everyone trying to update patches at once would be good too.)

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: loose plan (was Re: K&R C)

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

On Wed, 2 Jun 2004, Daniel J Sebald wrote:

> 
> 
> Hans-Bernhard Broeker wrote:
> 
> >We're not in the habit of making any plans...
> >
> >But, if pressed, I'ld say:
> >
> >near term: iron out remaining bugs in 4.0, split off a 'stable' 4.0 
> >           branch, tag the trunk as 4.1
> >
> 
> I think there is a way in CVS to merge branches eventually, no?  

Yes.  It's not much more comfortable than just applying patches to
both branches individually, though...

> Anyway, simple bug fixes usually can be handled by "patch" with
> realignment, but something like ANSIfying the code would certainly cause
> problems for a large percentage of the patches in SourceForge.

Most of them will require tweaking anyway.  The only real question is how
much of it.

> This would be nice.  I'd opt for clearing the patch page over the course 
> of a couple months.  Then ANSIfy and restructer code.

While clearing the known bugs is a viable goal, I don't see that for the
patches tracker.  Some of those will simply not be integrated, or are too
far out of date to be applied cleanly.  The patches tracker is as much a
service to enterprising users as to us --- it's a means of collecting
unofficial changes that won't go in the mainline source code, as much as
one of collecting bugfixes that will have to be.

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

Re: gnu readline / license

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

On Wed, 2 Jun 2004, Ethan Merritt wrote:

> I do not believe that the GPL restricts gnuplot from being
> linked against libreadline.  

It doesn't restrict the link as such, but it does forbid distributing
the resulting binary, because the gnuplot Copyright contains some
restrictions that would violate the readline's GPL.

> Debian apparently believes otherwise, but that is their problem, not
> ours. 

> 1) gnuplot is clearly not a derived work of libreadline. I don't
> think anyone is arguing this point.

A binary version of gnuplot linked against readline pretty definitely is
such a derived work.

> 2) It is my understanding that restrictions imposed by the
> GPL do not cross a well-defined API boundary.  Therefore mere
> linkage to  an independent (and optional) shared library does
> not by itself contravene the GPL.

That library is by no means "optional" for a binary linked against
-lreadline.  If the user doesn't have libreadline.so on his box, such a
binary would fail to start.  Such behaviour pretty strictly contradicts it
being optional, by my book.

The only exception from this might be if we dlopen() libreadline.so
ourselve, at runtime, and are prepared to live with it not being
available.

>   The most extensive discussion
> on this issue that I have followed has been on the linux kernel
> mailing list.  So far the broad (though not universal) consensus
> is that non-GPL binaries can link against the GPL linux kernel.

Careful there.  Unless I misremember, the Linux Kernel has special
exceptions for such cases, i.e. it's not pure GPL in this sense.

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

Re: gnu readline / license

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

I do not believe that the GPL restricts gnuplot from being
linked against libreadline.  Debian apparently believes otherwise,
but that is their problem, not ours.  I don't think we should waste
any time over it.  Debian are waaaay out there on the extreme
of licensing paranoia.

1) gnuplot is clearly not a derived work of libreadline. I don't
think anyone is arguing this point.

2) It is my understanding that restrictions imposed by the
GPL do not cross a well-defined API boundary.  Therefore mere
linkage to  an independent (and optional) shared library does
not by itself contravene the GPL.  The most extensive discussion
on this issue that I have followed has been on the linux kernel
mailing list.  So far the broad (though not universal) consensus
is that non-GPL binaries can link against the GPL linux kernel.
This is a much tighter integration than our case of using 
libreadline as an optional adjunct to a software package (gnuplot)
that runs just fine even on platforms where libreadline does not
exist.

These arguments may well not sway Debian, who are (IMHO)
way over the top with regard to interpreting the GPL. But I do not
see that Debian's own policies, which are not widely shared even
by other linux distibutions, should control our actions for gnuplot.

Note that Fedora Core, Redhat, PLD, Mandrake, and SuSE
all seem perfectly happy distributing gnuplot+libreadline binary
packages.

On Wednesday 02 June 2004 01:34 am, Johannes Zellner wrote:
> Debian's gnuplot comes w/o gnu readline, which is very bad in my
> opinion. The reason is a license problem, which is documented by the
> package maintainer Thimo Neubauer <th...@de...> (in
> /usr/share/doc/gnuplot/README.Debian):
>
>     libreadline
>     -----------
>
>     Yes, the built in readline of gnuplot is bad. However, libreadline
>     cannot be used instead because it is licensed under the GPL, whereas
>     gnuplot has special licenses (patches only). Linking those programs
>     together is forbidden by the GPL. Please don't file bugs telling me
> to use libreadline in gnuplot...



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

loose plan (was Re: K&R C)

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

Hans-Bernhard Broeker wrote:

>We're not in the habit of making any plans...
>
>But, if pressed, I'ld say:
>
>near term: iron out remaining bugs in 4.0, split off a 'stable' 4.0 
>           branch, tag the trunk as 4.1
>

I think there is a way in CVS to merge branches eventually, no?  Anyway, 
simple bug fixes usually can be handled by "patch" with realignment, but 
something like ANSIfying the code would certainly cause problems for a 
large percentage of the patches in SourceForge.

>medium term:  discuss selection of patches, and integrate selected ones
>              into 4.1
>

This would be nice.  I'd opt for clearing the patch page over the course 
of a couple months.  Then ANSIfy and restructer code.

Dan

Re: gnu readline / license

[Thimo N. <th...@de...>]

On Wed, Jun 02, 2004 at 11:33:50AM +0200, Johannes Zellner wrote:
> hmm. I guess they won't change the readline license. What about
> dlopen'ing libreadline after gnuplot starts, would that solve the
> license problems?

No. Otherwise all licenses would be quite pointless on any system with
shared libs :)

Cheers
   Thimo

Re: gnu readline / license

[Thimo N. <th...@de...>]

On Wed, Jun 02, 2004 at 01:30:22PM +0200, Hans-Bernhard Broeker wrote:
> Which leaves us with essentially two ways to proceed:
> 
> 1) use libeditline, the LGPL alternative to libreadline
> 2) extend our own readline.c considerably
> 
> I have my doubts that 2) is feasible.  So: has any of us given libeditline
> a try?  If so, please speak up with some results.  If not, someone should
> do that soon.

I've tested libeditline quite some while ago, but it wasn't really
usable then: deleting a character with backspace printed a new line,
scrolling the rest up... However, changing gnuplot to use the lib was
easy, I posted a patch back then. Maybe I'll give libeditline a try
next weekend and tell you about the new results.

Cheers
   Thimo

Re: K&R C (was Re: Bugs in enhanced mode)

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

On Tue, 1 Jun 2004, Daniel J Sebald wrote:

> Speaking of evolution, the CVS source tree is a moving target right now. 
>  What are the near term, six month, one year plans?

We're not in the habit of making any plans...

But, if pressed, I'ld say:

near term: iron out remaining bugs in 4.0, split off a 'stable' 4.0 
           branch, tag the trunk as 4.1
medium term:  discuss selection of patches, and integrate selected ones
              into 4.1

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

Re: K&R C (was Re: Bugs in enhanced mode)

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

On Tue, 1 Jun 2004, Daniel J Sebald wrote:

> That's true.  But I'm guessing one of the philosophies of Gnuplot is to 
> accommodate as wide an audience as reasonably possible 

Certainly.  The debate we're having is about the exact meaning of
"reasonably" in this context.  It's becoming harder to guarantee K&R
compatibility, with none of us using real K&R compilers on a daily basis
any more.

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

Re: K&R C (was Re: Bugs in enhanced mode)

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

On Wed, 2 Jun 2004, Lars Hecking wrote:

>  That said, we should move to ISO/ANSI C, and let ansi2knr sort it out.
>  As Lucas and myself recently found it, tis in turn will require a few
>  changes in the code.

And one of those changes is elimination of 'char' type arguments, right?
Because, as far as I'm aware, that's not handled by ansi2knr.

So: do we have a consensus that we'll ANSI-fy the sources right now?

And if so: do we do it on the 4.1 version after branching of a 4.0 for the
"stable" version, or do we keep the version at 4.0 for the time being? At
the minimum, I think we should tag a patchlevel 1 immediately before, and
a patchlevel 2 after this change.

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

Re: K&R C (was Re: Bugs in enhanced mode)

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

On Tue, 1 Jun 2004, Daniel J Sebald wrote:

> Would this be a tolerable hack?  Define a special type in some header 
> for char's as function arguments
> 
> /* Throwback to K&R */
> #ifdef __STDC__
> #define ACHAR char
> #else
> #define ACHAR int
> #endif

Ethan already suggested pretty much the same idea, and I rejected it
as terminally ugly, and not particularly useful.  If the K&R variant
(making the parameter 'int') works at all, it'll work for ANSI C, too.

> Anyway, is gnuplot.texi a generated file?  (I see something called
> doc2texi.el)  If so, should it be in the cvsignore list so that it isn't
> checked out when getting the latest CVS version?

gnuplot.texi is a bit tricky to regenerate.  Up until rather recently,
I never managed to do it myself, because I usually do all builds outside
the source tree, which breaks the generation of gnuplot.texi.
Therefore, even though I'm not quite happy with the situation, I agree
with Lars on this one: it'll have to remain inside CVS for now.

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

gnuplot installation error

[<dj_...@ya...>]

Hello, 
Please, I wanderful if you can help me,
when I lunch ./configure this message apears:
" checking for a BSD ... /usr/bin/install -c
checking whether build enviroment is sane
...configure: error:newly created file is older than
distributed files"

THANK YOU


	

	
		
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! 
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com

Re: gnu readline / license

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

On Wed, 2 Jun 2004, Johannes Zellner wrote:

> Debian's gnuplot comes w/o gnu readline, which is very bad in my
> opinion. 

As a matter of fact, *all* binary distributions of gnuplot would
have to come without GNU readline compiled in.  Otherwise, they'ld
be in violation of the GPL.

I've seen mention of a program called 'rlwrap' (or similar) solving this
by a wrapper layer utilizing GNU readline, to go between non-GPL programs
like gnuplot and the console.  Maybe Thimo can package gnuplot to use
that.

> Is there a chance to get the license changed, so that debian can ship
> gnuplot with the gnu readline?

Essentially: no.  Neither side of this conflict appears willing to bugde.
That has been tried in the past, but never succeeded.

Which leaves us with essentially two ways to proceed:

1) use libeditline, the LGPL alternative to libreadline
2) extend our own readline.c considerably

I have my doubts that 2) is feasible.  So: has any of us given libeditline
a try?  If so, please speak up with some results.  If not, someone should
do that soon.

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

Re: gnu readline / license

[Johannes Z. <joh...@ze...>]

On Wed, Jun 02, 2004 at 11:04:17AM +0200, Petr Mikulik wrote:
> > Debian's gnuplot comes w/o gnu readline, which is very bad in my
> > opinion. The reason is a license problem, which is documented by the
> > package maintainer Thimo Neubauer <th...@de...> (in
> > /usr/share/doc/gnuplot/README.Debian):
> 
> Solution to this problem is to implement <TAB>-expansion of filenames in
> gnuplot's readline library. There was some discussion about it few years
> ago, but nobody did it.
> 	TAB is the only difference, I guess?

no. all the history goodies are missing, e.g. searching backwards in the
history by <ctrl-r> ... I guess we'd have to rewrite libreadline.

-- 
Johannes

Re: gnu readline / license

[Johannes Z. <joh...@ze...>]

On Wed, Jun 02, 2004 at 09:51:29AM +0100, Lars Hecking wrote:
> Johannes Zellner writes:
> > Hello,
>  
>  Johannes! Where have you been all the time? Good to hear from you :)

hehe. I've a real job, a wife and yet a child is on it's way.
Priorities have shifted ...

> [...]
> > Is there a chance to get the license changed, so that debian can ship
> > gnuplot with the gnu readline?
>  
>  The gnuplot license? Not much of a chance. However, I think this could
>  work if readline was distributed under the LGPL instead of GPL.

hmm. I guess they won't change the readline license. What about
dlopen'ing libreadline after gnuplot starts, would that solve the
license problems?

-- 
Johannes
Women are probably the main cause of free software starvation.

Re: gnu readline / license

[Arnd B. <arn...@we...>]

On Wed, 2 Jun 2004, Petr Mikulik wrote:

> > Debian's gnuplot comes w/o gnu readline, which is very bad in my
> > opinion. The reason is a license problem, which is documented by the
> > package maintainer Thimo Neubauer <th...@de...> (in
> > /usr/share/doc/gnuplot/README.Debian):
>
> Solution to this problem is to implement <TAB>-expansion of filenames in
> gnuplot's readline library. There was some discussion about it few years
> ago, but nobody did it.
> 	TAB is the only difference, I guess?

Long lines don't work either: i.e., for a line
longer than the width of the terminal window you cannot get
to the very beginning of that line.
(this is with debian testing, gnuplot Version 3.8k patchlevel 1,
debian unstable offers 4.0)
This is also filed as bug under
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75403

There Thimo Neubauer also wrote

"""
I've already proposed to the upstream authors to use libeditline which
is at least better than the internal commandline-stuff and is licensed
under BSD-license. However my patches weren't accepted yet...
"""

From the README of libeditline:
"""
This is a line-editing library.  It can be linked into almost any
program to provide command-line editing and recall.

It is call-compatible with the FSF readline library, but it is a
fraction of the size (and offers fewer features).  It does not use
standard I/O.  It is distributed under a "C News-like" copyright.

"""
(I downloaded that from
http://packages.debian.org/testing/source/editline)

Best,

Arnd

Re: gnu readline / license

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

> Debian's gnuplot comes w/o gnu readline, which is very bad in my
> opinion. The reason is a license problem, which is documented by the
> package maintainer Thimo Neubauer <th...@de...> (in
> /usr/share/doc/gnuplot/README.Debian):

Solution to this problem is to implement <TAB>-expansion of filenames in
gnuplot's readline library. There was some discussion about it few years
ago, but nobody did it.
	TAB is the only difference, I guess?

--
PM

Re: gnu readline / license

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

Johannes Zellner writes:
> Hello,
 
 Johannes! Where have you been all the time? Good to hear from you :)

[...]
> Is there a chance to get the license changed, so that debian can ship
> gnuplot with the gnu readline?
 
 The gnuplot license? Not much of a chance. However, I think this could
 work if readline was distributed under the LGPL instead of GPL.

 Caveat: IANAL.

gnu readline / license

[Johannes Z. <joh...@ze...>]

Hello,

Debian's gnuplot comes w/o gnu readline, which is very bad in my
opinion. The reason is a license problem, which is documented by the
package maintainer Thimo Neubauer <th...@de...> (in
/usr/share/doc/gnuplot/README.Debian):

    libreadline
    -----------

    Yes, the built in readline of gnuplot is bad. However, libreadline
    cannot be used instead because it is licensed under the GPL, whereas
    gnuplot has special licenses (patches only). Linking those programs
    together is forbidden by the GPL. Please don't file bugs telling me to
    use libreadline in gnuplot...

Is there a chance to get the license changed, so that debian can ship
gnuplot with the gnu readline?

-- 
Johannes

Re: K&R C (was Re: Bugs in enhanced mode)

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

Daniel J Sebald writes:
[...]

 Daniel, please trim your replies. There is absolutely no point in quoting
 the whole previous message in your reply, please show some consideration.
 
> Anyway, is gnuplot.texi a generated file?  (I see something called 
> doc2texi.el)  If so, should it be in the cvsignore list so that it isn't 
> checked out when getting the latest CVS version?
 
 Yes, it's a generated file. I'd like to leave it in cvs because some
 people  may not have some form of emacs installed, and because .texi
 is a generic format that many other forms of documentation can be derived
 from.

Allin Cottrell writes:
[...] 
> How many people are there in the world who refuse to use an ISO/ANSI C
> compiler, but who want to be able to compile the latest and greatest
> gnuplot?

 It's not a question of refusal. Some systems out there have K&R compilers
 only, if they come with a compiler at all, and cannot be upgraded for
 some reason.

 That said, we should move to ISO/ANSI C, and let ansi2knr sort it out.
 As Lucas and myself recently found it, tis in turn will require a few
 changes in the code.

Re: K&R C (was Re: Bugs in enhanced mode)

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

  Nigel Nunn wrote:

>Another vote in favour of dropping K&R syntax.  I have a 
>wxWidgets demo that builds Gnuplot 4.x as a library, and 
>drives it programmatically.  But before adding another set 
>of #defines to the code, it would be good if the config 
>and pre-processor stuff could be cleaned up to simplify 
>the next few years of Gnuplot evolution. 
>

That I'd go along with.

Speaking of evolution, the CVS source tree is a moving target right now. 
 What are the near term, six month, one year plans?

Dan




-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: K&R C (was Re: Bugs in enhanced mode)

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

Allin Cottrell wrote:

>On Tue, 1 Jun 2004, Daniel J Sebald wrote:
>
>  
>
>>Would this be a tolerable hack?  Define a special type in some header
>>for char's as function arguments
>>
>>/* Throwback to K&R */
>>#ifdef __STDC__
>>#define ACHAR char
>>#else
>>#define ACHAR int
>>#endif
>>    
>>
>
>I strongly support the suggestion put forward by Hans-Berhard a few
>days ago, namely that support for 'K&R' should be dropped.  I'm not
>aware of any other serious software package that insists on supporting
>pre-1989 C compilers.  The effect is simply to complicate and
>obfuscate the gnuplot code.
>

That's true.  But I'm guessing one of the philosophies of Gnuplot is to 
accommodate as wide an audience as reasonably possible and to not 
continually squeeze out groups of users.  (If Gnuplot were trying to 
make a profit, different philosophy...)  I'll leave it up to those more 
familiar with software to decide if there is that wide of a K&R group 
left.  But, if there is support for a VAX, I would assume that 
supporting K&R C isn't that unreasonable.

Seriously, I've no strong opinion.  In fact, K&R have web pages.  Could 
drop them a short note and get their opinion.

>I'm aware that I don't have much standing in this debate because I
>have not contributed much to gnuplot.  On the other hand, I'd be more
>inclined to contribute were it not for the weird archaisms in the
>gnuplot code base.
>
>How many people are there in the world who refuse to use an ISO/ANSI C
>compiler, but who want to be able to compile the latest and greatest
>gnuplot?
>

Well, apparently Petr tried, hence the note in the source code.

Dan

RE: K&R C (was Re: Bugs in enhanced mode)

[Nigel N. <nN...@au...>]

Another vote in favour of dropping K&R syntax.  I have a 
wxWidgets demo that builds Gnuplot 4.x as a library, and 
drives it programmatically.  But before adding another set 
of #defines to the code, it would be good if the config 
and pre-processor stuff could be cleaned up to simplify 
the next few years of Gnuplot evolution. 
 
Nigel 
PS: congrats to HBB on PhD! 
 
-----Original Message-----
From: Allin Cottrell [mailto:cot...@wf...]
Sent: Wednesday, 2 June 2004 12:35 PM
To: gnuplot-beta
Subject: Re: K&R C (was Re: Bugs in enhanced mode)


On Tue, 1 Jun 2004, Daniel J Sebald wrote:

> Would this be a tolerable hack?  Define a special type in some header
> for char's as function arguments
>
> /* Throwback to K&R */
> #ifdef __STDC__
> #define ACHAR char
> #else
> #define ACHAR int
> #endif

I strongly support the suggestion put forward by Hans-Berhard a few
days ago, namely that support for 'K&R' should be dropped.  I'm not
aware of any other serious software package that insists on supporting
pre-1989 C compilers.  The effect is simply to complicate and
obfuscate the gnuplot code.

I'm aware that I don't have much standing in this debate because I
have not contributed much to gnuplot.  On the other hand, I'd be more
inclined to contribute were it not for the weird archaisms in the
gnuplot code base.

How many people are there in the world who refuse to use an ISO/ANSI C
compiler, but who want to be able to compile the latest and greatest
gnuplot?

Allin Cottrell


**********************************************************************************
This message is intended for the addressee named and may contain confidential and 
privileged information. If you are not the intended recipient please note that 
any form of distribution, copying or use of this communication or the information
in it is strictly prohibited and may be unlawful. 
If you receive this message in error, please delete it and notify the sender.

Keep up to date with what's happening in Australian sport.
Visit http://www.ausport.gov.au
**********************************************************************************

Re: K&R C (was Re: Bugs in enhanced mode)

[Allin C. <cot...@wf...>]

On Tue, 1 Jun 2004, Daniel J Sebald wrote:

> Would this be a tolerable hack?  Define a special type in some header
> for char's as function arguments
>
> /* Throwback to K&R */
> #ifdef __STDC__
> #define ACHAR char
> #else
> #define ACHAR int
> #endif

I strongly support the suggestion put forward by Hans-Berhard a few
days ago, namely that support for 'K&R' should be dropped.  I'm not
aware of any other serious software package that insists on supporting
pre-1989 C compilers.  The effect is simply to complicate and
obfuscate the gnuplot code.

I'm aware that I don't have much standing in this debate because I
have not contributed much to gnuplot.  On the other hand, I'd be more
inclined to contribute were it not for the weird archaisms in the
gnuplot code base.

How many people are there in the world who refuse to use an ISO/ANSI C
compiler, but who want to be able to compile the latest and greatest
gnuplot?

Allin Cottrell