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

global pt

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

Hello,

is it possible to set a global point type, e.g. pt 7 for all plots
w/o specifying it on the plot command line?

-- 
Johannes

gnuplot, mac, python

[BBands <bb...@ya...>]

Would a developer with gnuplot and python installed on
a mac please respond off list?

Thanks,

    jab

John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.

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

Re: Bug report and whishlist

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

> > > I guess we should only do that if the term type actually changes (rather
> > > than if just the options change).
>
> > Ethan Merritt <merritt@u.washington.edu> wrote:
> > >What would happen in the case of "set term push" and "set term pop"?
>
> On Wednesday 11 May 2005 08:31 am, Petr Mikulik wrote:
> > "push" remembers current terminal's name and options, and "pop" executes
> > "set term <oldterm> <oldopts>" as you would type it on command line.
>
> I meant, does "set term push" count as changing the terminal type for the
> purposes of Robert's proposed test?

If it works for "set term blabla" from command line or script, then it will
work for "set term pop" as well.

---
PM

Povray terminal driver

[V. <gae...@en...>]

  http://www.eleves.ens.fr/home/varoquau/gnuplot/

  Here is the first draft of the povray terminal driver. It is fully 2D,
wright now. A lot of work remains to be done but I am going away for two
weeks; Among the big piece of work to do is the font handling and
enhanced text bit. I have added RGb color support a few days ago have
have ever since lost color.

  On the web page, there are also demo examples that have both the
povray terminal driver and the png one, for comparision. My "pov-webifye
is probably bugged, and that explaines the must bizarres bugs.

  Have a look at it, enjoy, tell me how to improve it or finish it... I
continue working on it only in two weeks times.

--
  Ga=EBl

PS it is currently quite late in France and I am falling asleep in front
of my computer, so please excuse this very poorly written post.

Re: Bug report and whishlist

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

> Robert Hart <en...@no...> wrote:
> > I guess we should only do that if the term type actually changes (rather
> > than if just the options change).

> Ethan Merritt <merritt@u.washington.edu> wrote:
> >What would happen in the case of "set term push" and "set term pop"?

On Wednesday 11 May 2005 08:31 am, Petr Mikulik wrote:
> "push" remembers current terminal's name and options, and "pop" executes
> "set term <oldterm> <oldopts>" as you would type it on command line.

I meant, does "set term push" count as changing the terminal type for the
purposes of Robert's proposed test?

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

Re: Compile error on Mac OS X

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

Brendan Burns wrote:
> In file included from term.h:400,
>                  from term.c:1205:
> ../term/pslatex.trm:120: error: static declaration of  'epslatex_header' 
> follows non-static declaration
> ../term/post.h:88: error: previous declaration of 'epslatex_header'  was 
> here

That's strange --- this is usually just a warning, not an error.  Did 
GCC change its behaviour on this?

> Changing
> "static char *epslatex_header..." -> "char *epslatex_header..." in  
> pslatex.trm fixed the compile error.  

It's quite probably the wrong direction of change, though.  Making the 
declaration in post.h 'static' makes more sense.  Actually, it should 
probably be TERM_PUBLIC, which evaluates to static.

Re: Bug report and whishlist

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

On Wednesday 11 May 2005 11:11 am, dan...@ie... wrote:
> 
> Since this discussion is going on, I thought I'd toss in something I sent
> to the list previously, which is the capability to append plots to an
> existing file.  Would that be difficult?  The "set output" etc. enables
> putting several plots in one file, but not openning an existing file and
> then adding.

For those few terminal types for which this makes any sense at all
(output streams to an HP printer?), you can already do this:

set output "| cat >> oldfile.dat"


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

Re: Bug report and whishlist

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

dan...@ie... wrote:

> Since this discussion is going on, I thought I'd toss in something I sent
> to the list previously, which is the capability to append plots to an
> existing file.  Would that be difficult?  

Yes, very.  It'd mean that gnuplot would need (possibly restricted) 
reading&parsing capabilities for all the file formats it currently only 
outputs.   Generally, a parser is about one order of magnitude harder to 
get fully correct than a writer for the same format.

Re: Bug report and whishlist

[<dan...@ie...>]

