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

Re: misc for readmes

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

> > BUGS:
> >
> >  *) compiling help file with Visual C++ 4.0/Windows NT
> >     The help compiler coming with this version of MSVC++ appers unable
> >     to compile gnuplot.rtf.  As a workaround download the freely
> >     available "Help Workshop" from Microsoft and use that instead.
> >
> >
> > => should not this be written to the makefile of MSVC++ ?
>
> No.  You need this help compiler for *all* Windows builds.  If at all, it
> would have to be added to all of them (makefile.{nt,cyg,mgw,win}).
>
> > Or to the preface of "MS-Windows" section in INSTALL
>
> That'd be another good place, indeed.

I think it is the right place where it should be -- as it is already in
makefile.mgw, .cyg:

# To compile the .hlp file you need hcw either out of Microsoft SDK or MS Help
# Workshop. The latter can be obtained at www.helpmaster.com/help/devaids.htm.
# Put the path to hcw here unless it is already in PATH:
#HCWPATH = /Program\ Files/Help\ Workshop/
#HCWPATH = h:/mssdk/bin/
HCW = $(HCWPATH)hcw
# Switches are for HCW 4.03:
HCWFLAG =


Because, it's a makefile-related information, and not a BUG.
Please remove this from BUGS and copy the text from makefile.mgw to
makefile.nt.


---
PM

Re: misc for readmes

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

> > My old complaint:
> > I always find the "Note 3" completely useless and vote for removing it.
>
> That would be very unfriendly to the author of gnuplot-mode.  We can't
> just swallow a copy of his package into ours without explaining why that
> copy is incomplete.
>
> > (I don't consider myself to be an ordinary user of gnuplot but never met
> > gnuplot-mode; and I wonder how gnuplot 4.0 is affected by some files
> > not being present from this mode...)
>
> Frankly, whether or not anyone of *us* is using that package is completely
> irrelevant.  gnuplot-mode is a user-interface to gnuplot that people are

Ok then but ordinary people have no idea what that front-end is for, and
just got confused immediately in README.1st. Could you please add 1 sentence
or a better title like "gnuplot-mode for emacs (??)  for (arbitrary??) OS".

Then, about those file which are missing (compared to what? link to the web
site of this mode as the "Front-ends" section on gnuplot's web page?), could
rather be written in its own directory then in README.1st which will be read
by more people then lisp/README.


---
PM

Re: misc for readmes

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:


> 
> gnuplot.sf.net  as a download side shoule be mentioned too

Of course. It is in my working copy.  Except that gnuplot.sf.net itself
won't be the download site.  I'll point at the file release system
below sf.net/projects/gnuplot instead.

>   Send comments and requests for help to <inf...@da...>
>   Send bugs, suggestions and mods to <inf...@da...>
> 
> Shoudn't this be changed?

Again: already done in my working copy.

> BUGS:
> 
>  *) compiling help file with Visual C++ 4.0/Windows NT
>     The help compiler coming with this version of MSVC++ appers unable
>     to compile gnuplot.rtf.  As a workaround download the freely
>     available "Help Workshop" from Microsoft and use that instead.
> 
> 
> => should not this be written to the makefile of MSVC++ ?

No.  You need this help compiler for *all* Windows builds.  If at all, it
would have to be added to all of them (makefile.{nt,cyg,mgw,win}).

> Or to the preface of "MS-Windows" section in INSTALL

That'd be another good place, indeed.

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

Re: misc for readmes

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> Here are some my observations (I've just read few INSTALL and README*,
> but no time to edit it today):
> 
> ***
> README.1ST
> 
> Text:
> generate and convert the images at the same time, as in this example:
>         set terminal png medium font LucidaSansDemiBold
>         set output '| convert png:- image.gif'
> 
> 
> I think it should be like
>     set term png font arial
> or
>     set term png medium
> but not both together

Right.  Will change that.

>     set term png font arial
>     set term png medium
> => it does not revert to medium; someone can have a look?

Ouch.  But it should be trivial to fix.  I'll have 'set term medium'
and friends turn off the TTF font option.

> My old complaint:
> I always find the "Note 3" completely useless and vote for removing it.

That would be very unfriendly to the author of gnuplot-mode.  We can't
just swallow a copy of his package into ours without explaining why that
copy is incomplete.

> (I don't consider myself to be an ordinary user of gnuplot but never met
> gnuplot-mode; and I wonder how gnuplot 4.0 is affected by some files
> not being present from this mode...)

Frankly, whether or not anyone of *us* is using that package is completely
irrelevant.  gnuplot-mode is a user-interface to gnuplot that people are
using (there's been the occasional question about it, including the one
which triggered this weekends' rediscovery of the Windows' !-command 
problem), and they have the right to know how the stuff in the 'lisp'
directory relates to the separate package they may have installed.

> There is a "gnuplot reference card" in docs/ -- but untouched since 1998.
> Could somebody edit it a bit (at least like set no => unset)?

Will do.

> Also, in lisp/gpelcard.tex, looks like yet another gp card -- but this is
> a bit wrong and outdated like here:
> 
> \item[Using pm3d] \hfill \\
>   All features of the pm3d patch to \textsc{gnuplot} should be
>   available when using gnuplot-mode.  One particularly useful feature
>   of pm3d is the ability to push a cursor position into the
>   clipboard.  This is done by double-clicking \texttt{mouse-1} in the
>   plot window, then doing \texttt{M-x yank-clipboard-selection}
>   (usually bound to \texttt{mouse-2}) in the gnuplot script buffer.
> 
> ... author obviously means Using mouse, and it's no more a patch.
> 
> How is this ref card related to docs/ one?

