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

arrow head adjustment

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

Did anyone have any ideas for getting the
width of a line in terms of plot units from the
terminal?

Dan

[Fwd: Re: new command: raise]

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

Hans-Bernhard Broeker wrote:

>If gnuplot is being used interactively, I would think raising windows on
>user request is a task well outside gnuplot's domain --- that's what you
>have a GUI with a window manager for.
>

Oh, and yes it is the job of the GUI panel, dock, or whatever
to be well organized.  To me, that is the fastest way to find and
raise a window.

I point out that having this control in Gnuplot is of some use
in cases where there is an application utilizing Gnuplot through
a pipe.  Say I write a GUI-based app for processing and
managing images, waveforms, or what have you.  If my app
has some kind of menu where I can select files or whatnot,
one of the functions may be to bring that waveform to the
front of the screen, enlarge the window, close the window,
etc.

Dan




-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: new command: raise

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

Hans-Bernhard Broeker wrote:

>On Thu, 4 Dec 2003, Petr Mikulik wrote:
>
>  
>
>>Often I need to raise terminal windows (or multiple windows in X11)
>>covered by other windows on the desktop (editor, console, ...), for
>>which I had to do "replot" -- but that doesn't work with inline data,
>>with multiple open gnuplot_x11 windows etc.
>>    
>>
>
>I don't see how it can be a good idea to have a gnuplot-internal command
>to raise a graph window to the front.
>
>If gnuplot is being used interactively, I would think raising windows on
>user request is a task well outside gnuplot's domain --- that's what you
>have a GUI with a window manager for.
>
>If gnuplot is non-interactive (scripted or redirected), I don't think the
>script has any business actively raising windows except when they're first
>created or the plot actually changed.  Not unless gnuplot is the only
>program displaying visible windows at a given time.  And maybe not even
>then.  There must have been a reason X11 has option -noraise to avoid
>that, right?
>

I sort of agree with Hans on this one, and the reason is because of
the Gnuplot paradigm which seems to be that plot commands get
sent to terminals in a unidirectional way.

There was discussion on the list about making the plots in Gnuplot
internally more object oriented so that old plots could be replotted
without having to reissue all the necessary commands.  If that were
to become the new paradigm then I would say that having a dedicated
"raise" command might fit, but as it stands probably not.

That doesn't mean a convenient "raise" isn't a good idea, because
it is, and it's something I would find useful.  I would say such a thing
really should be part of the "set term", if anywhere, if the behavior
can be tweeked such that "set term x11 44 raise" would raise the
window.  I realize the option doesn't actually raise the window immediately,
only upon plotting... and I guess these are mutually exclusive things, 
i.e., that
one might want to just raise the window now to be able to see it and not
necessarily to keep raising to the front upon plot in the future.

Could a solution be to add several more options that control the
window?  Instead of just "close" how about

{close | front | back | minimize | maximize | fullscreen}

But again, the idea of how to handle the effect of these on the
current plot hangs out there.  I would say that these should _not_
change the current plot number, but I realize that that is potentially
confusing as it seems to violate the current documentation a bit.

Dan

Re: new command: raise

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

On Thu, 4 Dec 2003, Petr Mikulik wrote:

> Often I need to raise terminal windows (or multiple windows in X11)
> covered by other windows on the desktop (editor, console, ...), for
> which I had to do "replot" -- but that doesn't work with inline data,
> with multiple open gnuplot_x11 windows etc.

I don't see how it can be a good idea to have a gnuplot-internal command
to raise a graph window to the front.

If gnuplot is being used interactively, I would think raising windows on
user request is a task well outside gnuplot's domain --- that's what you
have a GUI with a window manager for.

If gnuplot is non-interactive (scripted or redirected), I don't think the
script has any business actively raising windows except when they're first
created or the plot actually changed.  Not unless gnuplot is the only
program displaying visible windows at a given time.  And maybe not even
then.  There must have been a reason X11 has option -noraise to avoid
that, right?

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

