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

Cleanup list of patches and bug reports on sf.net

[Harald H. <h.h...@tu...>]

I have seen some old patches on sf.net that may have to change the status.

For example, the patch #982765, "Patch for AI (Adobe Illustrator) term",
has been discussed here. Since the whole AI terminal is outdated and
postscript is understood by Adobe Illustrator, this patch could be
rejected and closed.

Or patch #743667, "Epslatex term merged w/ pslatex/pstex", is superseeded
by #1040192, "Merge post, epslatex, pslatex, pstex terminals", and could
also be closed.

And isn't the bug report #963176, "wish: only create docs for available
terminals", solved?

This could shorten the lists and maybe help the writers of the patches to
know if their idea is just ignored or rejected. If rejecting such a patch
a cause should be given.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: any chance of a gui in the future?

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

On Fri, 22 Oct 2004, Stephen Guerdon Smith wrote:

> I'd still like to ask: any chance of a gui in the future?

There's always a chance.  There are no plans for a GUI right now,
inside the project, and I'm not sure we should even try to integrate
any GUI.  For starters, it would be pretty much guaranteed to destroy
one of gnuplot's traditional strong point: maximum portability.

It's been a stated long-term goal for quite a long time now to make life
easier for others to create such a GUI, by splitting gnuplot into a
callable library and a command-line user interface to that library, but
this project keeps getting buried under lots of new features being
implemented...

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

Re: Buggy invocation of emacs during "make"

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

On Friday 22 October 2004 11:29 am, Hans-Bernhard Broeker wrote:
> 
> That would seem to be your failure: /usr/local/bin is (supposedly) just as 
> unwritable to ordinary users as /usr/local/share/emacs/... is.
> 
> > The long and short of it is that the Makefile created
> > in the .../docs 
> 
> It's actually "lisp", not "docs"...

right. sorry.
 
> > directory tries to execute this command:
> >    /bin/sh ./../mkinstalldirs /usr/local/share/emacs/site-lisp
> > during a normal "make".  It shouldn't do that.
> 
> It should only do that in the 'make install' rather than plain 'make',
> right.  But the above *is* the correct location, for a default
> configure-driven install (prefix defaulting to /usr/local, not /usr).
> And for an install where emacs is found to be present, this is supposed 
> to be done.

How do you figure?
Configure does test for emacs, and it finds emacs in /usr/bin/emacs.
  configure:4000: checking for emacs
  configure:4016: found /usr/bin/emacs
  configure:4026: result: emacs
So it makes little sense to then use /usr/local/...  instead.

Anyway that is a secondary point.  The major point is that it should
not be trying to write into either /usr/share or /usr/local/share during
a normal "make".  Any ideas how to change this?

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

Re: Qt Wrapper for gnuplot

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

Ian Reinhart Geiser wrote:

>Greetings,
>I have been working on a KDE interface to Octave, when I found that there
>was no nice KDE wrapper around gnuplot.  So I started one.
>

Hi Ian,

There is a lot of functionality in gnuplot, making a wrapper for a full 
implementation quite big.  Octave doesn't use all features, naturally, 
but one nice thing about Octave is the "graw" function that allows one 
to access "non-Octave" graphics and other terminals.  If you want a good 
idea of things you are not aware of, I suggest downloading the latest 
CVS version of gnuplot, compiling, then running 'all.dem' in the 'demo' 
subdirectory.

Dan Sebald