It's an indepentend work.  Meant to explain gnuplot-mode, not gnuplot
itself.  

> To be merged, deleted, ...?

To be kept (optionally updated slightly).


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

Re: ! shell-escapes on Windows.

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> Oh really, it was not waiting to the end of execution ... does it wait now?

Apparently yes.  And even if it doesn't, that's still the best we can
do right now without cancelling the release.

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

Re: misc for readmes

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

remained in my clipboard:

****

README:

gnuplot.sf.net  as a download side shoule be mentioned too

***

gnuplot, when starts, prints:

  Send comments and requests for help to <inf...@da...>
  Send bugs, suggestions and mods to <inf...@da...>

Shoudn't this be changed?


***

BUGS:


 *) compiling help file with Visual C++ 4.0/Windows NT
    The help compiler coming with this version of MSVC++ appers unable
    to compile gnuplot.rtf.  As a workaround download the freely
    available "Help Workshop" from Microsoft and use that instead.


=> should not this be written to the makefile of MSVC++ ?
   (is it makefile.nt?)  I guess nobody will look to BUGS for this piece of
info.

Or to the preface of "MS-Windows" section in INSTALL


---
PM

Re: ! shell-escapes on Windows.

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

> > Proposed solution #1: get rid of winsystem() altogether.  Just call
> > system() like on all other platforms, and trust the compiler authors to
> > know what they're doing. Drawback: there's no time to go through a test
> > of'em all to make sure that assumption is reliable.
>
> Seizing an opportunity to have it tested on the second most important
> platform (besides Cygwin/MinGW32, that is), i.e. MSVC++,  I concluded
> that this is good enough to go, so I checked it in.
>
> (I actually left the code in, just disabled the actual call of
> winsystem() by an additional conditional, so we can tell users how
> to re-enable it easily if they have to...)

Oh really, it was not waiting to the end of execution ... does it wait now?

---
PM

misc for readmes

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

Here are some my observations (I've just read few INSTALL and README*,
but no time to edit it today):

***
README.1ST

Text:
generate and convert the images at the same time, as in this example:
        set terminal png medium font LucidaSansDemiBold
        set output '| convert png:- image.gif'


I think it should be like
    set term png font arial
or
    set term png medium
but not both together


WOW, there is a BUG in png:

    set term png font arial
    set term png medium
=> it does not revert to medium; someone can have a look?


---

My old complaint:
I always find the "Note 3" completely useless and vote for removing it.
(I don't consider myself to be an ordinary user of gnuplot but never met
gnuplot-mode; and I wonder how gnuplot 4.0 is affected by some files
not being present from this mode...)

***

GNUPLOT REFERENCE CARD(S)

There is a "gnuplot reference card" in docs/ -- but untouched since 1998.
Could somebody edit it a bit (at least like set no => unset)?
It could be put into web page if someone contributes.


Also, in lisp/gpelcard.tex, looks like yet another gp card -- but this is
a bit wrong and outdated like here:

\item[Using pm3d] \hfill \\
  All features of the pm3d patch to \textsc{gnuplot} should be
  available when using gnuplot-mode.  One particularly useful feature
  of pm3d is the ability to push a cursor position into the
  clipboard.  This is done by double-clicking \texttt{mouse-1} in the
  plot window, then doing \texttt{M-x yank-clipboard-selection}
  (usually bound to \texttt{mouse-2}) in the gnuplot script buffer.

... author obviously means Using mouse, and it's no more a patch.

How is this ref card related to docs/ one?
To be merged, deleted, ...?


---
PM

Re: ! shell-escapes on Windows.

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

On Mon, 12 Apr 2004, Hans-Bernhard Broeker wrote:

[...]

> Proposed solution #1: get rid of winsystem() altogether.  Just call
> system() like on all other platforms, and trust the compiler authors to
> know what they're doing. Drawback: there's no time to go through a test
> of'em all to make sure that assumption is reliable.

Seizing an opportunity to have it tested on the second most important
platform (besides Cygwin/MinGW32, that is), i.e. MSVC++,  I concluded
that this is good enough to go, so I checked it in.

(I actually left the code in, just disabled the actual call of 
winsystem() by an additional conditional, so we can tell users how
to re-enable it easily if they have to...)

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

! shell-escapes on Windows.

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

Gents,

an old issue just resurfaced after laying dormant for most of 2 years.
It's the behaviour of the '!' shell-escape on Windows platforms, and was
brought to our attention by Don Taber in 2002 without every reaching a 
conclusion.

Here's the beef: for a reason that's not explained particularly well,
wgnuplot rolls it's own version of the system() function to implement the
'!' command.  The home-grown version relies on a deprecated Windows API
entry WinExec(). That probably even made sense back in the days of 16-bit
Windows-3.x. but it's currently experiencing at least two serious
drawbacks.  Does anybody here still remember when, or why that code was
put in there in the first place?  It must have been there since at least
3.6.  For all I know, it could even be from the initial port to Windows.

The code in question is command.c:winsystem(), which essentially does
this:

	if (WinExec(cmd) fails)
	  WinExec("%COMSPEC% /c " + cmd);

The problems are:

1) WinExec() doesn't really wait for the called programm to finish the way
system() is supposed to.  This wreaks havoc to gnuplot scripts like

	! tool input -o output.dat
	plot 'output.dat'

2) WinExec doesn't support redirection or internal commands of the command
line processor.

The second WinExec() call is supposed to address issue 2) by handing the
job over to the shell, but fails to do so, silently, if the command is an
external .exe that just silently ignores the redirection options (--> the
first WinExec() succeeds).  It can be worked around by "hiding" this fact
from WinExec(), e.g. by prepending a space:

	!command > output.dat

