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

Re: Python parser for gnuplot scripts

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

Fr=E9d=E9ric Mantegazza writes:
> Hello there,
>=20
> I'm working in a french research institute, with a guy who is writing a=
 nice=20
> GUI for Gnuplot. This GUI is written in wxPython, and is oriented for=20
> people who want to analyse data, ie who want to make fit functions, plo=
t=20
> datas and have them fitted.
>=20
> This guy would like to be able to parse a gnuplot script. He started to=
=20
> write a parser in python, but as gnuplot as a very large set of=20
> commands/options, it is not very easy.
>=20
> My question is: do you think it could be possible to get the C parser u=
sed=20
> in the source of gnuplot, run swig on it, add some little code around, =
and=20
> get a usable parser ? I mean, is the C parser of gnuplot store the resu=
lt=20
> of a command line in a structure which can be used easily ?
=20
 The gnuplot parser is essentially a full-custom job, and it's spread acr=
oss
 several source files. E.g. every single .trm file has its own parser for
 terminal options, and in general every source module has its own parser =
for
 the options it provides.

 A number of years ago, I started to move towards a table-driven parser,
 but got stuck somewhere along the line (the plot command is particularil=
y
 nasty in this regard ...).

 What I would like to have is a lex/yacc based scanner/parser for gnuplot=
.
 This would allow to put it into its own module, and let other apps use i=
t.
 But I think no-one here has the skills to write one.

Python parser for gnuplot scripts

[<man...@il...>]

Hello there,

I'm working in a french research institute, with a guy who is writing a nic=
e=20
GUI for Gnuplot. This GUI is written in wxPython, and is oriented for=20
people who want to analyse data, ie who want to make fit functions, plot=20
datas and have them fitted.

This guy would like to be able to parse a gnuplot script. He started to=20
write a parser in python, but as gnuplot as a very large set of=20
commands/options, it is not very easy.

My question is: do you think it could be possible to get the C parser used=
=20
in the source of gnuplot, run swig on it, add some little code around, and=
=20
get a usable parser ? I mean, is the C parser of gnuplot store the result=20
of a command line in a structure which can be used easily ?

Thank's for your help,

=2D-=20
   Fr=E9d=E9ric

'set palette maxcolors' for x11

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

Using a code like

set pal maxcolor 5
set pm3d map
splot x
set out 'a.png'; set term png; replot
set out 'a.ps'; set term post color; replot
set out 'a.pdf'; set term pdf; replot
set out 'a.svg'; set term svg; replot
set out 'a.fig'; set term fig; replot

I have noticed that:

1. X11 draws (maps) one color less.

2. pdf, svg give wrong mapping -- I've just fixed this, together with
aquaterm.

3. postscript makes one color wrong only for 'set pal maxcolor 3'.


The fix of 2. consists of using new routines rgb1maxcolors_from_gray() and
rgb255maxcolors_from_gray() instead of rgb1_from_gray() and
rgb255_from_gray().


Please somebody fix X11 terminal so that:
  - it maps correct number of colors,
  - the color mapping is exactly as in png.

--
PM

Re: emf.trm update

[Stephane B. <gn...@co...>]

Ethan Merritt wrote:

>On Monday 17 May 2004 04:57 am, Hans-Bernhard Broeker wrote:
> =20
>
>>On Mon, 17 May 2004, James R. Van Zandt wrote:
>>   =20
>>
>>>Stephane Barbaray <gn...@co...> writes:
>>>     =20
>>>
>>>>   So here my answer to MS idiots : a new version of emf.trm ;-)
>>>>       =20
>>>>
>>>Where do I find it?
>>>     =20
>>>
>>In the Patch Tracker at SourceForge, or attached to Stephane's mail.
>>Nobody got round to incorporating Stephane's patched version into the
>>CVS tree yet.
>>   =20
>>
>
>The new version does not work for me (or rather, for Word2000).
>
> =20
>
I don't have Word2000... can someone confirm the problem? Working OK for
me in Word97 and Word2002

--=20
St=E9phane BARBARAY.

Re: emf.trm update

[Stephane B. <ste...@co...>]

Ethan Merritt wrote:

>On Monday 17 May 2004 04:57 am, Hans-Bernhard Broeker wrote:
> =20
>
>>On Mon, 17 May 2004, James R. Van Zandt wrote:
>>   =20
>>
>>>Stephane Barbaray <gn...@co...> writes:
>>>     =20
>>>
>>>>   So here my answer to MS idiots : a new version of emf.trm ;-)
>>>>       =20
>>>>
>>>Where do I find it?
>>>     =20
>>>
>>In the Patch Tracker at SourceForge, or attached to Stephane's mail.
>>Nobody got round to incorporating Stephane's patched version into the
>>CVS tree yet.
>>   =20
>>
>
>The new version does not work for me (or rather, for Word2000).
>
> =20
>
I don't have Word2000... can someone confirm the problem? Working OK for=20
me in Word97 and Word2002

--=20
St=E9phane BARBARAY.

Re: Zoom peculiarities

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

Hans-Bernhard Broeker wrote:

>On Fri, 14 May 2004, Hans-Bernhard Broeker wrote:
>
>  
>
>>	set yrange [35.5:*]
>>	load 'using.dem'
>>	# break after the first plot.
>>
>>You'll find the impulses end at 35 instead of 35.5, which is below the
>>bottom border.  Looks like they were auto-extended to the nearest tick
>>position, like autoscaled ranges.  This has to be investigated at 
>>source level.
>>    
>>
>
>I've looked into this, and found the problem.  It's not actually the
>baseline that got mistreated, but the points themselves.  It was using an
>int to hold the y value of the datapoint before clipping it to the range
>boundaries.  As soon as they're non-integer values, like the ones you'll
>almost invariably generate in mouse interaction, this breaks
>spectacularly.
>
>Fixed in CVS as I write this.
>  
>

Great!  Thanks.  There is a lag in the CVS download, so I will confirm 
at a latter time.

Dan

-- 

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

Re: Zoom peculiarities

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

On Fri, 14 May 2004, Hans-Bernhard Broeker wrote:

> 	set yrange [35.5:*]
> 	load 'using.dem'
> 	# break after the first plot.
> 
> You'll find the impulses end at 35 instead of 35.5, which is below the
> bottom border.  Looks like they were auto-extended to the nearest tick
> position, like autoscaled ranges.  This has to be investigated at 
> source level.

I've looked into this, and found the problem.  It's not actually the
baseline that got mistreated, but the points themselves.  It was using an
int to hold the y value of the datapoint before clipping it to the range
boundaries.  As soon as they're non-integer values, like the ones you'll
almost invariably generate in mouse interaction, this breaks
spectacularly.

Fixed in CVS as I write this.

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

Re: SQL plotting

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

On Mon, 17 May 2004, Wesley Morgan wrote:

> Has there been any discussion about integrating support for plotting
> results of queries from database backends? 

No.  And if there were, I'ld be strictly against it, on several grounds.

1) It completely violates the Unix tool philosophy.  "One job <--> one
tool".  Parsing and handling SQL is not gnuplot jobs, by a wide margin.

2) It's a can of worms --- which SQL servers would we support?  Or, more
to the point: who is going to keep up with all of them?  And how can we
possibly justify not support some of them, once we support others?

3) It's utterly unportable.

This is clearly a job for Perl or similar scripting languages.  If you
want to use gnuplot to plot, fine: script it from the outside.  Moving
these kinds of commands into gnuplot is not the right way of doing this.

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

Re: SQL Plotting

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

> > How is gnuplot ever going to know what to send other than just
> > passing through what you type?  I used a fifo in my example to
> > show you that it can be done that way, but for the simple case
> > at hand you can do it all in a single command anyhow:
> >
> > 	plot "< db 'select * from table'" with lines
> >
> > or whatever the database command might be.  What syntax did
> > you have in mind that would be simpler?
>
> The thing is that databases like mysql and postgres, the two most used OSS
> servers, don't output useable data by default (it's "pretty print"), so
> you would have to learn the somewhat cumbersome and irritating syntax to
> fix this (although you could write another passthrough shell command for
> it). Some databases may not even have a command-line client. If gnuplot
> had support for several different backends, you could plot data from any
> of them with ease, not needing to worry about differences in arguments
> etc. Just simple SQL.
>
> Anyhow.. Is there any kind of documentation on the gnuplot internals, or
> am I better off reading the source?


I propose you write a "simple" C/C++/awk/perl program what would do the
above you want gnuplot to do. This program would output just two columns on
its standard output according to your select. This way, you can fully
implement your idea but still don't put plenty of new code and external
libraries into gnuplot.