>I am mostly looking for people who are interested in helping me that are
>familiar with gnuplot.  I only really know how to do pretty simple things
>with it, but I did most of the dirty work already, so anyone with minor
>C++ knowledge, and a good gnuplot background would work.
>
>The following C++ code generates the graphic at
>http://www.geiseri.com/kdevelop/gnuplot.png
>
>	KGNUPlotWidget *wid = new KGNUPlotWidget();
>	LineStyle line(2);
>	line.setLineType( 4 );
>	line.setLineWidth( 1 );
>	line.setPointType( 6 );
>	line.setPointSize( 3 );
>
>	LineStyle border( 3 );
>	border.setLineType( 9 );
>	border.setLineWidth( 2 );
>
>	FillStyle fill;
>	fill.setType( FillStyle::pattern );
>	fill.setFillPattern( 2 );
>	fill.setBorderStyle( &border );
>
>	FunctionPlot *plot = new FunctionPlot( "sin(x)" );
>	plot->setTitle( "Test Plot of sin(x)" );
>	plot->setStartRange( -1 );
>	plot->setEndRange( 2 );
>	plot->setPlotStyle( PlotBase::linespoints );
>	plot->setLineStyle( &line );
>
>	wid->addLineStyle( &border );
>	wid->addLineStyle( &line );
>	wid->addFillStyle( &fill );
>
>	wid->show();
>	wid->resize(400,300);
>	wid->setXLabel("Test X Label");
>	wid->setYLabel("Test Y Label");
>	wid->setFormats(KGNUPlotWidget::X, "%g");
>	wid->setFormats(KGNUPlotWidget::Y, "%.2f");
>	wid->plot(plot);
>
>Currently line styles, arrows, and arrow styles are supported.  Fill is
>sort of supported, and plot for data or functions will work with most
>simple cases.  I think the big issues that remain are the ones I am not
>aware of ;)
>
>Currently there is a small dependency on KDE, but I have plans to remove
>it, and the remainder works on Win32 or Unix.
>
>So who wants to play?  I'm not on the list so please CC me.
>
>-ian reinhart geiser
>  
>

-- 

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

Re: Buggy invocation of emacs during "make"

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

On Thu, 21 Oct 2004, Ethan Merritt wrote:

> I have complained about this before. But each time I
> fix it, the fix is permanent for that machine so I forget about it
> until the next time.  Today I was trying to install on a machine
> for which I don't have root access, and I was majorly annoyed
> trying to work around this bug.

> Problem:
> The normal build process fails because it tries to write to
> a non-existant directory that seems to have something to
> do with emacs.  

Actually, as you show later, it's not just writing to there, it's also
trying to *create* the directory.  So the above grief is somewhat beside
the point.

> Installing emacs does not fix this problem, because
> (a) the directory is looked for in the wrong place, and

Not really.

> (b) a normal user does not have write-access to it

That would seem to be your failure: /usr/local/bin is (supposedly) just as 
unwritable to ordinary users as /usr/local/share/emacs/... is.

> The long and short of it is that the Makefile created
> in the .../docs 

It's actually "lisp", not "docs"...

> directory tries to execute this command:
>    /bin/sh ./../mkinstalldirs /usr/local/share/emacs/site-lisp
> during a normal "make".  It shouldn't do that.

It should only do that in the 'make install' rather than plain 'make',
right.  But the above *is* the correct location, for a default
configure-driven install (prefix defaulting to /usr/local, not /usr).
And for an install where emacs is found to be present, this is supposed 
to be done.


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

Re: Changes to stable branch?

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

On Friday 22 October 2004 12:24 am, Per Persson wrote:
> 
> I seems to me that the driver will have to duplicate the main event 
> loop and take over control while mousing is active.
> 
> I'm reluctant to have an opininon where I don't intend to put down 
> work, but wouldn't it be cleaner to have a single event loop and an 
> event queue where any input unit (keystrokes at the prompt, mouse 
> clicks etc.) put their events to be processed by the event loop in a 
> timely manner?

That is the way it works now for x11 and ggi, yes.
The driver provides a routine (*term)->waitforinput() that merges the
input stream from the keyboard and from the plot window[s].
Events pulled from this merged input stream are either handled by
the caller, e.g. interpret new command line, or by the mousing code, 
e.g. do_event() in mouse.c.

> By making events (i.e. their structure) device independent at the level 
> of the main loop/event queue the drivers would only have to translate 
> an event as it is recieved and could then forget about it.