> On Wed, 2005-05-11 at 13:44 +0200, Petr Mikulik wrote:
>
>> Is there any non-screen terminal that has no output file? I wonder
>> whether
>> it makes sense to add flag TERM_SCREEN.
>
> Would it make more sense to add an implicit "set output" before a set
> term?
>
> The current "set output" documentation states it is safer to set term
> before set output, so it shouldn't break anything.
>
> I guess we should only do that if the term type actually changes (rathe=
r
> than if just the options change).

Since this discussion is going on, I thought I'd toss in something I sent
to the list previously, which is the capability to append plots to an
existing file.  Would that be difficult?  The "set output" etc. enables
putting several plots in one file, but not openning an existing file and
then adding.  Perhaps this would be too difficult because there might be =
a
"footer" at the end of the existing file that would need to be removed.

Dan

color sequence in fig

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

The fig terminal currently does not respect the color sequence of the
postscript terminal, unified to many other terminals. I'm about to fix this.
Are there any complains?

---
PM

Re: Bug report and whishlist

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

> Hmm.  That comes closer.  I don't know if that test is sufficient or not.
> What would happen in the case of "set term push" and "set term pop"?
> [I've never gotten those to work as I expect anyhow, so maybe it would
> be a small loss].

"push" remembers current terminal's name and options, and "pop" executes
"set term <oldterm> <oldopts>" as you would type it on command line.

---
PM

Re: Bug report and whishlist

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

On Wednesday 11 May 2005 06:13 am, Robert Hart wrote:
> On Wed, 2005-05-11 at 13:44 +0200, Petr Mikulik wrote:
> 
> > Is there any non-screen terminal that has no output file? I wonder whether
> > it makes sense to add flag TERM_SCREEN.
> 
> Would it make more sense to add an implicit "set output" before a set
> term?

That would break some existing uses.
For example, if you want to continue writing to an output pipe but
change a characteristic such as the default font:

  set output '| display png:-'
  set term png font "verdana"
  plot <something>
  set term png font "Times" 20
  plot <something_else>


We are moving towards an alternative command that would let you 
do this without calling 'set term'
  set term png font "verdana"
  plot <something>
  set termoptions font "Times" 20
  plot <something_else>

But so far this only works for a small number of terminal options.

> I guess we should only do that if the term type actually changes (rather
> than if just the options change).

Hmm.  That comes closer.  I don't know if that test is sufficient or not.
What would happen in the case of "set term push" and "set term pop"?
[I've never gotten those to work as I expect anyhow, so maybe it would
be a small loss].

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

Re: Bug report and whishlist

[Robert H. <en...@no...>]

On Wed, 2005-05-11 at 13:44 +0200, Petr Mikulik wrote:

> Is there any non-screen terminal that has no output file? I wonder whether
> it makes sense to add flag TERM_SCREEN.

Would it make more sense to add an implicit "set output" before a set
term?

The current "set output" documentation states it is safer to set term
before set output, so it shouldn't break anything.

I guess we should only do that if the term type actually changes (rather
than if just the options change).

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Bug report and whishlist

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

> > This is a rather non natural behavior that must trick a quite a few
> > users.
>
> It does seem to be a recurring complaint.
> Can anyone see bad side effects if we were to
>
> 1) Give win and x11 an explicit term->flags TERM_NO_OUTFILE
>    (aquaterm? vgagl? others?)
>

pm.trm

>
> 2) Modify term_init() to check for TERM_NO_OUTFILEE, and if present
>    then *close* the output file rather than re-opening it; i.e.
>    call term_close_output() rather than term_set_output().

I would like this.

Is there any non-screen terminal that has no output file? I wonder whether
it makes sense to add flag TERM_SCREEN.

---
PM

Re: Linux Gazette article on python + gnuplot

[<dan...@ie...>]

> Linux Gazette has an article on using python + gnuplot and other tools
>
>    http://linuxgazette.net/114/andreasen.html

Cool!  :-)

Linux Gazette article on python + gnuplot

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

Linux Gazette has an article on using python + gnuplot and other tools

   http://linuxgazette.net/114/andreasen.html


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

Re: Bug report and whishlist

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

On Tuesday 10 May 2005 11:51 am, Ga=EBl Varoquaux wrote:
> > It's a little bit trickier than I made it sound. For instance, you can
> > save the output from the x11 terminal driver to a file so that you can
> > play it back later (like a recording of the session).
>=20
>    I thought it was a different terminal (xlib) !