Re: new command: raise

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

Ethan Merritt wrote:

>On Thursday 04 December 2003 13:38, Ethan Merritt wrote:
>  
>
>>>will change the current plot to 100.  But should
>>>	 set term x11 105 raise
>>>actually change the current plot number, or should
>>>it just raise that plot (if it exists) and not change the plot?
>>>      
>>>
>>The latter, definitely.
>>    
>>
>
>Oops.  I see now that this would specifically contradict 
>what the current documentation states.  Sigh.
>

If it is a portion of the documentation that has just been
added, I think changing the documentation and behavior
of "close" for "set term" would be fine.

>Maybe we could change the syntax of these new options to
>	set term x11 {{close|raise} {<x>}}
>That is, a terminal number immediately following the
>'close' or 'raise' indicates that this command leaves
>the current terminal unchanged.  While
>	set term x11 <x> raise
>would continue to set the current window to <x> and flag it
>to raise again on every new plot, as it does now.
>
>Seems kind of confusing.  Let me try again....
>Petr proposed
>	'raise' or 'raise one' 
>and I protested that it was not necessarily clear which
>terminal was involved.  How about modifying this to
>	'{raise|close} term x11 <x>'
>
>I'm not sure either raise or close belongs in a 'set ...'
>command anyhow, since it's a one-time action rather
>than a continuing property.
>  
>

At first I didn't catch your meaning, but now I think
I see what you are saying.  By your thinking, then,
'title "plot title"' would stay with the 'set term ...'
command because that is still setting a _property_
of the window.  "raise" and "close" are basically
arranging the desktop and do not constitute a
property.  They would have no effect on the current
plot.  (Unless of course the current plot is one that
was closed, in which case it goes to the most
recently created, if I recall correctly.)

That's fine with me so long as others don't feel
dedicating an instruction for a rather limited purpose
is too much.  I'd say then deactivate the "raise" and
"close" commands and its documentation if the
Gnuplot build is configured such that a windows-based
terminal is not compiled into the executable.  I.e.,

#if defined(X11) || defined(OS2) || defined(Windows)
close and raise command code
#endif



Dan

Re: new command: raise

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

On Thursday 04 December 2003 13:38, Ethan Merritt wrote:
> > will change the current plot to 100.  But should
> >=09 set term x11 105 raise
> > actually change the current plot number, or should
> > it just raise that plot (if it exists) and not change the plot?
>
> The latter, definitely.

Oops.  I see now that this would specifically contradict=20
what the current documentation states.  Sigh.

Maybe we could change the syntax of these new options to
=09set term x11 {{close|raise} {<x>}}
That is, a terminal number immediately following the
'close' or 'raise' indicates that this command leaves
the current terminal unchanged.  While
=09set term x11 <x> raise
would continue to set the current window to <x> and flag it
to raise again on every new plot, as it does now.

Seems kind of confusing.  Let me try again....
Petr proposed
=09'raise' or 'raise one'=20
and I protested that it was not necessarily clear which
terminal was involved.  How about modifying this to
=09'{raise|close} term x11 <x>'

I'm not sure either raise or close belongs in a 'set ...'
command anyhow, since it's a one-time action rather
than a continuing property.