If your program is working, it can be referenced from gnuplot web page.

Note that gnuplot is used this way for accessing other specific data
formats, for example structured data files from synchrotron experiments.

Loading dynamical functions would be another solution. But piping works OK.

--
PM

parts chart

[Dan J. <ji...@ji...>]

Maybe as quick way to find how to adjust different parts of a graph,
there should be distributed in the docs some .png files with arrows
pointing to each part of a graph, with names of that part.

E.g. it took me an hour to find out the name of the part that was
bothering me was "key", I needed to unset "key", and not "title",
"label" etc.

Splotting a sphere looks squashed.  I don't know how you can convey
whatever one needs to do to unsquash it on the diagram I call for
above, unless it is axis related...

Re: SQL Plotting

[Wesley M. <mo...@ch...>]

On Mon, 17 May 2004, Ethan Merritt wrote:

> On Monday 17 May 2004 05:54 pm, you wrote:
> > > Something more or less like:
> > >
> > > gnuplot> ! mkfifo ./database_out
> > > gnuplot> ! db 'select * from table' > ./database_out
> > > gnuplot> plot '< ./database_out' with lines
> >
> > Yes, but isn't that much more complicated than simply gnuplot itself
> > supporting a direct connection to the db? :>
>
> I don't know.
> I still don't understand what you have in mind, maybe because
> I'm not a database guy.
>
> Isn't every database going to have its own set of commands?

That's what SQL is for :)

> How is gnuplot ever going to know what to send other than just
> passing through what you type?  I used a fifo in my example to
> show you that it can be done that way, but for the simple case
> at hand you can do it all in a single command anyhow:
>
> 	plot "< db 'select * from table'" with lines
>
> or whatever the database command might be.  What syntax did
> you have in mind that would be simpler?

The thing is that databases like mysql and postgres, the two most used OSS
servers, don't output useable data by default (it's "pretty print"), so
you would have to learn the somewhat cumbersome and irritating syntax to
fix this (although you could write another passthrough shell command for
it). Some databases may not even have a command-line client. If gnuplot
had support for several different backends, you could plot data from any
of them with ease, not needing to worry about differences in arguments
etc. Just simple SQL.

Anyhow.. Is there any kind of documentation on the gnuplot internals, or
am I better off reading the source?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: SQL Plotting

[Wesley M. <mo...@ch...>]

On Mon, 17 May 2004, Ethan Merritt wrote:

> On Monday 17 May 2004 04:58 pm, Wesley Morgan wrote:
> > I'm simply thinking that I would like to be able to execute something
> > like this...
> >
> > set dbserver 'localhost'
> > set dbname 'test'
> > set dbuser 'test'
> > plot 'select * from table' with lines
> > <ask for password if necessary>
> > <plot away>
>
> I'm lost. What is this snippet supposed to represent?
> Are these commands to gnuplot?

Yes, exactly.

> > As you see, I'm not looking for an interface TO gnuplot, the command
> > line works quite well for me. I'm more curious as to how difficult it
> > would be to add this functionality to gnuplot itself. It already
> > supports a tremendous range of output formats, so why not accept a few
> > more input methods?
>
> But isn't that just another pipe, or anyway a pair of pipes?
> What is different about this input to gnuplot that distinguishes it
> from any other input to gnuplot?

Well by "input" I meant data not commands.

> If I understand what you are trying to do, you should be able
> to send your commands *to* the database with shell escapes
> and read the output *from* the database via a pipe.
> Something more or less like:
>
> gnuplot> ! mkfifo ./database_out
> gnuplot> ! db 'select * from table' > ./database_out
> gnuplot> plot '< ./database_out' with lines

Yes, but isn't that much more complicated than simply gnuplot itself
supporting a direct connection to the db? :>


-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: (no subject)

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

On Monday 17 May 2004 04:58 pm, Wesley Morgan wrote:
> I'm simply thinking that I would like to be able to execute something
> like this...
>
> set dbserver 'localhost'
> set dbname 'test'
> set dbuser 'test'
> plot 'select * from table' with lines
> <ask for password if necessary>
> <plot away>

I'm lost. What is this snippet supposed to represent?
Are these commands to gnuplot?

> As you see, I'm not looking for an interface TO gnuplot, the command
> line works quite well for me. I'm more curious as to how difficult it
> would be to add this functionality to gnuplot itself. It already
> supports a tremendous range of output formats, so why not accept a few
> more input methods? 