Yep.  That's the idea, and the core code is already in place.
It's just that up until now not many of the drivers actually use it.
But it sounds to me that most of the work in adding mousing to
aquaterm would consist of (1) providing an AQUA_waitforinput()
routine, and (2) implementing the terminal-specific draw commands
for mouse-coordinate printout and rulers (optional).  The rest of
it, including hot-keys and zooming, should "just work".

> An any case, this is not something I have strong opinions about and in 
> case anyone feels like working on providing event support for the 
> aquaterm driver I'd gladly provide as much help as I can.

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

Re: Changes to stable branch?

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

Per Persson wrote:

>
> On Oct 22, 2004, at 00:07, Ethan Merritt wrote:
>
>> On Thursday 21 October 2004 03:22 pm, Daniel J Sebald wrote:
>>
>>>>
>>>> Actually, on 10.3 and any previous system with X11 installed it will
>>>> startup with terminal x11.
>>>> Somewhat better than 'unknown' ;-)
>>>
>>>
>>> Ah.  I'm starting to get the picture on how Aqua functions.  The
>>> suggested fixes all sound logical to me.
>>
>>
>> I hesitate a little to say this, but it seems to me that unless and
>> until aquaterm provides all the features of x11, it is better to
>> default to x11.
>
>
> No problem. We'll just let it be the default if x11 is not available. 


That sounds OK for 4.0 errata, but I'd suggest for 4.1 and CVS to make 
Aqua the default if Aqua is what is running.  That encourages its use 
and users give feedback about the terminal.

Dan

any chance of a gui in the future?

[Stephen G. S. <sg...@ya...>]

Too bad that jerk gave you one star on version
tracker, just for not having a GUI.
I don't think that's fair.

I'd still like to ask:
any chance of a gui in the future?

very best regards,
stephen
new orleans

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Changes to stable branch?

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

On Oct 22, 2004, at 00:07, Ethan Merritt wrote:

> On Thursday 21 October 2004 03:22 pm, Daniel J Sebald wrote:
>>>
>>> Actually, on 10.3 and any previous system with X11 installed it will
>>> startup with terminal x11.
>>> Somewhat better than 'unknown' ;-)
>>
>> Ah.  I'm starting to get the picture on how Aqua functions.  The
>> suggested fixes all sound logical to me.
>
> I hesitate a little to say this, but it seems to me that unless and
> until aquaterm provides all the features of x11, it is better to
> default to x11.

No problem. We'll just let it be the default if x11 is not available.

>
>
> If there is something in particular that users
> need from aquaterm, they can easily do a 'set term'.  But
> new users who are presented with aquaterm by default may
> not even realize that they are missing out on capabilities
> (Mousing!) they would have had under x11.
>
> Per has been doing a great job of developing the aquaterm
> option, but so far as I can tell it's still not quite up to the level
> of the other primary gnuplot interfaces.

As far as mousing is concerned, I had a quick look and hacked up 
aquaterm.trm to support passing events from aquaterm windows some time 
ago.
I never finished it because I couldn't figure out how aquaterm events 
and keyboard events (at the prompt, not in the plot window) were 
supposed to interact.

I seems to me that the driver will have to duplicate the main event 
loop and take over control while mousing is active.

I'm reluctant to have an opininon where I don't intend to put down 
work, but wouldn't it be cleaner to have a single event loop and an 
event queue where any input unit (keystrokes at the prompt, mouse 
clicks etc.) put their events to be processed by the event loop in a 
timely manner?
By making events (i.e. their structure) device independent at the level 
of the main loop/event queue the drivers would only have to translate 
an event as it is recieved and could then forget about it.

An any case, this is not something I have strong opinions about and in 
case anyone feels like working on providing event support for the 
aquaterm driver I'd gladly provide as much help as I can.

/Per

possible addition to 'gnuplot links' page

[Mark M. <mm...@ea...>]

Hello,

I am the author of Engauge Digitizer, which seeks to undo what gnuplot
does. This open source tool is at digitizer.sourceforge.net.

