gnuplot-beta

Re: Ready for wrap-up everyone?

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

On Mon, 5 Apr 2004, Lars Hecking wrote:

> > *) Lars: contact Tom Williams (and whoever else you contacted last
> >    time) for the formal "blessing" according to the gnuplot Copyright
> >    statement.
>  
>  In progress - do we have some form of "what's new in 4.0" that I can
>  attach?

You could attach the head of "NEWS", or point at the What's New page at
gnuplot.sf.net by Petr.

> > *) Lars also seems to be the only person who can reliably generate a
> >    working 'gnuplot.texi' (my boxes are all either too old or
> >    too new to run doc2texi.el).  
>  
>  Strange, I usually keep XEmacs around here quite up to date.

Well, my private SuSE box barfs for some missing elisp function, and my
RedHat box generates a .texi that differs from yours in subtle ways.
Actually, since I routinely build outside the source tree, the build of
gnuplot.texi fails completely anyway.  It fails to pick up the entire
terminal driver section, and up until recently, the corresponding rule in
docs/Makefile.in was completely crazy.

Here's an excerpt from the cvs diff -uwp between what I get on RedHat
(Using RH's emacs 21.2-2) and the version currently in CVS, cut to the
differences not explainable by recent changes to gnuplot.doc:

@@ -692,7 +692,7 @@ The Atari version of readline defines so
       Ctrl Home       - same as ^E.
       Esc             - same as ^U.
       Help            - @ref{help} plus return.
-      Ctrl Help       - `help `.
+      Ctrl Help       - @ref{help}.

 @end example

@@ -9723,6 +9724,7 @@ to you, depending on its output format.
 * kyo::
 * latex::
 * linux::
+* linux_::
 * macintosh::
 * mf::
 * mp::
@@ -9743,7 +9745,6 @@ to you, depending on its output format.
 * regis_::
 * rgip::
 * sun::
-* sun_::
 * svg::
 * tek410x::
 * tek410x_::
@@ -12081,7 +12082,24 @@ environment variable GSVGAMODE for the d
 1024x768x256 as default mode or, if that is not possible, 640x480x16
 (standard VGA)."

-@node macintosh, mf, linux, terminal
+@node linux_, macintosh, linux, terminal
+@subsubsection linux
+
+@c ?commands set terminal linux
+@c ?set terminal linux
+@c ?set term linux
+@c ?terminal linux
+@c ?term linux
+@cindex linux
+@tmindex linux
+
+
+The `linux` driver has no additional options to specify.  It looks at the
+environment variable GSVGAMODE for the default mode; if not set, it uses
+1024x768x256 as default mode or, if that is not possible, 640x480x16
+(standard VGA)."
+
+@node macintosh, mf, linux_, terminal

My copy of gnuplot.texi actually has *two* copies of the 'linux'
node, and I have no idea whatsoever where it might be picking that
up from.

@@ -13365,22 +13383,7 @@ puts six graphs on a page in three rows
 The `sun` terminal driver supports the SunView window system.  It has no
 options."

-@node sun_, svg, sun, terminal
-@subsubsection sun
-
-@c ?commands set terminal sun
-@c ?set terminal sun
-@c ?set term sun
-@c ?terminal sun
-@c ?term sun
-@cindex sun
-@tmindex sun
-
-
-The `sun` terminal driver supports the SunView window system.  It has no
-options."
-
-@node svg, tek410x, sun_, terminal
+@node svg, tek410x, sun, terminal

... It appears your build makes the same kind of error, just in a
different place.

>  gnuplot.texi should be up to date, too. I'm running a make to see if
> there are changes.

The important thing is that this has to be done immediately before the
final source tarball is made.  I've just run "make dist" for the release
candidate, but a little careful checking of the result would be in order
for the real thing.

> >    All ready by, let's say, Friday this week?
> 
>  You forgot that Easter is coming up. I will be out of the office
>  from Friday to Monday, inclusive.

Hmmm... so I guess that means we'll miss the proclaimed release target
date by a day or two, and release next week.  Not a big problem I presume.


-- 
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 Mon, 5 Apr 2004, Per Persson wrote:

> Sorry, no time to do that now (I'm not really sure of the proper way to 
> do it). Will have to wait until after the release.

Well, if anyone complains, we'll just blame you, then ;-)

> OTOH, nobody is expecting a binary for Mac OS X, I think.

They're not?  That's a surprise to me.  I was under the impression Apple
users were pretty much like those of Windows concerning wielding a
compiler to get some program installed --- they consider it a dangerous
thing only to be undertaken by experts.  What would be the purpose of the
"fink" project then?

For releases before 4.0, MacOS users didn't have binaries provided by the
gnuplot team itself, and that was quite a mess which I think we really
should try to avoid, if possible.  There were versions of gnuplot
specially adapted to macintosh, but those changes were lost because they
never were brought back into the mainline sources.


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

OS X binaries [Was: Ready for wrap-up everyone?]

[Per P. <per...@ma...>]

On Apr 6, 2004, at 13:15, Hans-Bernhard Broeker wrote:

> On Mon, 5 Apr 2004, Per Persson wrote:
>
>> Sorry, no time to do that now (I'm not really sure of the proper way 
>> to
>> do it). Will have to wait until after the release.
>
> Well, if anyone complains, we'll just blame you, then ;-)

No problem, I can handle that. ;-)