> And now that I look, I see that your earlier patch does not
> behave this way.  But it ought to.
> =09set term x11 101 close
> should close window 101 but leave the current window
> unchanged.  Do you want to make that change, or should I?
>
> > I tend to use the Gnome desktop panel for raising
> > the windows.  (The problem is if one starts to get too
> > many plots open it is difficult to remember in which
> > order they came and the plot number never seems
> > to appear in the little panel icon because it is "Gnuplot #"
>
> That sounds like a bug in Gnome.  I don't think we should
> worry about modifying gnuplot just to correct for poor
> window managers.   KDE and CDE both show the plot title
> correctly in the corresponding window icon.
> (Let the flamewars begin :-)

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

Re: new command: raise

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

On Thursday 04 December 2003 13:06, Daniel J Sebald wrote:
> I think the "set term ..." approach is better, but there
> could be some confusion about it.  Typing
>
> set term x11 100
>
> will change the current plot to 100.  But should
>=09 set term x11 105 raise
> actually change the current plot number, or should
> it just raise that plot (if it exists) and not change the plot?

The latter, definitely.
And now that I look, I see that your earlier patch does not
behave this way.  But it ought to.
=09set term x11 101 close
should close window 101 but leave the current window
unchanged.  Do you want to make that change, or should I?

> I tend to use the Gnome desktop panel for raising
> the windows.  (The problem is if one starts to get too
> many plots open it is difficult to remember in which
> order they came and the plot number never seems
> to appear in the little panel icon because it is "Gnuplot #"

That sounds like a bug in Gnome.  I don't think we should
worry about modifying gnuplot just to correct for poor
window managers.   KDE and CDE both show the plot title
correctly in the corresponding window icon.
(Let the flamewars begin :-)

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

Re: new command: raise

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

Ethan Merritt wrote:

>On Thursday 04 December 2003 10:31, Petr Mikulik wrote:
>
>  
>
>>Solution: new command "raise" (abbreviated "ra"). Enclosed is an
>>implementation for OS/2 PM and Windows terminals.
>>    
>>
>
>Your patch calls driver-specific routines directly from the core code
>in command.c.  Doesn't that break all sorts of things?  What if your
>current terminal type is something other than the windows or OS2
>terminal? 
>
>I would think such a command would have to be implemented either
>as a new driver entry point  (term->raise)(win_number), or via a new
>option to `set term`.  
>
>  
>
>>Could somebody contribute X11 code?
>>Note: proposed is "raise one" command for x11, which would raise just
>>that one currently "set term"ed window, instead of all windows.
>>    
>>
>
>Wouldn't it be better to handle this as in Daniel Sebald's recent patch to
>communcate with previously opened X windows?
>	set term x11 <win#> raise
>The command is already accepted by the current syntax and parser.
>We just need to force an immediate "raise" event if the window already exists.
>I'll have a look - it sounds easy enough.
>

Ethan, Petr added this code to CVS so you should
be able to work from there.

I think the "set term ..." approach is better, but there
could be some confusion about it.  Typing

set term x11 100

will change the current plot to 100.  But should

set term x11 105 raise

actually change the current plot number, or should
it just raise that plot (if it exists) and not change the
current plot?

The only thing about the "set term ..." approach
is that it is slightly long for doing a raise.  Raising
is one of those commands that is more useful for
fluent use of Gnuplot when there are a lot of plots
open and you are working away.  So it would nice
for such a command to be short.

I tend to use the Gnome desktop panel for raising
the windows.  (The problem is if one starts to get too
many plots open it is difficult to remember in which
order they came and the plot number never seems
to appear in the little panel icon because it is "Gnuplot #"
and there is never enough room for the number...
The most recent version of Gnome may have fixed
this.  It seems to place all windows launched from
the same process under one selectable menu.)

Dan

Re: new command: raise

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

On Thursday 04 December 2003 10:31, Petr Mikulik wrote:

> Solution: new command "raise" (abbreviated "ra"). Enclosed is an
> implementation for OS/2 PM and Windows terminals.

Your patch calls driver-specific routines directly from the core code
in command.c.  Doesn't that break all sorts of things?  What if your
current terminal type is something other than the windows or OS2
terminal?=20

I would think such a command would have to be implemented either
as a new driver entry point  (term->raise)(win_number), or via a new
option to `set term`. =20

> Could somebody contribute X11 code?
> Note: proposed is "raise one" command for x11, which would raise just
> that one currently "set term"ed window, instead of all windows.

Wouldn't it be better to handle this as in Daniel Sebald's recent patch t=
o
communcate with previously opened X windows?
=09set term x11 <win#> raise
The command is already accepted by the current syntax and parser.
We just need to force an immediate "raise" event if the window already ex=
ists.
I'll have a look - it sounds easy enough.

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

new command: raise

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

Often I need to raise terminal windows (or multiple windows in X11) covered
by other windows on the desktop (editor, console, ...), for which I had to
do "replot" -- but that doesn't work with inline data, with multiple open
gnuplot_x11 windows etc.

Solution: new command "raise" (abbreviated "ra"). Enclosed is an
implementation for OS/2 PM and Windows terminals. Could somebody contribute
X11 code?

Note: proposed is "raise one" command for x11, which would raise just that
one currently "set term"ed window, instead of all windows.

Well, I hope, you will like it too, so I can committ it afterwards...

---
Petr Mikulik

Re: strange auto tic behavior in 3.8j with timeseries data

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

On Mon, 1 Dec 2003, Kelley, Scott wrote:

> In order to using scalable png's, 

What's a "scalable png"?  PNG is just as scalable or not as any other
pixel-based file format.  Which means: hardly at all.

> I just installed gnuplot 3.8j onto a Redhat7.2 box.  I'm trying to plot
> timeseries data. The autofreq's xtics are not behaving right (i.e. like
> they did under gnuplot 3.7).

I'm afraid "like 3.7 did" is not a particularly precise description of
"behaving right".  To put it mildly.  Timeseries autoticking in 3.7 worked
more by lucky happenstance than by design.  In particular, it quite
reliably broke on Intel FPUs because of rounding problems, as soon as any
compiler optimization was allowed, because it tried to apply *decimal*
based auto-ticking to time data, which don't adhere to decimal system in
any way.

This area has been rewritten almost completely since 3.7.  Responsibility
for it is mine, so I'll try to see how this can be fixed.

> They go to hour intervals well before they should.  And (even worse) the
> x axis gets stretched to be an hour, even if the data only covers part
> of the hour.  35 minutes seems to be about the point the problem
> manifests.

36 minutes, actually ;-)  That's 12 times 3 minutes, and that's the actual
threshold the observed behaviour relies on.  An easier way to reproduce
the problem is:

	set ydata time
	set format y '%H:%M:%S'
	p [1e4 : 1e4 + 36*60 -1] x