will fail, but

	! command > output.dat

seems to work.  That's stupid, to put it mildly. And it still fails to
wait for the termination of the external command.

Proposed solution #1: get rid of winsystem() altogether.  Just call
system() like on all other platforms, and trust the compiler authors to
know what they're doing. Drawback: there's no time to go through a test
of'em all to make sure that assumption is reliable.

Proposed solution #2: only get rid of the if(), so the job always ends up
being done by the shell.  Drawback: wouldn't solve the wait-for-subcommand
issue at all.

Proposed solution #3: Like #2, but also change from WinExec to the
Win32-only function CreateProcess() with appropriate waiting.

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

Re: "make" touches /usr/share/emacs/site-lisp/

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

On Sat, 10 Apr 2004, James R. Van Zandt wrote:

[...]
> Both were generated by the same version of autoconf:
>   $ grep "generated.*autoconf" config.status /tmp/working/lisp/config.status
>   config.status:    echo "./config.status generated by autoconf version 2.13"
>   /tmp/working/lisp/config.status:    echo "./config.status generated by autoconf version 2.13"

This is wrong.  gnuplot doesn't work with autoconf-2.13 any longer.  You
must have version 2.52 or higher, as mentioned in the AC_PREREQ() of the
master configure.in.  Issued at hand are:

1) no, I don't think you're supposed to run ./configure in the lisp
directory manually.  Leave that to the master ./configure script and
tools.

2) it's not exactly a surprise that autoconf files generated by 2.13 with
automake-1.4/autoconf-2.52 generated ones don't mix well.

As a fix, I'll bump AC_PREREQ() in lisp/configure up to 2.52.

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

"make" touches /usr/share/emacs/site-lisp/

[James R. V. Z. <jr...@co...>]

somebody wrote:
> The only problem/annoyance I have is that the 'make' process tries
> to update files in the system directory /usr/share/emacs/site-lisp/,
> which means that I get error messages if I'm not building as root.
> Seems to be harmless, though.

I'm trying to reconstruct a different problem, and tripped over this.
My builds failed like this:

  make[2]: Entering directory `/home/local/src/gnuplot/cvs/gnuplot/lisp'
  /bin/sh ./mkinstalldirs /usr/local/share/emacs/site-lisp
   /usr/bin/install -c -m 644 gnuplot-gui.el /usr/local/share/emacs/site-lisp/gnuplot-gui.el
  /usr/bin/install: cannot remove `/usr/local/share/emacs/site-lisp/gnuplot-gui.el': Permission denied
  ...
  
I'm appending lisp/Makefile (sorry about the length).  Apparently the
offending commands come from the "install-els" target via this chain:
   
  all -> all-redirect -> all-am -> $(LISP) -> $(INSTALL_LISP)
      -> install-lisp -> install-els

the suspicious line being:

  all-am: Makefile $(LISP)

which comes from an identical line in lisp/Makefile.in.

I can reproduce this by running this in the lisp/ directory:

  make clean && ./prepare ; automake --add-missing --copy &&
  autoconf && ./configure && make

(There's no "prepare" script there, so that part fails.)
However, running the same commands in the top directory fixes things,
and the build succeeds.

Here are the file differences between the working and failing versions
of the lisp/ directory:
  
  $ diff --brief -r . /tmp/working/lisp
  Files ./Makefile and /tmp/working/lisp/Makefile differ
  Files ./Makefile.in and /tmp/working/lisp/Makefile.in differ
  Files ./config.status and /tmp/working/lisp/config.status differ
  Only in /tmp/working/lisp: gnuplot-gui.elc
  Only in /tmp/working/lisp: gnuplot.elc

Here are the differences in config.status:

  $ diff -u /tmp/working/lisp/config.status config.status
  --- /tmp/working/lisp/config.status	2004-04-10 10:55:38.000000000 -0400
  +++ config.status	2004-04-10 10:55:49.000000000 -0400
  @@ -4,7 +4,7 @@
   # This directory was configured as follows,
   # on host vanzandt:
   #
  -# ./configure  --prefix=/usr/local --cache-file=/dev/null --srcdir=.
  +# ./configure 
   #
   # Compiler output produced by configure, useful for debugging
   # configure, is in ./config.log if it exists.
  @@ -14,8 +14,8 @@
   do
     case "$ac_option" in
     -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
  -    echo "running ${CONFIG_SHELL-/bin/sh} ./configure  --prefix=/usr/local --cache-file=/dev/null --srcdir=. --no-create --no-recursion"
  -    exec ${CONFIG_SHELL-/bin/sh} ./configure  --prefix=/usr/local --cache-file=/dev/null --srcdir=. --no-create --no-recursion ;;
  +    echo "running ${CONFIG_SHELL-/bin/sh} ./configure  --no-create --no-recursion"
  +    exec ${CONFIG_SHELL-/bin/sh} ./configure  --no-create --no-recursion ;;
     -version | --version | --versio | --versi | --vers | --ver | --ve | --v)
       echo "./config.status generated by autoconf version 2.13"
       exit 0 ;;
  
Both were generated by the same version of autoconf:
  $ grep "generated.*autoconf" config.status /tmp/working/lisp/config.status
  config.status:    echo "./config.status generated by autoconf version 2.13"
  /tmp/working/lisp/config.status:    echo "./config.status generated by autoconf version 2.13"

I don't see any significant differences, and in fact executing the
working config.status in the failing directory, then typing "make"
still fails.
  