Engauge extracts the numbers from a graph or map, for use by a
spreadsheet or some other analysis tool. Although it may seem like the
audience would be extremely small, it has been used by 12,000 people in
the two years since its incarnation. Individual students and large
corporations are using it, with very encouraging results. You can click
on Reviews on the home page to find out more.

Perhaps Engauge would be a useful addition to your 'gnuplot links' page.

Sincerely,
Mark Mitchell
home.earthlink.net/~mmc1919

Buggy invocation of emacs during "make"

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

I have complained about this before. But each time I
fix it, the fix is permanent for that machine so I forget about it
until the next time.  Today I was trying to install on a machine
for which I don't have root access, and I was majorly annoyed
trying to work around this bug.

Problem:
The normal build process fails because it tries to write to
a non-existant directory that seems to have something to
do with emacs.  I don't use emacs; I don't want emacs;
and I don't want my gnuplot installations to fail just because
emacs isn't there.

Actually it's worse than that.
Installing emacs does not fix this problem, because
(a) the directory is looked for in the wrong place, and
(b) a normal user does not have write-access to it

The long and short of it is that the Makefile created
in the .../docs directory tries to execute this command:
   /bin/sh ./../mkinstalldirs /usr/local/share/emacs/site-lisp
during a normal "make".  It shouldn't do that.

I have:
	autoconf (GNU Autoconf) 2.59
	automake (GNU automake) 1.8.3
I also have
	GNU Emacs 21.3.2

emacs has a directory /usr/share/emacs/site-lisp
(*not* /usr/local/...) but it belongs to root

I append the output from "make check"