As given, you get 3-minute major tic intervals.  Remove the "-1", and you
get 1 hour.  I'm not entirely sure why it behaves this way --- the key
function in charge of this, quantize_time_tics() returns a quite
reasonable 5 minutes as the tic interval for an axis 36 minutes long.
The bug seems to happen in the communication between it and 
'time_tic_just' which decides on axis endpoints for the plot.

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

strange auto tic behavior in 3.8j with timeseries data

[Kelley, S. <Sco...@di...>]

In order to using scalable png's, I just installed gnuplot 3.8j onto a =
Redhat7.2 box.  I'm trying to plot timeseries data.

The autofreq's xtics are not behaving right (i.e. like they did under =
gnuplot 3.7).

They go to hour intervals well before they should.  And (even worse) the =
x axis gets stretched to be an hour, even if the data only covers part =
of the hour.  35 minutes seems to be about the point the problem =
manifests.

Any ideas ?  My attempt to force expected behavior with various xtic and =
mxtics options have not worked.


Example -

set xdata time
set xtics rotate
set timefmt  "%Y-%m-%d %H:%M:%S"
set format x "%Y-%m-%d %H:%M:%S"
set terminal png small
set output "broke.png"
plot "broke.csv" using 1:3 with lines
set output "works.png"
plot "works.csv" using 1:3 with lines


broke.csv
2003-11-25 14:20:00, 1
2003-11-25 14:30:00, 10
2003-11-25 14:56:00, 1

works.csv
2003-11-25 14:20:00, 1
2003-11-25 14:30:00, 10
2003-11-25 14:55:00, 1

--=20
Scott Kelley | Disney Enterprise Services

Re: test palette rgb

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