But isn't that just another pipe, or anyway a pair of pipes?
What is different about this input to gnuplot that distinguishes it
from any other input to gnuplot?  

If I understand what you are trying to do, you should be able
to send your commands *to* the database with shell escapes
and read the output *from* the database via a pipe.
Something more or less like:

gnuplot> ! mkfifo ./database_out
gnuplot> ! db 'select * from table' > ./database_out
gnuplot> plot '< ./database_out' with lines


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

(no subject)

[Wesley M. <mo...@ch...>]

On Mon, 17 May 2004, Ethan Merritt wrote:

> On Monday 17 May 2004 03:53 pm, Wesley Morgan wrote:
> > Has there been any discussion about integrating support for plotting
> > results of queries from database backends? Like many people, I have a
> > tremendous amount of data in databases but the only way to plot it in
> > gnuplot is with complicated systems of pipes or exporting to text files.
>
> Some of us in the unix world hold the contrary view,  that pipes and
> text files are the easy and uncomplicated way to go.  What did you
> have in mind as an alternative?

I'm simply thinking that I would like to be able to execute something like
this...

set dbserver 'localhost'
set dbname 'test'
set dbuser 'test'
plot 'select * from table' with lines
<ask for password if necessary>
<plot away>

Rather than have to create a data file, or pipe data from another program
to gnuplot. I don't know about you but it seems a lot less complicated to
me (and I hail from many years of unix, ;)). You could optionally keep the
query result around until another is issued for use with replot to save
some work on the backend.

As you see, I'm not looking for an interface TO gnuplot, the command line
works quite well for me. I'm more curious as to how difficult it would be
to add this functionality to gnuplot itself. It already supports a
tremendous range of output formats, so why not accept a few more input
methods? Adding support for a few db backends would surely be very similar
(if not easier) than reading data files.

> > What kind of function 'hooks' would need to be provided to the plotting
> > routines to accomplish this?
>
> There are interfaces to gnuplot through
> java:
> 	http://www.is.informatik.uni-duisburg.de/projects/java-unidu/api/de/unidu/is/gnuplot/Gnuplot.html
> perl:
> 	http://search.cpan.org/~ilyaz/Term-Gnuplot-0.5704/Gnuplot.pm
> python:
> 	http://gnuplot-py.sourceforge.net/

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

SQL plotting

[Wesley M. <mo...@ch...>]

Has there been any discussion about integrating support for plotting
results of queries from database backends? Like many people, I have a
tremendous amount of data in databases but the only way to plot it in
gnuplot is with complicated systems of pipes or exporting to text files.

What kind of function 'hooks' would need to be provided to the plotting
routines to accomplish this?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: Zoom peculiarities

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

Petr Mikulik wrote:

>>plot [0:50] [-2:2] sin(x)
>>
>>and attempt to zoom.  It won't zoom!  That certainly isn't a user
>>expectation, is it?
>>    
>>
>
>See also Bug Request
>
>	921028	Mouse zoom doesn't work if range has been given
>
>
>In the old ages of mousing, I intended this behaviour, mainly for use such
>as
>
>	plot [0:11] sin(x)
>
>=> you can fix x-range, and zoom by mouse only in y-axis.
>

I guess.  But I wonder how many people are cognizant enough of the mouse 
behavior to understand this is possible.  Also, if there is this option 
of only allowing zooming in the y-axis, the logical thing would be for 
the mouse cursor to change from drawing a zoom box to drawing a zoom 
"bar" in only the y direction.

>
>If you wish to use mouse, don't do   plot [ranges]  but
>set xrange ...; plot ...
>

So, is intended behavior that the mouse zoom change gnuplot's internal 
x-range and y-range so that a "replot" can be done to a different 
terminal device and that plot will have the new zoomed x-range and y-range?

Dan

Re: emf.trm update

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

On Monday 17 May 2004 04:57 am, Hans-Bernhard Broeker wrote:
> On Mon, 17 May 2004, James R. Van Zandt wrote:
> > Stephane Barbaray <gn...@co...> writes:
> > >    So here my answer to MS idiots : a new version of emf.trm ;-)
> >
> > Where do I find it?
>
> In the Patch Tracker at SourceForge, or attached to Stephane's mail.
> Nobody got round to incorporating Stephane's patched version into the
> CVS tree yet.

