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

Re: minor bug regarding time/date graphs

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

On Wed, 7 Apr 2004, Hans-Bernhard Broeker wrote:

> Consider yourself somewhat lucky, then.  I don't think sequence ticks
> have ever worked well in gnuplot.  

Duh.  An important part of that statement didn't make it from brain to
keyboard: it's only sequence tics on *time/date* axes that are this shaky.

> The crucial variable is axis_array[].format_is_numeric.  It's set
> to FALSE in the case at hand, and that's wrong.  I'll look into this.

Did that, found and fixed it in the CVS sources.  The bug was in
set.c:looks_like_numeric().  That function was utterly broken completely
at least since the default format was changed from '%g' to '% g'.

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

Re: Ready for wrap-up everyone?

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

> *) 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.  Look forward to hearing about the official
release!

-thaw-
Thomas Williams
GenSys Software www.gensys.com  
----- End forwarded message -----

Re: minor bug regarding time/date graphs

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

On Wed, 7 Apr 2004, Pieter-Tjerk de Boer wrote:

> If one gives the following commands in gnuplot (version 3.8k.3):
>   set xdata time
>   set timefmt x "%d %b %Y"
>   set xtics border mirror norotate "01 Jan 1999",3.1557e+07
>   set xra ["01 Oct 1998":"01 May 2004"]
>   p x
> one gets a (trivial) graph, with labels on the horizontal axis
> starting at 01/01/1999.

Consider yourself somewhat lucky, then.  I don't think sequence ticks have
ever worked well in gnuplot.  This has improved considerably, but I
wouldn't bet the farm on that stuff anytime soon.

> However, after saving this and then loading the resulting file
> into a freshly started gnuplot, the date axis labels starts
> at 01/01/2000.

That's indeed caused by the 'timefmt' being written to the save file
too late in the list.  Rearranging save_all() will fix that.

> Furthermore, the labels are all simply 'g' rather than numerical
> dates.

Hmm... this version here gives me a '9' instead.

That's because you didn't have an explicit "set format x" in your script.
So gnuplot had to invent a time/date format string for the x axis.  Such
invented format strings aren't written back into the 'set format'
variables, so after the commands you gave, 'show format' will still show
the default '% g' for all axes.

> - gnuplot puts the "set format x ...." line after the "set xdata time"
>   line, which apparently overrides the label format (implicitly?) set
>   by the latter.

No, that override only happens at 'plot' time, but it's sensitive to
whether you just never gave a 'set format' for that axis at all (i.e. it's
still in the default state), or you explicitly requested a particular
format.  Loading a saved file will look like an explicit request, and thus
will be honoured.

Using a script-reduction tool like the one Petr put on the gnuplot.sf.net
web pages will solve this mystery, by removing the 'set format x "% g"'
lines from the saved scripts.

The crucial variable is axis_array[].format_is_numeric.  It's set
to FALSE in the case at hand, and that's wrong.  I'll look into this.


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

minor bug regarding time/date graphs

[Pieter-Tjerk de B. <ptd...@cs...>]

Hello,

I'm sorry to interrupt the 4.0 release preparations, but this minor bug
may be easy to fix in time for the release.

If one gives the following commands in gnuplot (version 3.8k.3):
  set xdata time
  set timefmt x "%d %b %Y"
  set xtics border mirror norotate "01 Jan 1999",3.1557e+07
  set xra ["01 Oct 1998":"01 May 2004"]
  p x
one gets a (trivial) graph, with labels on the horizontal axis
starting at 01/01/1999.
However, after saving this and then loading the resulting file
into a freshly started gnuplot, the date axis labels starts
at 01/01/2000.
Furthermore, the labels are all simply 'g' rather than numerical
dates.

The causes seem to be that, when saving:
- gnuplot puts the "set xtics ...." line before the "set timefmt ..."
  line, so when reading, it doesn't yet know how to interpret the
  date appearing in the "set xtics ...." line.
- gnuplot puts the "set format x ...." line after the "set xdata time"
  line, which apparently overrides the label format (implicitly?) set
  by the latter.

Changing the order in which the lines are saved presumably would solve
this bug, but I don't know whether that could introduce any new problems.

Best regards,
  Pieter-Tjerk

partly ignored TextSize in wgnuplot.ini

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

A user of wgnuplot.exe is reporting that the width specified as
	TextSize=648 576