> On Tuesday 25 November 2003 05:58, Petr Mikulik wrote:
> > > <stdio.h>: FILE *tmpfile(void)
> >
> > Unfortunately this does not provide name of the file which I could use
> > in plot 'tmp_file1'
>
> You wouldn't need a file name if you wrote the data as an in-line command:
>   plot '-'
>   xx xx xx
>   xx xx xx
>   E
> and then passed the FILE pointer directly to load_file().
>
> So the code would look like:
> 	pre1 = tmpfile();  data = tmpfile(); post1 = tmpfile();
> 	fprintf(pre1, buf1);	/* write preliminary commands */
> 	fprintf(data, buf2);	/* write inline data for plot */
> 	fprintf(post1, buf3);	/* write any trailing commands */
> 	rewind(pre1); rewind(data); rewind(post1);
> 	load_file(pre1, ...);
> 	load_file(data, ...);
> 	load_file(post1, ...);
>
>
> > 	save set 'tmp_file2'
>
> A similar trick should work here:
> 	save_set(savefp=tmpfile());
> 	...
> 	load_file(savefp, ...);

In the final rework, it turned out that it is sufficient to use only one
temporary file once submitted to load_file().

---
Petr Mikulik

Re: test palette rgb

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

On Tuesday 25 November 2003 05:58, Petr Mikulik wrote:
> > <stdio.h>: FILE *tmpfile(void)
>
> Unfortunately this does not provide name of the file which I could use
> in plot 'tmp_file1'

You wouldn't need a file name if you wrote the data as an in-line command=
:
  plot '-'
  xx xx xx
  xx xx xx
  E
and then passed the FILE pointer directly to load_file().

So the code would look like:
=09pre1 =3D tmpfile();  data =3D tmpfile(); post1 =3D tmpfile();
=09fprintf(pre1, buf1);=09/* write preliminary commands */
=09fprintf(data, buf2);=09/* write inline data for plot */
=09fprintf(post1, buf3);=09/* write any trailing commands */
=09rewind(pre1); rewind(data); rewind(post1);
=09load_file(pre1, ...);
=09load_file(data, ...);
=09load_file(post1, ...);


> =09save set 'tmp_file2'

A similar trick should work here:
=09save_set(savefp=3Dtmpfile());
=09...
=09load_file(savefp, ...);


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

Re: test palette rgb

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

> >Unfortunately this does not provide name of the file which I could use in
> >	plot 'tmp_file1'
>
> An alternative if these temp files are not too big might be
> to slightly alter the "datafile.c" so that it doesn't necessarily
> need to read from a file stream but can instead read from
> some internal memory stream.  That way you could
> temporarily put memory on the heap and not have to deal
> with files...

It could e.g. read from internal memory, and also from shared memory.

Re: test palette rgb

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

> > Unfortunately this does not provide name of the file which I could use in
> > 	plot 'tmp_file1'
> > 	save set 'tmp_file2'
>
> Hmm... looks like the right answer would be "don't do that, then", in this
> case.  I.e. we may have to find a way to generate that test page without
> writing any files.  E.g. set up gnuplot a function per palette channel
> that the core can plot, instead of storing its values to a file.

That would need:

1. gnuplot can draw data from memory

2. gnuplot can save its current status of 'set' to recover from the current
temporary plot setting


Nb 2, alias "push and pop current set status" would be nice, but
unfortunately it is not so structured. For now, using temporary save help is
quite easy.

---
Petr Mikulik

Re: test palette rgb

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

Petr Mikulik wrote:

>>>Man page of tmpnam() and of tempnam() says:
>>>   Never use this function. Use mkstemp(3) instead.
>>>
>>>Is there any safe and portable way to create a file in a temporary
>>>directory, like /tmp or C:\TMP?
>>>      
>>>
>><stdio.h>: FILE *tmpfile(void)
>>    
>>
>
>Unfortunately this does not provide name of the file which I could use in
>	plot 'tmp_file1'
>	save set 'tmp_file2'
>