>
>> OTOH, nobody is expecting a binary for Mac OS X, I think.
>
> They're not?

With the emphasis on _expecting_, from the gnuplot team, and right from 
day one: No.
I bet they would _like_ a binary though.

> That's a surprise to me.

Well, you know our chief weapon is surprise...surprise and fear...fear 
and surprise.... Our two weapons are fear and surprise... [1]

>  I was under the impression Apple
> users were pretty much like those of Windows concerning wielding a
> compiler to get some program installed --- they consider it a dangerous
> thing only to be undertaken by experts.  What would be the purpose of 
> the
> "fink" project then?

You are pretty much right about this, although these days quite a few 
Mac users are from the Unix/Linux camp too.

>
> For releases before 4.0, MacOS users didn't have binaries provided by 
> the
> gnuplot team itself, and that was quite a mess which I think we really
> should try to avoid, if possible.

Yes, I agree.

> There were versions of gnuplot
> specially adapted to macintosh, but those changes were lost because 
> they
> never were brought back into the mainline sources.

I'd like to get this right and just throwing something together for 
friday or even next friday seems a bad idea. Just to get things 
started, I'll list the main options that comes to mind:


1) A static build of gnuplot.
	Standard double-clickable installer.
	Installs into /usr/local etc.
	Comes with a double clickable script[2] that can be freely moved 
around by the user.
	Static build may be trickier than it sounds, I don't know yet.	
2) A "normal" build of gnuplot.
	Standard double-clickable installer.
	Installs into /usr/local etc.
	Comes with a double clickable script[2] that can be freely moved 
around by the user.
	How do we solve deps?
	All the necessary libs in the installer?
	Better left for Fink, DarwinPorts etc.?

3) A "self contained" build of gnuplot.
	Drag'n drop install.
	All binaries and dependencies (libs) are wrapped up as a full 
application.
	The application can be freely moved around by the user.
	Hard to use with e.g. octave.

4) A full Gnuplot.app
	Drag'n drop install.
	All binaries and dependencies (libs) are wrapped up as a full 
application.
	Needs more code to fully behave like a "real" app, but not necessarily 
changes to the core code.
	Gnuplot.app can be freely moved around by the user.
	Hard to use with e.g. octave.

The last option (4) is what we had for 3.7, but that (carbonized) Mac 
gnuplot seem to have disappeared from the web.

For the "terminally-impaired", option (3) or (4) would be the most 
appropriate, as long as they don't need to interact with gnuplot from 
other programs.

To me, (2) is the preferred choice, but I suppose (1) is probably the 
least error-prone approach, should it work (I know it _sounds_ easy, 
but like I said, it could be tricky).

I'd appreciate feedback on this.

/Per




[1] http://www.ai.mit.edu/people/paulfitz/spanish/script.html

[2] To users, that script (proxy?) would in most respects act like a 
true application.

Re: Ready for wrap-up everyone?

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

On Mon, 5 Apr 2004, Lars Hecking wrote:


> > *) README (several of them) vs README.html:
> > I remember someone has contributed html-ized version of README, where is
> > its end nowadays?
>  
>  I am strictly against replaing plain-text READMEs with html versions.

I'm with Lars on that.  And unless there's a tool in place that generates
both files from a *single* source, having both README and README.html
would be a maintenance problem we don't need.

> > Anyway, should the FAQ file be in gnuplot sources anyway? Maybe it
> > could be removed from there.
>  
>  I think it's good style to include it, but I'm not feeling strongly
> about it.

Having the FAQ in the sources, while not itself a necessity, makes it
easier to ensure that the FAQ goes into all *binary* packages, whether
prepared by ourselves or by others (Linux distributors, in particular).

So I say we should keep it.

> > A note about Atari, Lars can remove that?
>  
>  Should probably go. Entry 8 should probably move to the FAQ.

[Note: the Entry numbers were so riddled with holes in the sequence
that I got rid of them....]

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

Re: Ready for wrap-up everyone?

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

> > > A note about Atari, Lars can remove that?
> >
> >  Should probably go. Entry 8 should probably move to the FAQ.
>
> [Note: the Entry numbers were so riddled with holes in the sequence
> that I got rid of them....]