The new version does not work for me (or rather, for Word2000).

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

Re: emf.trm update

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

On Mon, 17 May 2004, James R. Van Zandt wrote:

> 
> Stephane Barbaray <gn...@co...> writes:
> >    So here my answer to MS idiots : a new version of emf.trm ;-)
> 
> Where do I find it?  

In the Patch Tracker at SourceForge, or attached to Stephane's mail.  
Nobody got round to incorporating Stephane's patched version into the CVS
tree yet.

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

Re: emf.trm update

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

Stephane Barbaray <gn...@co...> writes:
>    So here my answer to MS idiots : a new version of emf.trm ;-)

Where do I find it?  I've just done a "cvs update", but emf.trm hasn't
changed.

I have my CVS/Root set to
  van...@cv...:/cvsroot/gnuplot

The last entry in /Changelog is:
  2004-05-09  Ethan Merritt  <merritt@u.washington.edu>
  
  	* term/x11.trm: Reduce time delay in waitforinput() from 1 sec
  	to 100 usec.


	- Jim Van Zandt

Re: Zoom peculiarities

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

> plot [0:50] [-2:2] sin(x)
>
> and attempt to zoom.  It won't zoom!  That certainly isn't a user
> expectation, is it?

See also Bug Request

	921028	Mouse zoom doesn't work if range has been given


In the old ages of mousing, I intended this behaviour, mainly for use such
as

	plot [0:11] sin(x)

=> you can fix x-range, and zoom by mouse only in y-axis.

If you wish to use mouse, don't do   plot [ranges]  but
set xrange ...; plot ...

Mousing is interactive stuff .. you can do your script compatible.

Or is there any situation why  plot [range]  should be used instead of  set
xrange; plot ?

---
PM

Re: Zoom peculiarities

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

On Thu, 13 May 2004, Daniel J Sebald wrote:

> I see what is happening now.  Impulses should behave so that negative 
> numbers have a line appearing below y=0.  However, it appears that the 
> current behavior does the same thing for *any* border that appears at 
> the bottom of the plot.  

More to the point, it'll try to draw them towards the border y=0 would
lie beyond, if y=0 isn't inside the yrange of the plot.  But something
went wrong in that area, so the actual baseline may not always be the 
border itself, but will end up slightly outside the actual y range.

You can reproduce the problem without involving the mouse:

	set yrange [35.5:*]
	load 'using.dem'
	# break after the first plot.

You'll find the impulses end at 35 instead of 35.5, which is below the
bottom border.  Looks like they were auto-extended to the nearest tick
position, like autoscaled ranges.  This has to be investigated at 
source level.

>  For some reason, gnuplot thinks it can plot outside the bottom border. 

Not quite.  It doesn't really "think" about drawing outside borders
at all.  In technical terms: it doesn't clip all graphical primitives
to the graph window.

> >Workaround: don't zoom in demos; or if you do, remember to unzoom _before_
> >you proceed to the next plot. Using 'unzoom' on a different graph than the
> >one you zoomed on is IMHO begging for trouble.
> >
> 
> So, when unzoomed in the second plot, the ranges go back to [*:*] or 
> something like that.  

No.  They go back to what they were before you started to zoom.  Do it
in '6' mode and you'll see it happening.

> But why should the explicit
> 
> set xrange [1:8]
> 
> be discarded?  

It's not discarded --- it's overruled by "set xrange [-1:24]"
from the first plot which got pulled off the zoom stack by your typing 
'u'.


> Anyway, I don't see how the "each plot has its own 
> settings" would change matters.  

It wouldn't, all on its own.  But it's a nacessary piece of infrastructure
for allowing the next step.  In particular, the mouse interaction could
avoid garbling the global settings, and each new 'plot' command entered
from the command line could reset the mouse code's copy of the settings.

Conceptually, we have two independent streams of commands.  For that to
work without strange surprises like the one you observed, those two
streams of commands have to work on independant sets of status variables,
synchronized only on explicit request.

> If one plot is zoomed and then a second 
> is generated, what will you use for the ranges of the second plot? 

The 'command line' settings.  The idea would be that the mouse interaction
would have its *own* set of settings to play with.  One per simultaneously
open plot window, actually.