Comparing the two versions of Makefile.in shows:
  
  $ diff -u /tmp/working/lisp/Makefile.in Makefile.in
  --- /tmp/working/lisp/Makefile.in       2004-04-10 10:55:38.000000000
      -0400
  +++ Makefile.in 2004-04-10 10:55:47.000000000 -0400
  @@ -38,7 +38,7 @@
   pkglibdir = $(libdir)/@PACKAGE@
   pkgincludedir = $(includedir)/@PACKAGE@
  
  -top_builddir = ..
  +top_builddir = .
...
  @@ -168,13 +221,14 @@
   install-am: all-am
          @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
   install: install-am
  -uninstall-am: uninstall-local
  +uninstall-am: uninstall-INSTALLLISP uninstall-local
   uninstall: uninstall-am
  -all-am: Makefile
  +all-am: Makefile $(LISP)
   all-redirect: all-am
   install-strip:
          $(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
   installdirs:
  +       $(mkinstalldirs)  $(DESTDIR)$(INSTALLdir)
  
  
   mostlyclean-generic:

The initial lines of the files are the same, so the same version
of automake created both files.

Although I've made some progress, I do not understand what happened
here.  The first time, I had started in the top directory, _not_ in
lisp/.

For what it's worth, here are my default program versions:

  $ aclocal --version
  aclocal (GNU automake) 1.4-p6
  ...
  $ automake --version
  automake (GNU automake) 1.4-p6
  ...
  $ autoconf --version
  Autoconf version 2.13
  
However, I do have other versions installed:
  $ ls /usr/bin/auto{make,conf}*
  /usr/bin/autoconf	   /usr/bin/autoconf2.50  /usr/bin/automake-1.7
  /usr/bin/autoconf-wrapper  /usr/bin/automake
  /usr/bin/autoconf2.13	   /usr/bin/automake-1.4

	- Jim Van Zandt

--------------------  failing version of Makefile  -----------------
# Makefile.in generated automatically by automake 1.4-p6 from Makefile.am

# Copyright (C) 1994, 1995-8, 1999, 2001 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.


SHELL = /bin/sh

srcdir = .
top_srcdir = .

prefix = /usr/local
exec_prefix = ${prefix}

bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include

DESTDIR =

pkgdatadir = $(datadir)/gnuplot-mode
pkglibdir = $(libdir)/gnuplot-mode
pkgincludedir = $(includedir)/gnuplot-mode

top_builddir = .

ACLOCAL = aclocal-1.4
AUTOCONF = autoconf
AUTOMAKE = automake-1.4
AUTOHEADER = autoheader

INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL} $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = ${INSTALL} -m 644
INSTALL_SCRIPT = ${INSTALL}
transform = s,x,x,

NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
host_alias = 
host_triplet = @host@
CC = @CC@
DVIPS = dvips
EMACS = emacs
HAVE_LIB = @HAVE_LIB@
INFO_LOOK_ELC = 
INSTALL_LISP = install-lisp
LATEX = latex
LIB = @LIB@
LISPFILES = elcs
LTLIB = @LTLIB@
MAKEINFO = /usr/bin/makeinfo
PACKAGE = gnuplot-mode
PDFLATEX = pdflatex
VERSION = 0.6.0
lispdir = $(prefix)/share/emacs/site-lisp

AUTOMAKE_OPTIONS = foreign 1.2h

ELS = gnuplot-gui.el gnuplot.el info-look.20.2.el info-look.20.3.el
ELCS = gnuplot.elc gnuplot-gui.elc 
EXTRA_DIST = dot.el dotemacs gnuplot.el.old gpelcard.dvi gpelcard.pdf gpelcard.ps gpelcard.tex $(ELS)

CLEANFILES = $(ELCS) gpelcard.pdf gpelcard.ps gpelcard.dvi gpelcard.log gpelcard.aux
DISTCLEANFILES = info-look.el

BYTEC = $(EMACS) -batch -q -no-site-file -l $(srcdir)/dot.el -f batch-byte-compile

SUFFIXES = .el .elc .pdf .ps .tex
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_CLEAN_FILES = 
CFLAGS = @CFLAGS@
COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@
LISP =  $(INSTALL_LISP)

DIST_COMMON =  README COPYING ChangeLog INSTALL Makefile.am Makefile.in \
aclocal.m4 configure configure.in install-sh missing mkinstalldirs


DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)

TAR = tar
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
.SUFFIXES: .el .elc .pdf .ps .tex
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) 
	cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile

Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status $(BUILT_SOURCES)
	cd $(top_builddir) \
	  && CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status

$(ACLOCAL_M4):  configure.in 
	cd $(srcdir) && $(ACLOCAL)

config.status: $(srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
	$(SHELL) ./config.status --recheck
$(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4) $(CONFIGURE_DEPENDENCIES)
	cd $(srcdir) && $(AUTOCONF)

install-INSTALLLISP: $(INSTALL_LISP) $(ELCFILES)
	@$(NORMAL_INSTALL)
	@if test -n "$(lispdir)"; then \
	  $(mkinstalldirs) $(DESTDIR)$(INSTALLdir); \
	  list='$(INSTALL_LISP)'; for p in $$list; do \
	    if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \
	    echo " $(INSTALL_DATA) $$d$$p $(DESTDIR)$(INSTALLdir)/$$p"; \
	    $(INSTALL_DATA) $$d$$p $(DESTDIR)$(INSTALLdir)/$$p; \
	    if test -f $${p}c; then \
	      echo " $(INSTALL_DATA) $${p}c $(DESTDIR)$(INSTALLdir)/$${p}c"; \
	      $(INSTALL_DATA) $${p}c $(DESTDIR)$(INSTALLdir)/$${p}c; \
	    else : ; fi; \
	  done; \
	else : ; fi

uninstall-INSTALLLISP:
	@$(NORMAL_UNINSTALL)
	@if test -n "$(lispdir)"; then \
	  list='$(INSTALL_LISP)'; for p in $$list; do \
	    rm -f $(DESTDIR)$(INSTALLdir)/$$p $(DESTDIR)$(INSTALLdir)/$${p}c; \
	  done; \
	else : ; fi
tags: TAGS
TAGS:


distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)