moraig [31] make check
Making check in config
make[1]: Entering directory `/home/merritt/cvs/gnuplot-cvs/config'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/config'
Making check in m4
make[1]: Entering directory `/home/merritt/cvs/gnuplot-cvs/m4'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/m4'
Making check in term
make[1]: Entering directory `/home/merritt/cvs/gnuplot-cvs/term'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/term'
Making check in src
make[1]: Entering directory `/home/merritt/cvs/gnuplot-cvs/src'
make[2]: Entering directory `/home/merritt/cvs/gnuplot-cvs/src'
make[2]: Nothing to be done for `check-am'.
make[2]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
Making check in docs
make[1]: Entering directory `/home/merritt/cvs/gnuplot-cvs/docs'
Building allterm.h
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src -I../term -I/usr/X11R6/include -I/usr/local /include -Wall -g -O2 -DALL_TERM_DOC -c ./checkdoc.c
gcc -Wall -g -O2 -L/usr/lib64 -L/usr/X11R6/lib64 -o checkdoc checkdoc.o termdoc.o -lm 
spaces-only line :2975
PASS: gnuplot.doc
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/docs'
Making check in lisp
make[1]: Entering directory `/home/merritt/cvs/gnuplot-cvs/lisp'
/bin/sh ./../mkinstalldirs /usr/local/share/emacs/site-lisp
mkdir -p -- /usr/local/share/emacs/site-lisp
mkdir: cannot create directory `/usr/local/share/emacs': Permission denied
make[1]: *** [install-els] Error 1
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/lisp'
make: *** [check-recursive] Error 1

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

Re: Terminal settings saved where they shouldn't

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

On Thursday 21 October 2004 02:58 pm, Harald Harders wrote:
> 
> It produces two identical, coloured, eps figures. I would prefer that a
> terminal starts with its default settings when it is chosen after another
> terminal type.

I would prefer that the current settings are kept.

> If I want to restore the old settings I can use 
> 'set term push' and 'set term pop' (BTW: gnuplot does not find these
> command in the help).

Do these actually work?
When I have tried to use them I get errors or misdirected output
or some random collection of terminal settings.  I thought they
were unmaintained remnants of some earlier system.

>   Another case is this:
> 
> set terminal postscript eps
> set terminal postscript color
> 
> This adds the setting 'color' to the already chosen terminal type. If this
> should be the case has been discussed here some years ago.
> 
> But, if a different terminal has been used in the meanwhile I think the
> old settings should not be preserved.

Isn't that rather confusing?  You don't necessarily *know* if another
terminal has been used in between, particularly if you are stringing
together scripts.  But even if you *do* know, I think it is better to 
preserve the settings as much as possible

Example:

bind "P" 'set term post color solid; set output "| lpr"; replot; set term x11'

Now I have a print key in X11.  But it's really annoying if using that 
print key changes what is next shown on the x11 plot window. 

For completeness I point out that

bind "p" 'set term push; set term post color solid; set output "| lpr"; replot; set term pop'

does not work.  It produces a corrupt output stream.
Adding in another 'set output' does not help.

Did this ever work? 


> What do you think about it? I offer to do the work if you also think this
> is useful.

I'd say first fix push/pop, including making sure they work
recursively.

If those actually worked then I'd have a more favorable reaction
to losing the current settings from a normal 'set term foo'. 


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

Re: Changes to stable branch?

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

On Thursday 21 October 2004 03:22 pm, Daniel J Sebald wrote:
> >
> > Actually, on 10.3 and any previous system with X11 installed it will 
> > startup with terminal x11.
> > Somewhat better than 'unknown' ;-) 
> 
> Ah.  I'm starting to get the picture on how Aqua functions.  The 
> suggested fixes all sound logical to me.

I hesitate a little to say this, but it seems to me that unless and
until aquaterm provides all the features of x11, it is better to
default to x11.    

If there is something in particular that users 
need from aquaterm, they can easily do a 'set term'.  But 
new users who are presented with aquaterm by default may
not even realize that they are missing out on capabilities
(Mousing!) they would have had under x11.

Per has been doing a great job of developing the aquaterm
option, but so far as I can tell it's still not quite up to the level
of the other primary gnuplot interfaces.



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

Terminal settings saved where they shouldn't

[Harald H. <h.h...@tu...>]

Today, I have noticed that sometimes terminal settings are saved where I
normally would not expect it. See this example:

set terminal postscript eps color
set output "1.eps"
plot sin(x)
set output
set terminal png
set output "2.png"
replot
set output
set terminal postscript eps
set output "3.eps"
plot sin(x)
set output

It produces two identical, coloured, eps figures. I would prefer that a
terminal starts with its default settings when it is chosen after another
terminal type. If I want to restore the old settings I can use
'set term push' and 'set term pop' (BTW: gnuplot does not find these
command in the help).
  Another case is this:

set terminal postscript eps
set terminal postscript color

This adds the setting 'color' to the already chosen terminal type. If this
should be the case has been discussed here some years ago.

But, if a different terminal has been used in the meanwhile I think the
old settings should not be preserved.

This behaviour can be realised by adding a new terminal function to the
term_api that is called whenever changing the terminal type from one to
another, for example term->set_defaults().
This routine should then be called in change_term() in term.c, for example
like this:


     /* Success: set terminal type now */

+    if (strcmp(term->name, t->name) != 0) {
+    /* maybe also   if (term == t) {   works here */
       term = t;
+      if (term->set_defaults())
+        term->set_defaults()
+    }
     term_initialised = FALSE;
     name = term->name;


For me, this is a difference to the variable term_initialised since this
is also set when something is changed within the same terminal.

The mentioned approach
- avoids to use global default variables, as it is done at the moment,
- can help to solve the problem mentioned at the beginning of this mail,
- eases shared code for different terminals, for example different default
  font sizes for postscript, epslatex, ps(la)tex. I have been run in large
  difficulties when trying to merge these terminals since they often need
  different default values.

Of course, this needs to change the terminal api, but I think it is worth
it because it provides a much clearer interface for the terminal's default
values. When appending the new terminal routine to the TERMENTRY, it is
not necessary to add this functionality to all terminals immediately.

What do you think about it? I offer to do the work if you also think this
is useful.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Changes to stable branch?

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

Per Persson wrote:

>
> On Oct 21, 2004, at 20:06, Hans-Bernhard Broeker wrote:
>
>> The aquaterm driver forgot to set up this default, so gnuplot would
>> startup with terminal 'unknown'.  That's silly.
>>
>
> Actually, on 10.3 and any previous system with X11 installed it will 
> startup with terminal x11.
> Somewhat better than 'unknown' ;-) 


Ah.  I'm starting to get the picture on how Aqua functions.  The 
suggested fixes all sound logical to me.

Dan

Re: [RFC] Distro script for Mac OS X

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

On Thu, 21 Oct 2004, Per Persson wrote:

> How about calling it MacOSX, just to be clear?

Agreed.
> 
> /Per
> 
> 
> 

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

Re: [RFC] Distro script for Mac OS X

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

On Oct 21, 2004, at 20:02, Hans-Bernhard Broeker wrote:

>>
>> I suppose the top dir rather than src/ is the appropriate location for
>> a directory with the files?
>> Any objections to naming that dir "MacOSXDistro"?
>
> Yes.  That name's much too long.  A more natural place IMHO would be to
> put a new MacOS directory below "config", where all other
> platform-specific build utilities are currently kept.

Ah, thanks. Stupid of me not to think of "config".

How about calling it MacOSX, just to be clear?

/Per

Re: Changes to stable branch?

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

On Oct 21, 2004, at 20:06, Hans-Bernhard Broeker wrote:

> The aquaterm driver forgot to set up this default, so gnuplot would
> startup with terminal 'unknown'.  That's silly.
>

Actually, on 10.3 and any previous system with X11 installed it will 
startup with terminal x11.
Somewhat better than 'unknown' ;-)

/Per

Re: Changes to stable branch?

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

On Oct 21, 2004, at 19:58, Hans-Bernhard Broeker wrote:

> The fact that this code hasn't been in CVS at the time of 4.0.0 release
> was clearly a bug by oversight, so this is a bug fix, and should go in.
>

OK, I'll fix that then.

/Per

Re: [RFC] Distro script for Mac OS X

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

On Oct 21, 2004, at 19:16, Ethan Merritt wrote:

>
> How stable is this standard installer?

Very. Apple delivers OS X with it.

I probably should have been more precise previously

* The installer (executable) is part of the OS

* The installer package (as the one I'm creating for gnuplot) is just a 
particular file hierarchy (referred to as a bundle) that appears as a 
single item to the user. It contains the files to install, any scripts 
that need to be run during the install process and a description of 
where to put stuff etc.

* The "distro script" I wrote simply[1] build and install gnuplot into 
a temporary destination, creates the PDF documentation files etc. It 
then uses a third party utility to create an installer package (i.e. 
not an executable). The reasons to choose a tool other than the one 
supplied by Apple are several, all good and valid. Finally, it wraps 
everything up as a "disk image", a compressed format suitable for 
distribution.

* In addition to the files neccessary to create the install package, I 
also added a ReadMe file and a copy of the license.

[1] It actually makes a small change to allow gnuplot to be built on 
10.3 and deployed on earlier systems (stpcpy wasn't standard prior to 
10.3)

>
> If no one maintains the OSX-specific files in your new directory,
> will we risk losing the benefit of your work because the installer
> files themselves no longer function under Tiger or its successor?

Only if Apple decides to break every installer in existance.

The only problems I can see with future releases of OS X would apply to 
_any_ form of binary distribution, where you build on Y and deploy on 
Z.

>
> I'm not objecting to including it, but I'd like a better feel of
> how much benefit it is to future work.

Hopefully, a lot.

/Per

Re: Plot size in postscript/epslatex/ps(la)tex terminals

[Harald H. <h.h...@tu...>]

On Thu, 21 Oct 2004, Hans-Bernhard Broeker wrote:

> On Wed, 20 Oct 2004, Harald Harders wrote:
>
> > On Tue, 19 Oct 2004, Ethan Merritt wrote:
> >
> > > My expectation for *.eps files is that they will by default be small enough
> > > to use as an inset figure within an normal page.  So I would not like this
> > > to change.
> >
> > Ah, it seems I have not been clear enough. I do not want to change the
> > size of the postscript terminal (neither in ps nor in eps mode). At the
> > moment, the epslatex and ps(la)tex terminals use different sizes than the
> > eps mode of the postscript terminal.
>
> Are you sure of that?  What are the sizes, actually?  I seem to remember
> them to be 5x3 inches for both pslatex and 'post eps'; not sure about
> epslatex though.

epslatex, pslatex, and pstex produce 5 x 3 inches (360 x 216 pt).
post eps produces 5 x 3.5 inches (360 x 252 pt).

And even if the bounding boxes of epslatex and ps(la)tex are equal, the
plot areas are different with the standard settings of the terminals.

Since for my eyes, the proportions of 'post eps' are better than these of
the postscript-tex combinations I prefer to switch to 5 x 3.5 inches for
all postscript derivatives.

BTW: Should'nt somebody delete the file #post.trm# from CVS? Seems that
someone has killed emacs without saving.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Changes to stable branch?

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

Hans-Bernhard Broeker wrote:

>On Thu, 21 Oct 2004, Daniel J Sebald wrote:
>
>  
>
>>I haven't been following, sorry.  How does this default work?  It seems 
>>to me that a "default terminal" is something that the user should be 
>>able to configure without having to recompile anything.  
>>    
>>
>
>That's not what this is about.  The default terminal driver is the
>mechanism that lets you just start gnuplot and 'plot x', without setting 
>any terminal driver first, and have the "obviously correct" thing happen:
>get a plot to X11 on Unix, to Windows GUI on MS Windows, to PM on OS/2, 
>etc.  The aquaterm driver forgot to set up this default, so gnuplot would
>startup with terminal 'unknown'.  That's silly.
>

I tried running gnuplot from outside of X an hour or so ago and saw the 
'unknown' so got the idea.  Yes, that should be fixed.

>>I know there is some reluctance to add default mechanisms to gnuplot.  
>>Is there some way already of automatically loading a file at startup?  
>>    
>>
>
>Of course there is.  "help startup" even tells you what it is ;-)
>

"startup"!  (Not "defaults".)  That's what I was looking for.  :)  Thanks.

Dan

Re: Changes to stable branch?

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

On Thu, 21 Oct 2004, Daniel J Sebald wrote:

> I haven't been following, sorry.  How does this default work?  It seems 
> to me that a "default terminal" is something that the user should be 
> able to configure without having to recompile anything.  

That's not what this is about.  The default terminal driver is the
mechanism that lets you just start gnuplot and 'plot x', without setting 
any terminal driver first, and have the "obviously correct" thing happen:
get a plot to X11 on Unix, to Windows GUI on MS Windows, to PM on OS/2, 
etc.  The aquaterm driver forgot to set up this default, so gnuplot would
startup with terminal 'unknown'.  That's silly.

> I know there is some reluctance to add default mechanisms to gnuplot.  
> Is there some way already of automatically loading a file at startup?  

Of course there is.  "help startup" even tells you what it is ;-)

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

Re: [RFC] Distro script for Mac OS X

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

On Thu, 21 Oct 2004, Per Persson wrote:

> Hi,
> I've cleaned up my distro script for Mac OS X and would like to add it 
> and it's supporting files to CVS.
> 
> I suppose the top dir rather than src/ is the appropriate location for 
> a directory with the files?
> Any objections to naming that dir "MacOSXDistro"?

Yes.  That name's much too long.  A more natural place IMHO would be to
put a new MacOS directory below "config", where all other
platform-specific build utilities are currently kept.

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

Re: Changes to stable branch?

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

On Thu, 21 Oct 2004, Per Persson wrote:

> I'm considering adding code to make aqua the default terminal to the 
> stable branch, as in CVS HEAD, but I'm not sure if that qualifies as a 
> *neccessary* change.

I would think it is reasonable to put the fix in there, on the basis of 
the resulting binary being effectively unusable as designed, without it.

The fact that this code hasn't been in CVS at the time of 4.0.0 release
was clearly a bug by oversight, so this is a bug fix, and should go in.

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