Yes, it is xlib.  But the two drivers are no longer separate;
the xlib and x11 drivers share almost all driver routines.
I did not mean to imply that x11/xlib would cause a problem.
On the contrary, I meant that I understand how x11/xlib works and so I
can be careful to test any possible bad effects of the proposed change.
But I am not equivalently familiar with the windows driver, and cannot
test it myself to explore possible side-effects.



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

Re: Bug report and whishlist

[V. <gae...@en...>]

> It's a little bit trickier than I made it sound. For instance, you can
> save the output from the x11 terminal driver to a file so that you can
> play it back later (like a recording of the session).

   I thought it was a different terminal (xlib) !

   A simple work around is to reset the output after changing to x11
terminal :

set term x11
set output x11_dump
replot

--
  Ga=EBl
=20
PS : I sent you my last email privately, but realizing my mistake I
resent it to the list.

Re: Bug report and whishlist

[V. <gae...@en...>]

> Can anyone see bad side effects if we were to

> 1) Give win and x11 an explicit term->flags TERM_NO_OUTFILE
>    (aquaterm? vgagl? others?)=20

> 2) Modify term_init() to check for TERM_NO_OUTFILEE, and if present
>    then *close* the output file rather than re-opening it; i.e.
>    call term_close_output() rather than term_set_output().

  I strongly favor such a solution : I have found that a lot of people
avoid gnuplot because they are faced with such problems they do not
understand. Lets make there life easy.

--
  Ga=EBl

Re: Bug report and whishlist

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

> set term post
> set output 'result.ps'
> plot 'foo'
> set term win
> plot 'baz' using 1:2
> (then result.ps becomes blank
 
> This is a rather non natural behavior that must trick a quite a few
> users.

It does seem to be a recurring complaint.
Can anyone see bad side effects if we were to

1) Give win and x11 an explicit term->flags TERM_NO_OUTFILE
   (aquaterm? vgagl? others?) 

2) Modify term_init() to check for TERM_NO_OUTFILEE, and if present
   then *close* the output file rather than re-opening it; i.e.
   call term_close_output() rather than term_set_output().


The following proof-of-principle test works for x11, but I don't
know what wrinkles may exist in doing the same for win.trm


--- gnuplot/src/term.c  2005-04-28 14:34:35.000000000 -0700
+++ gnuplot-cvs/src/term.c      2005-05-10 11:16:04.378445568 -0700
@@ -483,6 +483,10 @@
      * resulted in output files being truncated
      */
 