# This target untars the dist file and tries a VPATH configuration.  Then
# it guarantees that the distribution is self-contained by making another
# tarfile.
distcheck: dist
	-rm -rf $(distdir)
	GZIP=$(GZIP_ENV) $(TAR) zxf $(distdir).tar.gz
	mkdir $(distdir)/=build
	mkdir $(distdir)/=inst
	dc_install_base=`cd $(distdir)/=inst && pwd`; \
	cd $(distdir)/=build \
	  && ../configure --srcdir=.. --prefix=$$dc_install_base \
	  && $(MAKE) $(AM_MAKEFLAGS) \
	  && $(MAKE) $(AM_MAKEFLAGS) dvi \
	  && $(MAKE) $(AM_MAKEFLAGS) check \
	  && $(MAKE) $(AM_MAKEFLAGS) install \
	  && $(MAKE) $(AM_MAKEFLAGS) installcheck \
	  && $(MAKE) $(AM_MAKEFLAGS) dist
	-rm -rf $(distdir)
	@banner="$(distdir).tar.gz is ready for distribution"; \
	dashes=`echo "$$banner" | sed s/./=/g`; \
	echo "$$dashes"; \
	echo "$$banner"; \
	echo "$$dashes"
dist: distdir
	-chmod -R a+r $(distdir)
	GZIP=$(GZIP_ENV) $(TAR) chozf $(distdir).tar.gz $(distdir)
	-rm -rf $(distdir)
dist-all: distdir
	-chmod -R a+r $(distdir)
	GZIP=$(GZIP_ENV) $(TAR) chozf $(distdir).tar.gz $(distdir)
	-rm -rf $(distdir)
distdir: $(DISTFILES)
	-rm -rf $(distdir)
	mkdir $(distdir)
	-chmod 777 $(distdir)
	here=`cd $(top_builddir) && pwd`; \
	top_distdir=`cd $(distdir) && pwd`; \
	distdir=`cd $(distdir) && pwd`; \
	cd $(top_srcdir) \
	  && $(AUTOMAKE) --include-deps --build-dir=$$here --srcdir-name=$(top_srcdir) --output-dir=$$top_distdir --foreign Makefile
	@for file in $(DISTFILES); do \
	  d=$(srcdir); \
	  if test -d $$d/$$file; then \
	    cp -pr $$d/$$file $(distdir)/$$file; \
	  else \
	    test -f $(distdir)/$$file \
	    || ln $$d/$$file $(distdir)/$$file 2> /dev/null \
	    || cp -p $$d/$$file $(distdir)/$$file || :; \
	  fi; \
	done
info-am:
info: info-am
dvi-am:
dvi: dvi-am
check-am: all-am
check: check-am
installcheck-am:
installcheck: installcheck-am
install-exec-am:
install-exec: install-exec-am

install-data-am: install-INSTALLLISP
	@$(NORMAL_INSTALL)
	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
install-data: install-data-am

install-am: all-am
	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-am
uninstall-am: uninstall-INSTALLLISP uninstall-local
uninstall: uninstall-am
all-am: Makefile $(LISP)
all-redirect: all-am
install-strip:
	$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
installdirs:
	$(mkinstalldirs)  $(DESTDIR)$(INSTALLdir)


mostlyclean-generic:

clean-generic:
	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)

distclean-generic:
	-rm -f Makefile $(CONFIG_CLEAN_FILES)
	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
	-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)

maintainer-clean-generic:
mostlyclean-am:  mostlyclean-generic

mostlyclean: mostlyclean-am

clean-am:  clean-generic mostlyclean-am

clean: clean-am

distclean-am:  distclean-generic clean-am distclean-local

distclean: distclean-am
	-rm -f config.status

maintainer-clean-am:  maintainer-clean-generic distclean-am
	@echo "This command is intended for maintainers to use;"
	@echo "it deletes files that may require special tools to rebuild."

maintainer-clean: maintainer-clean-am
	-rm -f config.status

.PHONY: uninstall-INSTALLLISP install-INSTALLLISP tags distdir info-am \
info dvi-am dvi check check-am installcheck-am installcheck \
install-exec-am install-exec install-data-am install-data install-am \
install uninstall-local uninstall-am uninstall all-redirect all-am all \
installdirs mostlyclean-generic distclean-generic clean-generic \
maintainer-clean-generic clean mostlyclean distclean maintainer-clean


.el.elc:
	$(BYTEC) $<

.dvi.ps:
	$(DVIPS) -o $@ $<

.tex.dvi:
	$(LATEX) $<

.tex.pdf:
	$(PDFLATEX) $<

all: elcs

elcs: $(ELCS)

noelcs:

pdf: gpelcard.pdf
ps: gpelcard.ps

install-data-hook: install-lisp

install-lisp: install-els install-elcs
install-nolisp:

install-els: $(ELS)
	$(mkinstalldirs) $(DESTDIR)$(lispdir)
	@for p in $(ELS) ; do \
	  echo " $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p"; \
	  $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p; \
	done

install-elcs: $(ELCS)
	$(mkinstalldirs) $(DESTDIR)$(lispdir)
	@for p in $(ELCS) ; do \
	  echo " $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p"; \
	  $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p; \
	done