An alternative if these temp files are not too big might be
to slightly alter the "datafile.c" so that it doesn't necessarily
need to read from a file stream but can instead read from
some internal memory stream.  That way you could
temporarily put memory on the heap and not have to deal
with files...  or the equivalent, some type of mechanism to
generate an arbitrary function mapping points from one
set to another set that you can plot without having to use
a datafile but rather a function... or, could datafile.c be
rewritten so that the name of the file is not needed, just
the FILE *.  That is, there is already a special case '-'.
Maybe there is something simple to do there.

Dan

Re: test palette rgb

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

On Tue, 25 Nov 2003, Petr Mikulik wrote:

> > > Man page of tmpnam() and of tempnam() says:
> > >    Never use this function. Use mkstemp(3) instead.
> > >
> > > Is there any safe and portable way to create a file in a temporary
> > > directory, like /tmp or C:\TMP?
> >
> > <stdio.h>: FILE *tmpfile(void)
> 
> Unfortunately this does not provide name of the file which I could use in
> 	plot 'tmp_file1'
> 	save set 'tmp_file2'

Hmm... looks like the right answer would be "don't do that, then", in this
case.  I.e. we may have to find a way to generate that test page without
writing any files.  E.g. set up gnuplot a function per palette channel
that the core can plot, instead of storing its values to a file.

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

Re: test palette rgb

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

> > Man page of tmpnam() and of tempnam() says:
> >    Never use this function. Use mkstemp(3) instead.
> >
> > Is there any safe and portable way to create a file in a temporary
> > directory, like /tmp or C:\TMP?
>
> <stdio.h>: FILE *tmpfile(void)

Unfortunately this does not provide name of the file which I could use in
	plot 'tmp_file1'
	save set 'tmp_file2'

---
Petr Mikulik

Re: test palette rgb

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

Hans-Bernhard Broeker writes:
> On Tue, 25 Nov 2003, Petr Mikulik wrote:
> 
> > Man page of tmpnam() and of tempnam() says:
> >    Never use this function. Use mkstemp(3) instead.
> > 
> > Is there any safe and portable way to create a file in a temporary
> > directory, like /tmp or C:\TMP?
> 
> <stdio.h>: FILE *tmpfile(void)
> 
> It may not be particularly safe, but it's as portable as they come, being
> an ANSI/ISO C Standard Library function.  You get no control whatsoever
> about the directory it places the file in, though.
 
 It is quite difficult to do this portably and securly (avoiding races).
 It's probably best to create a temporary directory (mkdtemp() if available),
 chmod 700 it, and create all temp files in that directory. I've written
 some not terribly intelligent code like this for amavis.

Re: test palette rgb

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

On Tue, 25 Nov 2003, Petr Mikulik wrote:

> Man page of tmpnam() and of tempnam() says:
>    Never use this function. Use mkstemp(3) instead.
> 
> Is there any safe and portable way to create a file in a temporary
> directory, like /tmp or C:\TMP?

<stdio.h>: FILE *tmpfile(void)

It may not be particularly safe, but it's as portable as they come, being
an ANSI/ISO C Standard Library function.  You get no control whatsoever
about the directory it places the file in, though.

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

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

On Mon, 24 Nov 2003, Petr Mikulik wrote:

> ==30824== Invalid read of size 1
> ==30824==    at 0x4016371B: strlen (in /usr/lib/valgrind/valgrind.so)
> ==30824==    by 0x80E88BC: fontpath_handler (variable.c:519)

A similar bug seems to be in loadpath_handler, too, where it's easier
to trigger: just give the commands

	test pal
	test pal

in a fresh gnuplot session that does have a loadpath from the environment
($GNUPLOT_LIB is set), and the second one will cause a SIGSEGV in
loadpath_handler, in a line that's in exactly the same context as line
variable.c:519 which valgrind complained about:

(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080dae74 in loadpath_handler (action=16, path=0x0)
    at ../../src/variable.c:175
175                 p += strlen(p);
(gdb) l
170                 if (p < limit)
171                     return p;
172                 else
173                     return NULL;
174             } else {
175                 p += strlen(p);
176                 /* skip over '\0' */
177                 p++;
178                 if (p < limit)
179                     return p;

So the real problem obviously is that 'beenhere' wasn't reset to zero,
even though the state of 'p' suggests it has.

And the reason for that is pretty clear, too: fontpath_handler() and
loadpath_handler() both expect the caller to *always* do ACTION_GET until
it gets a NULL return.  The code in 'test palette' doesn't do that, and
thus it crashes.  The right fix would thus be to set 'beenhere' to zero
whenever p is NULLed, i.e. on each re-initialization of fontpath_handler()
or loadpath_handler, respectively.

Actually 'beenhere' serves no useful purpose anyway, as far as I can see.
Tests for it can be replaced by the condition (p != NULL), I think.

I'm checking in a fix along these lines.

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

Re: test palette rgb

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

Further, it was crashing in read-only directory. I've fixed that.

The problem is that it needs to write two temporary files ('save set', and
palette data). For that, I use mkstemp(). But this functions makes the file
in the current directory.

Man page of tmpnam() and of tempnam() says:
   Never use this function. Use mkstemp(3) instead.

Is there any safe and portable way to create a file in a temporary
directory, like /tmp or C:\TMP?

---
Petr Mikulik

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

On Monday 24 November 2003 07:22, Petr Mikulik wrote:
> There seems to be a bug in file
> =09variable.c
>
> Below is an ad-hoc fix -- and actually two possibilities of the fix.
> Does someone (Harald?) know what that code is doing and propose a
> correct fix?

This is a parallel case to the crash I was getting.
Mine was in loadpath_handler(), yours in fontpath_handler().
I make the correct fix to be the one given below, but I don't
know why this problem is only showing up now:

--- gnuplot/src/variable.c=092002-10-11 09:26:49.000000000 -0700
+++ gnuplot-eam/src/variable.c=092003-11-24 16:32:16.000000000 -0800
@@ -161,7 +161,7 @@
 =09FPRINTF((stderr, "Get loadpath\n"));
 =09if (!loadpath)
 =09    return NULL;
-=09if (!beenhere) {
+=09if (!beenhere || !p) {
 =09    /* init section */
 =09    beenhere =3D 1;
 =09    p =3D loadpath;
@@ -505,7 +505,7 @@
 =09FPRINTF((stderr, "Get fontpath\n"));
 =09if (!fontpath)
 =09    return NULL;
-=09if (!beenhere) {
+=09if (!beenhere || !p) {
 =09    /* init section */
 =09    beenhere =3D 1;
 =09    p =3D fontpath;


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

Re: test palette rgb

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

> So it is in cvs.

Works nicely the first time. =20
Crashes on the second.
Same behaviour seen for x11, png, and post terminal types

gnuplot> set term png font arial
Terminal type set to 'png'
Options are 'nocrop font arial 12 size 640,480 '
gnuplot> set output 'rgb.png'
gnuplot> test palette
smooth palette in png: available 157 color positions; using 157 of them
gnuplot> test palette

Program received signal SIGSEGV, Segmentation fault.
0x401ebbc3 in strlen () from /lib/i686/libc.so.6
(gdb) where
#0  0x401ebbc3 in strlen () from /lib/i686/libc.so.6
#1  0x080e8c67 in loadpath_handler (action=3D0, path=3D0x1 <Address 0x1 o=
ut of bounds>) at variable.c:175
#2  0x08092612 in save_set_all (fp=3D0x8212240) at save.c:837
#3  0x08090e08 in save_set (fp=3D0x80f6c3c) at save.c:100
#4  0x080536f8 in test_palette_subcommand () at command.c:1371
#5  0x08051e4a in command () at command.c:507
#6  0x080519b5 in do_line () at command.c:364
#7  0x080518d3 in com_line () at command.c:323
#8  0x08084e69 in main (argc=3D1, argv=3D0xbfffec74) at plot.c:609
#9  0x4018f082 in __libc_start_main () from /lib/i686/libc.so.6



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