> which would mean that the range settings in this command only apply to 
> replot and when a new plot command comes along, the original ranges are 
> used, not the "temp" or "replot" ones.  Also, with the new plot command, 
> these "temp" or "replot" settings are changed to those ranges 
> corresponding to "plot".

You're just reinventing the same scheme I've been talking about ;-)
Except that I wouldn't limit that to the ranges, but have a complete
collections of all gnuplot settings.  

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

Re: Able to replicate now...

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

Ethan A Merritt wrote:

>On Thursday 13 May 2004 08:26 pm, Daniel J Sebald wrote:
>  
>
>>I believe I am able to replicate the plot object placement problem in
>>X11.  The fillstyle demo seems particularly apt to cause its occurrence.
>> After doing
>>
>>load 'fill_style.dem'
>>
>>and the plot window appears, resize the plot window so that it is rather
>>narrow, say 2 or 3cm or a ration of 6 to 1.  Now hit return for the next
>>plot.  Resize the window back to the normal size, and I see a
>>mispositioned plot and objects not in the right place, or filled regions
>>at strange angles.  Hitting return will sometimes  continue to produce
>>mispositioned plots.  After a few of these strange plots it will correct
>>itself.
>>    
>>
>
>It doesn't do anything odd for me.  The only ugliness I see is that the
>font positioning is not quite correct immediately after resizing the window.
>This is inherent in the way the gnuplot<->gnuplot_x11 communication is
>done.  The font info is updated at the start of every plot or replot 
>command. But a resize by itself does not trigger a replot.  So right after
>you resize the plot the actual text layout is no longer correct for the new
>plot size. But as soon as you do a plot or replot it should be OK again.
>
>
>  
>
>>Here is something else I noticed, totally unrelated from that.  Running
>>the same demo, I accidently hit the up arrow (out of habit of displaying
>>the last command, but in fact I'm in pause mode so no command appears,
>>but instead ^[[A.  Now after hitting return, the plot takes a very long
>>time to appear.  Successive plots also seem to take a long time.  Ethan,
>>is this the same situation as we were talking about before?
>>    
>>
>
>No. It sounds like something is wrong with your configuration.
>For me if I hit up-arrow as you say, it buffers the input and then
>when I hit return I get an immediate jump through the next several
>plots because of the extra characters in the input buffer.  No delay at all.
>
>Try a 'make clean' and 'make' to force everything to recompile jointly.
>Then see if you can replicate these problems.
>

OK, I did a make clean.  Still getting the same thing.  Attached are 
some example PNG plots.  The first looks like the key element is much 
larger than it should be.  The second has the plot upside down.  The 
third has a key element drawn in a random direction.

I've updated my system a bit so that "prepare" and "configure" work 
without complaint.  Here are a few bits of info if it helps:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)

This file was extended by config.status, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  CONFIG_FILES    =
  CONFIG_HEADERS  =
  CONFIG_LINKS    =
  CONFIG_COMMANDS =
  $ ./config.status

** Configuration summary for gnuplot 4.0.0:

  Where is the help file?           /usr/local/share/gnuplot/4.0/gnuplot.gih

configure:13496: result:   Use builtin minimal readline
configure:13512: result:   Enable generation of JPEG files
configure:13522: result:   Enable generation of PNG files
configure:13527: result:     using gd driver
configure:13545: result:   Enable generation of PDF files
configure:13559: result:   Build gnuplot-mode for X/Emacs
configure:13569: result:   Build LaTeX tutorial
configure:13574: result:   Use the X Window System
configure:13577: result:   Enable mouse for X11
configure:13583: result:   Enable pm3d
configure:13588: result:   Enable filledboxes
configure:13593: result:   Enable relative boxwidths
configure:13598: result:   Enable defined(variable) test
configure:13618: result:   Enable fitting error variables

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_c_compiler_gnu=yes
ac_cv_c_const=yes
ac_cv_c_inline=inline
ac_cv_c_stringize=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_func_atexit=yes
ac_cv_func_bcopy=yes
ac_cv_func_bzero=yes
ac_cv_func_connect=yes
ac_cv_func_doprnt=no
ac_cv_func_erf=yes
ac_cv_func_erfc=yes
ac_cv_func_gamma=yes
ac_cv_func_getcwd=yes
ac_cv_func_gethostbyname=yes
ac_cv_func_index=yes
ac_cv_func_lgamma=yes
ac_cv_func_memcpy=yes
ac_cv_func_memmove=yes
ac_cv_func_memset=yes
ac_cv_func_on_exit=yes
ac_cv_func_pclose=yes
ac_cv_func_poll=yes
ac_cv_func_popen=yes
ac_cv_func_remove=yes
ac_cv_func_rindex=yes
ac_cv_func_select=yes

-- 

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

Re: Able to replicate now...

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

On Thursday 13 May 2004 08:26 pm, Daniel J Sebald wrote:
>
> I believe I am able to replicate the plot object placement problem in
> X11.  The fillstyle demo seems particularly apt to cause its occurrence.
>  After doing
>
> load 'fill_style.dem'
>
> and the plot window appears, resize the plot window so that it is rather
> narrow, say 2 or 3cm or a ration of 6 to 1.  Now hit return for the next
> plot.  Resize the window back to the normal size, and I see a
> mispositioned plot and objects not in the right place, or filled regions
> at strange angles.  Hitting return will sometimes  continue to produce
> mispositioned plots.  After a few of these strange plots it will correct
> itself.

It doesn't do anything odd for me.  The only ugliness I see is that the
font positioning is not quite correct immediately after resizing the window.
This is inherent in the way the gnuplot<->gnuplot_x11 communication is
done.  The font info is updated at the start of every plot or replot 
command. But a resize by itself does not trigger a replot.  So right after
you resize the plot the actual text layout is no longer correct for the new
plot size. But as soon as you do a plot or replot it should be OK again.


> Here is something else I noticed, totally unrelated from that.  Running
> the same demo, I accidently hit the up arrow (out of habit of displaying
> the last command, but in fact I'm in pause mode so no command appears,
> but instead ^[[A.  Now after hitting return, the plot takes a very long
> time to appear.  Successive plots also seem to take a long time.  Ethan,
> is this the same situation as we were talking about before?

No. It sounds like something is wrong with your configuration.
For me if I hit up-arrow as you say, it buffers the input and then
when I hit return I get an immediate jump through the next several
plots because of the extra characters in the input buffer.  No delay at all.

Try a 'make clean' and 'make' to force everything to recompile jointly.
Then see if you can replicate these problems.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Able to replicate now...

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

Hans-Bernhard Broeker wrote:

>>strings would be shifted, the key would be in the wrong place.  The next 
>>two or three plots showed the same thing, getting progressively worse. 
>> The problem then corrected itself and things worked fine again.  I 
>>haven't been able to reproduce this.
>>    
>>
>
>Well, next time you come across this, 'save' the state of the broken plot
>then, before it disappears.
>  
>

I believe I am able to replicate the plot object placement problem in 
X11.  The fillstyle demo seems particularly apt to cause its occurrence. 
 After doing

load 'fill_style.dem'

and the plot window appears, resize the plot window so that it is rather 
narrow, say 2 or 3cm or a ration of 6 to 1.  Now hit return for the next 
plot.  Resize the window back to the normal size, and I see a 
mispositioned plot and objects not in the right place, or filled regions 
at strange angles.  Hitting return will sometimes  continue to produce 
mispositioned plots.  After a few of these strange plots it will correct 
itself.

Here is something else I noticed, totally unrelated from that.  Running 
the same demo, I accidently hit the up arrow (out of habit of displaying 
the last command, but in fact I'm in pause mode so no command appears, 
but instead ^[[A.  Now after hitting return, the plot takes a very long 
time to appear.  Successive plots also seem to take a long time.  Ethan, 
is this the same situation as we were talking about before?  Or might it 
have to do with command memory and the "pause" command?

Dan

Errors in Batch mode

[Lauren C. <la...@co...>]

Hi All, 

 

Apologies if this in an FAQ, but I'm in the process of integrating version 4
into our gnuplot-enabled web applications and have the same question I had
back in 2000 (on ver 3.7).

 

When running on MS Windows, is there any mechanism whereby the errors that
would be displayed in interactive mode (with LOAD), can be stored to a file
when running in batch mode?

 

Thanks, 

 

-lc 

 

PS: Congrats on version 4 BTW. It's been a very smooth transition thus far,
and I'm seeing substantial performance increases, not to mention new
features I'm sure will be useful.

 

Lauren Clarke

Director, 

Cornerstone Systems Northwest Inc.

8665 Berthusen Road

Lynden WA 98264

360-318-1011

 <http://www.cornerstonenw.com/> www.cornerstonenw.com