uninstall-local:
	@$(NORMAL_UNINSTALL)
	@for p in $(ELCS) $(ELS) ; do \
	  rm -f $(DESTDIR)$(lispdir)/$$p; \
	done

distclean-local:
	@if test "$(top_srcdir)" != "$(top_builddir)" ; then \
	  rm -f gnuplot.el gnuplot-gui.el gpelcard.tex ; \
	fi

# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

Re: Ready for wrap-up everyone?

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

On Fri, 9 Apr 2004, Petr Mikulik wrote:

> What is "Bruce Ravel's gnuplot-mode distribution"? An old binary
> distribution for Windows? Why it contains info file then?

See the final paragraph of INSTALL.  gnuplot-mode used to be part of
gnuplot itself, then it was taken up and developed into a standalone
package by Bruce Ravel.  Lars has integrated a copy of Bruce's work into
the 3.8 series, which has become the 'lisp' subdirectory of gnuplot.

> I don't see this text relevant for gnuplot 4.0. I don't think it has to
> be "README.1st".

It may not have to be in README.1st, but it does have to be somewhere.

> That an impatient user would go and edit something in term.h.

Well, believe it or not, there are indeed cases where people would and
should do that.  We have autoconf choices mainly for those terminals that
require external libraries, but there are quite a number of others for
which the canonical way to disable them *is* to directly edit term.h

> And if you install gd library, you will no get gif support nowadays -- as
> said in FAQ.

And in README.1st.  Which, as it's name says, people are supposed to have
looked into before they read INSTALL.

> > > Also, README.1ST speaks only about GIFs. What about deleting this file
> > > and reference from README to FAQ?
> >
> > README.1st is the first-stop README file for the source distribution.
> > It's not even necessarily being distributed with binary distributions.
> 
> It's nowhere written why and why should read this document.

~The name explains that by itself.  "Read me first!".  That's about the
most obvious you can get.

> For source distribution, one should read INSTALL. 

*After* reading README.1st.  And README.1st should say so.  It will ---
I'm working on it.


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

Re: TODO

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

> > version, but the distributors won't necessarily know which files these
> > are. I would *hope* they at least think to install the demo files, but
> > they may not know to first run 'make' in the demo directory to generate
> > binary data files.

Yes, if there is no "make" option to install all files *we* think should
belong to a complete gnuplot distribution, then we can expect every linux
distribution and will be different. Why somebody else should know whether
e.g. tutorial is useful for users or not?

> They don't have to --- running 'make' in the main directory is perfectly
> sufficient.  If they don't know how to build a fully autoconf/automake
> wrapped package like gnuplot, they're in the wrong business pretending to
> be a Linux distributor anyway.

No, "make install" is not sufficient. For example, compares its result to
that of my binary releases. There is no such "make install blabla" I guess.

> > The pm3d/contrib directory?

Hmm I would also like to know how to organize them better -- or put to web?
I thought gnuplot could be distributed with a library of useful scripts, but
nobody has proposed such a structure.

> > The old README.* files?

Should be merged with gnuplot.doc and INSTALL, or to web.

I've done this for OS/2-related documentation and some others. Maybe someone
could continue with other files? Some info (like from 3D data) would be much
more useful to be in gnuplot.doc.

> > The tutorial?

I've upgraded it for 4.0.

> If we want to give them a hand explaining them what we would like them
> to put in their binary packages --- fine, add a paragraph to INSTALL
> about that.

make completeinstall  ??

> OTOH, why should we expect them to put stuff in there that our
> own 'make install' doesn't put up anywhere?

Exactly.

---
PM

Re: Ready for wrap-up everyone?

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

> > >  Note 3
> > >  ------
> > >  some files from Bruce Ravel's gnuplot-mode distribution have
> > >    not been included here, namely
> > >
> > >    o INSTALL              (covered by gnuplot install instructions)
> > >    o Win9x/INSTALL.Win9x
> > >    o Win9x/pgnuplot.c     (already in src/win)
> > >    o gnuplot.info         (can be created from docs/gnuplot.texi)
> > >    o gpelcard.ps          (can be created from lisp/gpelcard.tex)
> > >    o install-sh, mkinstalldirs  (provided by gnuplot)
> >
> >
> > I don't understand what this text tries to say nowadays. Therefore I propose
> > to delete it.
>
> Deleting what you don't understand might be dangerous.  I think it really
> should stay.

What is "Bruce Ravel's gnuplot-mode distribution"? An old binary
distribution for Windows? Why it contains info file then?

I don't see this text relevant for gnuplot 4.0. I don't think it has to be
"README.1st".