+    /* If this is an interactive terminal, close previous output file */
+    if (outstr && !strncmp(term->name,"x11",3))
+       term_close_output();
+
     if (outstr &&
        (((term->flags & TERM_BINARY) && !opened_binary) ||
         ((!(term->flags & TERM_BINARY) && opened_binary)))) {



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

Compile error on Mac OS X

[Brendan B. <bb...@cs...>]

Hello,
I just tried to compile the latest CVS on Mac OS X (10.4, gcc 4.0)  
and it failed with the error:

gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/ 
local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.1\" - 
DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/ 
local/share/gnuplot/4.1/gnuplot.gih\"   -g -O2 -ObjC -c `test -f  
'term.c' || echo './'`term.c
In file included from term.h:400,
                  from term.c:1205:
../term/pslatex.trm:120: error: static declaration of  
'epslatex_header' follows non-static declaration
../term/post.h:88: error: previous declaration of 'epslatex_header'  
was here

Changing
"static char *epslatex_header..." -> "char *epslatex_header..." in  
pslatex.trm fixed the compile error.  I didn't try the pslatex  
terminal to see if it worked, but I think it should.

--brendan

Re: [Gnuplot-info] logscale and autoscale improvement (was logscale and manual range setting?)

[<br...@ph...>]

Jim Kleckner wrote:
> Hans-Bernhard Broeker wrote:

> It sounds like perhaps a function on the outside to detect this 
> particular situation and set the manual range is the way to go.

Or use
	set autoscale yfix

and live with strange endpoints.  That still won't get you useful
tickmarks, though --- You'll eventually have to either choose a very 
small logarithm base, like

	set log y 1.1

(one labelled tick every 10%), or generate the tic positions outside 
gnuplot.

Re: Bug report and whishlist

[<br...@ph...>]

Ga=EBl Varoquaux wrote:

>   First a non intuitive behavior :=20

=2E.. this is already filed as a bug report on SF.net.


> set output 'result.ps'
> replot
> (then result.ps is drawn)
> set term win

The problem is here.  You only opened the output file, but didn't clo=
se=20
it. The correct sequence is

=09set term {file-writing driver}
=09 set output
=09   plot something
=09 unset output
         set term {GUI}

>   Secondly more interactive terminals : I have never used the win
> terminal (as I don't have a windows box) but it seems to have nice
> features for beginners that could be add to the X11 terminal (and t=
he
> new born Glut terminal ?). These menus should of course be controle=
d by
> a option for the terminal.

The majority of interactive features of the windows terminal driver=
=20
itself (font selection, line type redefinition) are actually=20
anachronisms.   They predate most capabilities of the gnuplot core=
=20
controlling such things, and get in the way of implementing the new=
=20
terminal API capabilities.  So if there's going to be change in this=
=20
area, IMHO it should be in the opposite direction of what you're prop=
osing.

Re: [Gnuplot-info] logscale and autoscale improvement (was logscale and manual range setting?)

[Jim K. <je...@kl...>]

Hans-Bernhard Broeker wrote:
> Jim Kleckner wrote:
> 
>> It would be nice to have the autoscale logic be able to
>> handle the scaling to waste less space, I think.  
> 
> 
> The case you stumbled on is quite particular.  The data yrange is
> [1-epsilon:4.0]  This drives autoscaling for log axis exactly into its 
> worst-case scenario.
> 
> 1) the input range is scarcely one decade long
> 2) it's positioned uncomfortably, with one end point scarcely below a
>    natural tic position.
> 3) it's a logarithmic axis.
> 
> Item 2) means that the autoscaled range will be extended beyond that
> power-of-ten.  Throwing data points off the plot (like 'set yrange 
> [1:10]' does it in this case), is strictly a non-option for the 
> automatic behaviour of gnuplot.  You can turn off this extension, at the 
> risk of getting rather ugly ranges.  See "help autoscale"; the 'fix' 
> options.
> 
> Item 3) means that the extension cannot currently be shorter than one
> full unit in logarithm (i.e. a factor of 10) --- that's why the 
> autoscaled range ends up being [0.1:10].  The core limitation here is 
> that gnuplot still has no way ofcontinuously changing from the only 
> sensible ticking pattern for long log axes (labelled, graphically 
> equidistant major tics, unlabelled, arithmetically equidistant tics in 
> between) to the only sensible one for very short axes (labelled, 
> arithmetically equidistant tics).
> 
> The fact that the additional is perceived to be creating such a huge
> "waste" of plot space is because of item 1).  In the essence, you're in 
> violation of an old lemma of scientific plotting: "He who uses a 
> logarithmic axis spanning less than two decades is rather probably 
> trying to brush some embarrasing detail under the carpet."

It would be great if all of my financial returns exceeded a decade or 
two! :)  Unfortunately, the natural way to look at compounded returns is 
logarithmic and the noisy nature of the information can cause a dip 
below the starting value giving an extra decade at the bottom end and 
sometimes just above a decade at the top end.

>> How hard do you think it would be to start/end the axis
>> on a minitic rather than a major tic if too large a
>> fraction of the range is wasted?
> 
> 
> Starting the axis on a minitic is IMHO not the right solution.  Lifting 
> the limitation that in log axes only at integer powers of the base can 
> currently be major tics is what really needs tackling.  While at it, 
> other axis re-mappings than pow()/log() should be made possible.
> 
> Unfortunately, that'd end up in having to essentially re-write the 
> entire autoticking stuff from scratch.  James Van Zandt made a proposal 
> for that a long time ago, but it never made it into serious discussion, 
> let alone the CVS code.

It sounds like perhaps a function on the outside to detect this 
particular situation and set the manual range is the way to go.

Many thanks for your insight.

Jim

Re: Bug report and whishlist

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

On Monday 09 May 2005 11:00 am, Ethan Merritt wrote:
> On Sunday 08 May 2005 12:57 pm, Ga=EBl Varoquaux wrote:
> >   There is something I don't really understand : the online help (
> > http://gnuplot.sourceforge.net/docs/gnuplot.html#mouse_variables )
> > suggest that "set pause mouse" should work. But it doesn't. It think the
> > actual syntax is "pause mouse".
>=20
> That documentation error was fixed in the documentation source
> some time ago.

My apologies. It was fixed in one place, but you have found a
separate occurance of the error.  Fixed now.

	thanks

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