Caused by me few hours before your major clean-up -- I had guessed you do
so.

---
PM

Re: Ready for wrap-up everyone?

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

On Mon, 5 Apr 2004, Ethan Merritt wrote:

> On Monday 05 April 2004 12:02 pm, Petr Mikulik wrote:
> >
> > > *) Distribute work on binary packages for PCs.
> > >
> > >    One important note: I don't think we can provide binaries with
> > >    the pdf driver compiled in.  It's "non-commercial use only".
> 
> I'm not so sure.  I think we are OK to include it ourselves since
> gnuplot source code is available, and since gnuplot itself is not
> a commercial product.   A problem could arise, however, if 3rd
> parties used a gnuplot binary for commercial development.

Well, as I understand the "PDFlib Lite" license, it says it's free for
*developers* of open-source applications, but not free for *use* by
commercial *users* of such programs.

> The only way to be certain is to ask them:
> 
> 	License inquiries: sa...@pd...

OK, I'll do that.

-- 
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 Tue, 6 Apr 2004, Petr Mikulik wrote:

> Is the information in README and INSTALL still up-to-date? 

There's a pending change to INSTALL that would summarize versions and
download URLs for all the optional support libraries.  A user complained
(rightfully, IMHO), that "hiding" that information in the various *.trm
files is not a particularly good plan, at least not for a release version.

> Should gnuplot.sf.net / Files be mentioned too?

The sf.net site definitely has to be mentioned.  Both the new homepage
there, and esp. the project page with all the bug trackers and friends. 

I guess it would also make sense to declare SF.net our primary download
site.  They have significantly larger pipes than any of the alternatives.

> I think that for OS/2 and Windows distributions, there will be FAQ.html.
> Web browser is always on these platforms.

A text file browser is, too.  So what?

What about a compromise: keep FAQ.html on the web only (and in the
separate "docs in all formats" tarball), and add a pointer to its URL to
the plain-text edition of the FAQ.

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

Re: Ready for wrap-up everyone?

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

> > Is the information in README and INSTALL still up-to-date?
>
> There's a pending change to INSTALL that would summarize versions and
> download URLs for all the optional support libraries.  A user complained
> (rightfully, IMHO), that "hiding" that information in the various *.trm
> files is not a particularly good plan, at least not for a release version.

Yes, and these INSTALL* look a bit unorganized, that's why my inclination
towards html. Anyway, INSTALL should probably have a table of contents.

> > Should gnuplot.sf.net / Files be mentioned too?
>
> I guess it would also make sense to declare SF.net our primary download
> site.  They have significantly larger pipes than any of the alternatives.

I agree. All others can be "secondary" -- but still keep them, as they
contain all previous gnuplot releases.



> > I think that for OS/2 and Windows distributions, there will be FAQ.html.
> > Web browser is always on these platforms.
>
> A text file browser is, too.  So what?
>
> What about a compromise: keep FAQ.html on the web only (and in the
> separate "docs in all formats" tarball), and add a pointer to its URL to
> the plain-text edition of the FAQ.

FAQ are on web in all 3 (html, pdf, txt) formats.
Ok, for binary releases, we can put a copy of FAQ.txt and FAQ.html; that
will satisfy everybody.

***

Small problem: FAQ.txt is not nicely produced by "lynx -dump" as in
Makefile, at least by my "Lynx Version 2.8.4rel.1" -- there are some
spurious citations like [18] to table of links at the end of the text
document. Somebody knows how to remove that? Or how to use a "-dump" feature
by "links"?

***

Other thing: how will gnuplot homepage be maintained? Will it be a mirror
(automatic mirror by cron?) of gnuplot.sf.net, where more people have ssh
access to? That's better than redirect?

---
PM

Re: Ready for wrap-up everyone?

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

On Mon, 5 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)

Why would we want to remove that?  We might want to remove the line
about INSTALL (because that file *is* in gnuplot, actually), but the
others are potentially important information.  I say we keep them.

> *) INSTALL (several of them):
> Should be unified too.

No.  There are only three:

./INSTALL
./INSTALL.gnu
./lisp/INSTALL

INSTALL.gnu is a file provided by external sources, so it should be kept
separate.  If at all, we might want to remove lisp/INSTALL (from
gnuplot-mode).

-- 
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: 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: 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: Ready for wrap-up everyone?

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

> >  You forgot that Easter is coming up. I will be out of the office
> >  from Friday to Monday, inclusive.
>
> Hmmm... so I guess that means we'll miss the proclaimed release target
> date by a day or two, and release next week.  Not a big problem I presume.

Thus, the release can be this Thursday (sources frozen Wednesday), or next
Wednesday (sources closed on Tuesday). I don't mind.

Petr