> [Note this is from INSTALL, and it goes under the heading "For the
> impatient."  This is not the principal installation instruction.]
>
> > First, tune term.h to choose which terminal drivers you wish to enable.
> > If you want to support gif output, you need to download, compile and
> > install the gd library : see term/gif.trm for details.
>
> > I don't think that's like that.
>
> What exactly in this do you think is "not like that"?

That an impatient user would go and edit something in term.h.

And if you install gd library, you will no get gif support nowadays -- as
said in FAQ.


> > Also, README.1ST speaks only about GIFs. What about deleting this file
> > and reference from README to FAQ?
>
> README.1st is the first-stop README file for the source distribution.
> It's not even necessarily being distributed with binary distributions.

It's nowhere written why and why should read this document.

For source distribution, one should read INSTALL. And that first paragraph
of of README.1ST is duplicated in section "For impatient user".

And README.1ST also writes how to convert images into gif -- i.e. user-space
utilities.

So the information there is a mess. I propose to delete the file completely,
unless someone gives it a sense.

---
PM

Re: TODO

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

On Thu, 8 Apr 2004, Ethan Merritt wrote:

> version, but the distributors won't necessarily know which files these
> are. I would *hope* they at least think to install the demo files, but
> they may not know to first run 'make' in the demo directory to generate
> binary data files.

They don't have to --- running 'make' in the main directory is perfectly
sufficient.  If they don't know how to build a fully autoconf/automake
wrapped package like gnuplot, they're in the wrong business pretending to
be a Linux distributor anyway.

> The pm3d/contrib directory?  
> The old README.* files?
> The tutorial?
> ps_guide.ps?

If we want to give them a hand explaining them what we would like them
to put in their binary packages --- fine, add a paragraph to INSTALL
about that.  

OTOH, why should we expect them to put stuff in there that our
own 'make install' doesn't put up anywhere?

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

Re: TODO

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

On Thursday 08 April 2004 04:00 pm, you wrote:
> If RPM or .spec files really were compatible between a large
> subset of the major distros, it might be worth it, but AFAIK, they're
> not. I see no reason why we should do the distributor's work for them.

Right. But a key part of the spec file in any case is simply a list of
the files that should be installed.  There may be files in the source
tree that we think should be kept for user reference in the installed
version, but the distributors won't necessarily know which files these
are. I would *hope* they at least think to install the demo files, but
they may not know to first run 'make' in the demo directory to generate
binary data files.
The pm3d/contrib directory?  
The old README.* files?
The tutorial?
ps_guide.ps?

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

Re: TODO

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

On Thu, 8 Apr 2004, Ethan Merritt wrote:

> On Thursday 08 April 2004 09:46 am, Petr Mikulik wrote:
> > Please have a look to that file...
> 
> BUGS - maybe just refer people to the bug-tracker on 
> SourceForge.

Not unless we file all the bugs currently in there into the Tracker first.  
For the moment, I guess we should err toward the lazy option and just keep
it as it is.  It's short, and the Bug Tracker is mentioned prominently.

> I think all those docs/old/README.* files can be deleted.

No.  At least some of these files are a significant part of the legacy of
gnuplot.  Pretending all that history never happened would be the wrong
thing to do at this time, IMHO.

In what little time is left, I suggest we concentrate our efforts on those
things that really *need* improvement.  Removing stale stuff should be
postponed to the general house-cleaning session we'll have to do right
after the release anyway.

> The mention of an INF bug for binary files- I'm not sure.
> I can't find any record of such a bug on the SourceForge bug list.

There was a bug with reading Inf and NaN's from ordinary data files which
I fixed pretty recently (2004-03-04).  I guess that will plug this one,
too, because the fix works one level above the datafile reading.

I'll delete this from TODO.  If it's an actual bug, somebody should file
it at SF.net.

> A linux rpm - hmm.  I think the distros will probably do that to
> suit themselves.  If necessary I can make a Mandrake rpm.
> that might or might not work under other rpm-based distros.

Making our own binary packages for Linux distros would be waste of effort.  
They'll all make their own ones anyway, eventually, so whatever we do
would be obsolete with the next distribution release (if not earlier).  
If RPM or .spec files really were compatible between a large subset of the
major distros, it might be worth it, but AFAIK, they're not. I see no
reason why we should do the distributor's work for them.

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

Re: Ready for wrap-up everyone?

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

On Thu, 8 Apr 2004, Petr Mikulik wrote:

> > *) File README.1st:
> >
> > This text is to be deleted?
> >
> >  Note 3
> >  ------
> >  some files from Bruce Ravel's gnuplot-mode distribution have
> >    not been included here, namely
> >
> >    o INSTALL              (covered by gnuplot install instructions)
> >    o Win9x/INSTALL.Win9x
> >    o Win9x/pgnuplot.c     (already in src/win)
> >    o gnuplot.info         (can be created from docs/gnuplot.texi)
> >    o gpelcard.ps          (can be created from lisp/gpelcard.tex)
> >    o install-sh, mkinstalldirs  (provided by gnuplot)
> 
> 
> I don't understand what this text tries to say nowadays. Therefore I propose
> to delete it.

Deleting what you don't understand might be dangerous.  I think it really 
should stay.

> And what about this text:

[Note this is from INSTALL, and it goes under the heading "For the
impatient."  This is not the principal installation instruction.]

> First, tune term.h to choose which terminal drivers you wish to enable.
> If you want to support gif output, you need to download, compile and
> install the gd library : see term/gif.trm for details.

> I don't think that's like that.

What exactly in this do you think is "not like that"?

> Also, README.1ST speaks only about GIFs. What about deleting this file
> and reference from README to FAQ?

README.1st is the first-stop README file for the source distribution.
It's not even necessarily being distributed with binary distributions.

It should point at INSTALL, though.  And it's probably also the place
where we should explain the situation with PDFlib (or at least mention
it and refer to INSTALL for the details.


> Note that the new gnuplot web page does neither speak about gifs.
>
> ---
> PM
>
>
>

> 
> First, tune term.h to choose which terminal drivers you wish to enable.
> If you want to support gif output, you need to download, compile and
> install the gd library : see term/gif.trm for details.

> I don't think that's like that.

What e
> 
> Also, README.1ST speaks only about GIFs. What about deleting this file and
> reference from README to FAQ?
> 
> Note that the new gnuplot web page does neither speak about gifs.
> 
> ---
> PM
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

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

Re: TODO

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

On Thu, 8 Apr 2004, Petr Mikulik wrote:

> BTW, the text written into ChangeLog is getting narrower and narrower. 

It's not getting "narrower and narrower; just narrower, i.e. it
only gets narrowed ones, not repeatedly.  

> It was 80 chars wide, but now people started to wrap it at 73 (?) chars.

Those "people" are actually me.  I do occasionally reformat ChangeLog
comment lines that are very long, by using (X)Emacs' M-q on them.

> Why? I propose to use full 80 chars width.

Why not?  That doesnt' make them any easier to read.

Generally, I'd be a lot happier if people could stick to GNU ChangeLog
style more strictly.  It's really helpful to be able to just grep the
Changelog for a function name and find (almost) all entries affecting it.

I think we should postpone this discussion until after the release.  We
should probably cycle the ChangeLog then (--> move the current one to
ChangeLog.1), which will be good point to discuss how to write entries in
the fresh one.

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

Re: partly ignored TextSize in wgnuplot.ini

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

On Thu, 8 Apr 2004, Ethan Merritt wrote:

> - Rotated text doesn't rotate to angles other than 90 degrees.
> Was general text rotation never added to the windows code?

Nope.

> - In 'fillstyle.dem' some of the box borders seem to be drawn
> 1 pixel off from the box interior fill. 

That could be caused by Windows' slightly strange idea of how
coordinates are interpreted.  If I find a fix quickly, I'll put it
in before the release, otherwise it says as-is.

> - (I will now display my great ignorance of the Windows world :-)
> I see that this windows build does not support enhanced text mode,
> yet I know that Petr has said it works under os2.  Is the os2
> environment so different  from windows that the same driver
> code cannot support both?

Any actual similarities between OS/2 and Windows had better be seen as
mere coincidence.  These OSes both were originally written in the same
place, right, but that doesn't mean their gnuplot drivers have any
particular relation to each other.  The Windows driver is a couple of
years older, and there are some corners where that *still* shows.

> Petr Mikulik wrote:
> > The only thing not available is "Save current settings to wgnuplot.ini" and
> > similar menu option which are located under the current window menu (of the
> > window manager), which obviously X11 does not allow.
> 
> For me that menu works fine so long as I first say "unset mouse".
> Well, some fonts work and some don't, but I suspect that is a wine problem.

To clarify this, there are *two * places this menu show up: as the
right-click (a.k.a. "context") menu of the graph window, and as a special
extension of the "system button" (in the top left corner of the GUI
window).  With mouse mode active, you can only access the latter --- but
most users won't find it there.  Yes, this is a violation of pretty much
every user interface tradition for MS Windows ever invented, but it works,
and it conserves screen real-estate by not using a menu-bar.

Most of the above is caused mainly by the fact that gnuplot hasn't had an
active maintainer of the MS Windows version for ages.  I reluctantly
stepped in a while ago to keep it working (and keep Petr off my back when
he wanted something *really* badly...), but that's about it.

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

Re: TODO

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

On Thursday 08 April 2004 09:46 am, Petr Mikulik wrote:
> Please have a look to that file...

BUGS - maybe just refer people to the bug-tracker on 
SourceForge.

I think all those docs/old/README.* files can be deleted.

The windows bugs/todo items I suppose should stay on the
TODO list.

The xlib project seems to be dead, so far as I can tell.
We don't need to mention it.

Per is taking care of aquaterm documentation, I hope anyway.

Unifying the point styles should remain on the TODO list.
Line types have been unified as much as practical already,
so far as I know.

The mention of an INF bug for binary files- I'm not sure.
I can't find any record of such a bug on the SourceForge bug list.

A linux rpm - hmm.  I think the distros will probably do that to
suit themselves.  If necessary I can make a Mandrake rpm.
that might or might not work under other rpm-based distros.

The long list at the end - I've a long list of my own as well,
but these have little to do with the Version 4 release.


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

Re: Ready for wrap-up everyone?

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

> *) File README.1st:
>
> This text is to be deleted?
>
>  Note 3
>  ------
>  some files from Bruce Ravel's gnuplot-mode distribution have
>    not been included here, namely
>
>    o INSTALL              (covered by gnuplot install instructions)
>    o Win9x/INSTALL.Win9x
>    o Win9x/pgnuplot.c     (already in src/win)
>    o gnuplot.info         (can be created from docs/gnuplot.texi)
>    o gpelcard.ps          (can be created from lisp/gpelcard.tex)
>    o install-sh, mkinstalldirs  (provided by gnuplot)


I don't understand what this text tries to say nowadays. Therefore I propose
to delete it.



And what about this text:

First, tune term.h to choose which terminal drivers you wish to enable.
If you want to support gif output, you need to download, compile and
install the gd library : see term/gif.trm for details.


I don't think that's like that.

Also, README.1ST speaks only about GIFs. What about deleting this file and
reference from README to FAQ?

Note that the new gnuplot web page does neither speak about gifs.

---
PM

Re: Ready for wrap-up everyone?

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

Lars Hecking wrote:

>>*) Lars: contact Tom Williams (and whoever else you contacted last
>>   time) for the formal "blessing" according to the gnuplot Copyright
>>   statement.
>>    
>>
> 
> I thought I'd share this with all of you :)
>
>----- Forwarded message -----
>Lars,
>
>It has been a long time!  Good to know you're still helping out with
>Gnuplot.   It looks like the 4.0 features are great, I really like the
>website Petr put together.
>

And Ethan, a portion thereof.

Dan

TODO

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

Please have a look to that file...

BTW, the text written into ChangeLog is getting narrower and narrower. It
was 80 chars wide, but now people started to wrap it at 73 (?) chars. Why?
I propose to use full 80 chars width.

---
PM