item in wgnuplot.ini is ignored for large values of width (the first
number). He cannot get window width larger than sth like 808 pixels.
He is using font FixedSys, and then only 69 out of 80 characters can be
placed on the command line for that width. He claims this as bug (of
course).

I tried to reproduce this (btw, wgnuplot.exe runs also under wine in linux),
and really, for some larger values of TextSize width, the number is ignored,
and it somehow depends on font ... someone knows what's going wrong?
---
PM

Re: gnuplot with libgd for Windows?

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

On Tue, 6 Apr 2004, Ethan Merritt wrote:

> On Tuesday 06 April 2004 10:24 am, you wrote:

> > So it seems we could withdraw to a position stated in INSTALL that says:
> >
> > gnuplot+Windows+(current GD built as DLL)+(no libfreetype) == NO GO
> 
> But even if freetype is present, we would still need conditional code in
> gd.trm so that it doesn't generate unresolved symbol errors at build time,
> right?

Right.  Oversight on my end.

> Is it easy to build libgd as static under windows?  

I say we leave that to Petr, since he's going to be doing the Windows
builds, and he said he's been using static libs all the time and it works.


-- 
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: gnuplot with libgd for Windows?

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

> Is it easy to build libgd as static under windows?

All my OS/2 and MS Windows (Mingw, Cygwin) builds are with static libraries.
No problems.

---
PM

Re: gnuplot with libgd for Windows?

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

On Tuesday 06 April 2004 10:24 am, you wrote:
> On Tue, 6 Apr 2004, Ethan Merritt wrote:
> > These minimal built-in fonts are provided as fall-backs in the case
> > that better ones are not provided by the operating environment.
>
> You need more than just the fonts --- you still need the freetype
> library to access them, too, I think.

Yes, that's probably true.

> So it seems we could withdraw to a position stated in INSTALL that says:
>
> gnuplot+Windows+(current GD built as DLL)+(no libfreetype) == NO GO

But even if freetype is present, we would still need conditional code in
gd.trm so that it doesn't generate unresolved symbol errors at build time,
right?
And also to make sure the default font was set to something reasonable.

> AFAICS, this problem will not happen as soon as one of these conditions
> is removed.  Having libfreetype around or just using a statically
> compiled GD would probably be the easiest alternatives.

Is it easy to build libgd as static under windows?  If that's a way out of the
bind let's do that.  INSTALL can simply say (leaving open the possibility
that dlls will work again in the future):  "If you get unresolved symbol errors
for the fonts, please link against a static libgd library instead of the dll".
Or whatever the proper wording is for windows linkage.


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

Re: gnuplot with libgd for Windows?

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

On Tue, 6 Apr 2004, Ethan Merritt wrote:

> These minimal built-in fonts are provided as fall-backs in the case
> that better ones are not provided by the operating environment.

You need more than just the fonts --- you still need the freetype
library to access them, too, I think.

So it seems we could withdraw to a position stated in INSTALL that says:

gnuplot+Windows+(current GD built as DLL)+(no libfreetype) == NO GO

AFAICS, this problem will not happen as soon as one of these conditions
is removed.  Having libfreetype around or just using a statically compiled
GD would probably be the easiest alternatives.

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

Re: gnuplot with libgd for Windows?

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

Discussion transferred from usenet:
--------------------------------------------------------

Newsgroups: comp.graphics.apps.gnuplot
Subject: Re: gnuplot with libgd for Windows?
Summary:
Expires:
References: <e13...@po...> <e13...@po...> <ad6...@po...> <c4ufmb$gi3$1...@ne...>
Sender:
Followup-To:
Distribution:
Organization:
Keywords:
Cc:

In article <c4ufmb$gi3$1...@ne...>,
Hans-Bernhard Broeker  <br...@ph...> wrote:
>
>I've finally budged and got me a copy of that GD DLL onto a Windows
>machine to look at it myself.  Turns out my initial suspicition was
>mostly right --- the global symbols for those fonts aren't being
>exported by the DLL, so they're not present in the import lib.
>
>Looks like we will have to use those getter functions, after all, *if*
>they're available.  And the static initializers will probably have to
>go, too ;-(

These minimal built-in fonts are provided as fall-backs in the case
that better ones are not provided by the operating environment.
Are there any Windows systems for which TrueType fonts would
not be available?  Maybe the fix is as simple as removing these
fall-back cases under Windows.

>Dammit --- why, oh why is it that this kind of fatal blow *always* has
>to occur so short before a planned release date?

One other thought - is it possible to build a tiny extra dll on
the side that exports the required symbols, even if this extra
dll is an ugly hack?  It could use the getter functions and then
turn around and export the pointers as expected by external apps.
That would allow the gnuplot source to stay in its current state for
a version 4 release, while still providing a working Windows binary.

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

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

[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?

[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

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

[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 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?

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

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?

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

> > Where do the released files go?
> > - sourceforge
> > - darthmouth??
> > - CTAN
>
>  I think all major sites (mirror.ac.uk, CTAN) are mirroring from UCC.

Is the information in README and INSTALL still up-to-date? Should
gnuplot.sf.net / Files be mentioned too?

> > *) FAQ vs FAQ.html:
> > I would prefer to enclose FAQ.html instead of the plain text FAQ.
>
>  Dto.

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

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

already cleaned-up

---
PM

Re: Ready for wrap-up everyone?

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

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.
I will not venture an opinion on 3rd party use of a gnuplot for
commercial non-development work.

The only way to be certain is to ask them:

	License inquiries: sa...@pd...


Here are is the license description from the readme of pdflib
version 4.0.3

Licensing and Copyright
=======================
THIS IS NOT PUBLIC DOMAIN OR FREEWARE SOFTWARE!

PDFlib is available under two different licensing terms which are
substantially different, and meet the needs of different developer groups.
Please take the time to read the short summaries below in order to decide
which one applies to your development.


The Aladdin Free Public License
-------------------------------
This license applies to the main PDFlib package, but not to the
ActiveX, .NET, and EBCDIC editions or any of our precompiled
binary versions (all of these are only
available under the terms of the commercial PDFlib license). The
complete text of the license agreement can be found in the
file aladdin-license.pdf. In short and non-legal terms:

- You may develop free software with PDFlib, provided you make your source
  code available.
- You may develop software for your own use with PDFlib, as long as you
  don't sell it.
- You may redistribute PDFlib non-commercially.
- You may redistribute PDFlib on digital media if the complete contents of
  the media are freely redistributable.
  
Only the text in the file doc/aladdin-license.pdf is considered to completely
describe the licensing conditions. Project managers please note: Using PDFlib
in your commercial projects is not covered by the Aladdin license, and
effectively means jeopardizing your project through unlicensed software!

License inquiries: sa...@pd...

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

Re: Ready for wrap-up everyone?

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

> Where do the released files go?
> - sourceforge
> - darthmouth??
> - CTAN
 
 I think all major sites (mirror.ac.uk, CTAN) are mirroring from UCC.

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

> *) FAQ vs FAQ.html:
> I would prefer to enclose FAQ.html instead of the plain text FAQ.

 Dto.

> I will please majority of users I guess.
> 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.

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

Re: Ready for wrap-up everyone?

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

> *) HB or Lars make a source tarball.
>
>    Circulate that in private (Lars' ftp server?  Or the project home
>    directory at sf.net?) to check for last-minute glitches.

Where do the released files go?
- sourceforge
- darthmouth??
- CTAN

> *) 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".

If someone proofs this, then binaries will be without this feature.

>    I would volunteer building the 32-bit DOS version (DJGPP).
>    Cygwin by Petr (both Unix gnuplot/X11 and Win32 wgnuplot/pgnuplot,
>                    in a single or two separate packages)?

I can organize the following:

1. OS/2 binary.

2. Mingw binary -- probably with two executables: one normal, the other with
PIPES defined for more unixish users

3. Cygwin+X11 by ./configure; make

>    'docs tarball' by Lars?

A prerelease of 1. and 2. is at www.sci.muni.cz/~mikulik/gnuplot/
I think FAQ should be replaced by FAQ.html
Any other thing proposed to be there?

>    All ready by, let's say, Friday this week?

Yes, till Friday.


Other comments:


*) 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)


*) README (several of them) vs README.html:
I remember someone has contributed html-ized version of README, where is
its end nowadays?

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

*) FAQ vs FAQ.html:
I would prefer to enclose FAQ.html instead of the plain text FAQ.
I will please majority of users I guess.
Anyway, should the FAQ file be in gnuplot sources anyway? Maybe it could be
removed from there.


*) BUGS:
A note about Atari, Lars can remove that?


---
PM

Re: Ready for wrap-up everyone?

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

> 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 don't get that here either, and I never ever build as root.