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

Re: grid outside border

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

mi...@ph... wrote:

>>In Octave I've come across the a situation where the grid marks extend
>>a  slight bit beyond the right border.
>>    
>>
>
>I guess Octave has sent its "set grid" or "set tics" or "set xrange" into
>gnuplot, thus it draws grid far than gnuplot defaults.Try to graw('save "lookhere.gp"'); after the plot and reload that into
>fresh gnuplot.
>Petr
>  
>

I've done this.  There are 134 lines in the file, all kinds of commands 
that look like default settings.  However, the only line that seems to 
apply to all the gnuplot commands associated witht the freqz.m action is a

pl '/tmp/oct-ogH8L8' t "Phase (degrees)" w lines

I know gnuplot can save only the most recent plot command, but where all 
the "set multiplot", "set lmargin", etc. went I don't know.

I'll see if I can isolate this.

Dan

Re: grid outside border

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

Per Persson wrote:

>
> On Aug 5, 2004, at 08:51, Daniel J Sebald wrote:
>
>> In Octave I've come across the a situation where the grid marks 
>> extend a slight bit beyond the right border.  It happens for the 
>> terminals I've tried--x11, postscript, png.  Attached is a PNG file.  
>> I can't seem to reproduce this in gnuplot by itself, e.g., logarithm 
>> y axis, same margins, etc.  If this is not supposed to happen, I will 
>> add an entry to the SourceForge bug list.
>
>
> FWIW, I can't reproduce this using aquaterm as the terminal. (I guess 
> that the plot was created by octave's freqz() command?)
>
> octave 2.1.57 {gnuplot 4.0, recent CVS} and OSX 10.3.4


Yes.  Fairly recent CVS version.

Re: grid outside border

[Hans-Bernhard B. <hb...@pc...>]

On Thu, 5 Aug 2004, Daniel J Sebald wrote:

> In Octave I've come across the a situation where the grid marks extend a
> slight bit beyond the right border.

The problem is not the grid line --- it's in the right position, as you
can see by looking in the corners, where it meets the tick marks
quite nicely.

The problem is with the *border* line here.  It's in the wrong position,
by one pixel.  Normally, this would be caught automatically, because the
border lines are 2 pixels wide by default, on most terminals.

You really will have to isolate this into a stand-alone gnuplot script
to make it a worthwile target for further investigation.   I sincerely
hope octave leaves you a way of extracting the actual gnuplot commands
to a gnuplot script file (call gnuplot's "save" command, e.g.).

Re: grid outside border

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

> In Octave I've come across the a situation where the grid marks extend
> a  slight bit beyond the right border.

I guess Octave has sent its "set grid" or "set tics" or "set xrange" into
gnuplot, thus it draws grid far than gnuplot defaults.Try to graw('save "lookhere.gp"'); after the plot and reload that into
fresh gnuplot.
Petr

Re: grid outside border

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

On Aug 5, 2004, at 08:51, Daniel J Sebald wrote:

> In Octave I've come across the a situation where the grid marks extend 
> a slight bit beyond the right border.  It happens for the terminals 
> I've tried--x11, postscript, png.  Attached is a PNG file.  I can't 
> seem to reproduce this in gnuplot by itself, e.g., logarithm y axis, 
> same margins, etc.  If this is not supposed to happen, I will add an 
> entry to the SourceForge bug list.

FWIW, I can't reproduce this using aquaterm as the terminal. (I guess 
that the plot was created by octave's freqz() command?)

octave 2.1.57 {gnuplot 4.0, recent CVS} and OSX 10.3.4

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

grid outside border

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

In Octave I've come across the a situation where the grid marks extend a 
slight bit beyond the right border.  It happens for the terminals I've 
tried--x11, postscript, png.  Attached is a PNG file.  I can't seem to 
reproduce this in gnuplot by itself, e.g., logarithm y axis, same 
margins, etc.  If this is not supposed to happen, I will add an entry to 
the SourceForge bug list.

Dan

Re: [Gnuplot-info] linespoints with sparse points

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

On Tue, 3 Aug 2004, K.Moriyama wrote:

> I wonder why this feature has not included in gnuplot so far.
> when you plot several lines (e.g. calc. results) at once, 
> it may be hard to distinguish them, especially on a monochrome
> terminal or hard copy.
> 
> many other tools (e.g. kaleida graph) has a feature with which
> you can plot lines with points sparsely put along the lines,
> so that you can easily distinguish the lines.

I guess the main reasons such a feature doesn't exist yet are

1) It hasn't been requested strongly.

2) It's not strictly needed.  You can get essentially the same effect by
   plotting the dataset twice, once 'with points', and again 'with lines'
   using different 'every' modifiers for each.  A little fiddling with
   keys and line types will be needed, of course.

And please keep in mind that gnuplot-info is the user mailing list.
Suggestions of patches should really go to our development web site,
or the -beta mailing list.  I've Cc'ed that list for this reply.

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

New URLs for the UK Mirror Service

[The UK M. S. t. <mi...@mi...>]

Dear UK Mirror Service source site,

We're sending you this message because we currently mirror some of your
content, and any links you have to us will need updating. If you don't
currently list us as a mirror, please feel free to do so!

The resources we currently mirror from you are:
  gnuplot: ftp://ftp.ucc.ie/pub/gnuplot/

We used to operate from mirror.ac.uk; this has now been handed over to
Eduserv Internet, who will be running a new (unrelated) service from
there. We're pleased to announce that we will be continuing to provide
the UK Mirror Service from mirrorservice.org. If you currently have
download links pointing to a mirror of your site at mirror.ac.uk, please
update these to point at mirrorservice.org instead. For example, if your
old URLs were:

  http://www.mirror.ac.uk/sites/ftp.example.com/pub/example/
  ftp://ftp.mirror.ac.uk/sites/ftp.example.com/pub/example/
  rsync://rsync.mirror.ac.uk/ftp.example.com/pub/example/

then they will now need to be:

  http://www.mirrorservice.org/sites/ftp.example.com/pub/example/
  ftp://ftp.mirrorservice.org/sites/ftp.example.com/pub/example/
  rsync://rsync.mirrorservice.org/ftp.example.com/pub/example/
    (note that there's no /sites/ in the rsync URL)

Your content will be available by default using all three protocols. (If
you don't want this, let us know.) Our web interface allows users to
browse inside archives and ISO images.

If you want a symlink in /pub/ pointing to your content so
ftp.mirrorservice.org can be used in an FTP round-robin, please let us
know. (These are already in place for some sites.) If you have DNS
CNAMEs pointing at mirror.ac.uk addresses, these will also need to be
updated to point to the corresponding mirrorservice.org addresses.

The mirrorservice.org hosts are located at the University of Kent in
Canterbury, Kent, United Kingdom, which has a 155Mbit link to the rest
of the world (due to be upgraded to 1Gbit in the near future).

Mirroring is performed as before from the IPv4 addresses
212.219.56.140 (compton.mirrorservice.org) and 212.219.56.132
(palomar.mirrorservice.org).

Please contact us at <mi...@mi...> if you have any
questions.

Thanks,
The UK Mirror Service team
<mi...@mi...>
<http://www.mirrorservice.org/>

Re: Plot placement, revisited

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

On Tue, 27 Jul 2004, Daniel J Sebald wrote:

> Do you want to fix this first in the code independent of what I'm doing? 

Yes.  It's not important enough to warrant being backported to 4.0,
but I'll fix it in 4.1 right now --- I'll just move the gp_alloc inside
the 'case' that uses it.


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

Re: key and patches

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

Ethan Merritt wrote:

>On Thursday 29 July 2004 02:36 am, Daniel J Sebald wrote:
>  
>
>> There is a demo called 'key.dem' which will immediately give you the 
>>idea of how auto/manual positioning works.
>>    
>>
>
>Dan:
>
>The last 9 tests in your demo do not work right for me,
>or at least they don't act as I assume they are supposed to.
>Starting with "set key -5,1 right top title "(-5,1) right top"
>the key ends up somewhere near the left-hand vertical center
>of the plot, offset by a small amount from plot to plot but basically
>in the same place.
>
>Do you need a copy of the output?
>
>
>(for what it's worth, this is without having applied the with_pixels
>patch. I don't see why that would make a difference though)
>

I didn't know the patches would work independently, but shouldn't 
matter.  In any case, I think what you are seeing may be what it's 
programed to be.  The key should be "rotating" about the position (-5,1) 
with the various alignments.  Would it help to have crosshairs at the 
point (-5,1)?  (I'll send PNG examples.)...  I can see the behavior may 
not match as expected; 'left', 'right', etc. take on slightly different 
meaning based on the presence of <position>.

Dan

Re: key and patches

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

On Thursday 29 July 2004 02:36 am, Daniel J Sebald wrote:
> 
>  There is a demo called 'key.dem' which will immediately give you the 
> idea of how auto/manual positioning works.

Dan:

The last 9 tests in your demo do not work right for me,
or at least they don't act as I assume they are supposed to.
Starting with "set key -5,1 right top title "(-5,1) right top"
the key ends up somewhere near the left-hand vertical center
of the plot, offset by a small amount from plot to plot but basically
in the same place.

Do you need a copy of the output?


(for what it's worth, this is without having applied the with_pixels
patch. I don't see why that would make a difference though)

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

Re: gnuplot not license-compatible with GPL software

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

On Thursday 29 July 2004 05:25 am, Roland Stigge wrote:
> Hi,
> 
> while I understand that the name gnuplot is independent from the GNU
> project or the FSF, I find it annoying that through a different license,
> I'm not allowed to link this software with GPL programs, most
> importantly, with GNU readline.

To the best of my knowledge, Debian is the only entity that interprets
the respective licenses in such a way as to avoid using the gnu readline
library with gnuplot.   I have argued in the past that this is a mistaken
interpretation of the GPL; nobody at that end seems to care.
Yeah, I know - I am not a lawyer.  But that doesn't mean I'm wrong :-)

In a nutshell:  
gnuplot is not a derivative work of libreadline.
The gnuplot source code does not contain any part of gnu libreadline.
gnuplot provides its own readline function, and can be used totally
independent of gnu libreadline.

The question would be moot if gnu libreadline were LGPL rather
than GPL, but that is an issue you would have to take up with them,
not with us.

In any event, Debian's refusal to package up a pre-built version
of gnuplot that links to a shared libreadline does not in any way stop you
from building your own copy linked against whatever libaries you like.
The GPL does not limit your own use of the code; it only imposes
restrictions on the conditions under which you may distribute the
result.

So download the source, configure with
	./configure --with-readline=gnu
and be happy

> Please consider issuing gnuplot under the GPL.

It is my personal opinion that the GPL is not a good license for
academic or scientific software.  My opinion matters very little,
because I am only one of many people who have contributed to
gnuplot over the years.  But if you multiply my reservations by
50 or so, to account for the larger group of contributers to the
project, you will begin to see why changing the license would
be difficult.

> Thank you very much!
> 
> Roland Stigge

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

Re: gnuplot not license-compatible with GPL software

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

On Thu, 29 Jul 2004, Roland Stigge wrote:

[...]
> I find it annoying that through a different license,
> I'm not allowed to link this software with GPL programs, most
> importantly, with GNU readline.

You, me, and a lot of others.  But the holders of the gnuplot copyright
(who are no longer involved in active development, and indeed haven't been
in a *long* time) refuse to switch to GPL.  We've tried a couple times,
and even RMS himself has (allegedly?) tried.  Nothing gave.

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

Re: Plot placement, revisited

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

On Thursday 29 July 2004 07:42 am, mi...@ph... wrote:
> However, is there a color number for background? I.e.
>    set key opaque color lt -2
> or like that?

Yes, at least partially.

I went through prior to the version 4.0 release and made
many terminals honor LT_BACKGROUND (-2) when setting
a color.  But I could not check all the terminals, and I did not
add it to the documentation because the work was not complete.
Please feel free to go ahead and test this on os2, windows,
and the various other terminal types I can't test easily.
 
> I think I was stucked several times not being able to draw a label in the
> background colour. I wish this number gets introduced (it may need
> transfer of the knowledge from terminal to gnuplot).

I had vague ideas of making "background" or "bkg" a legal 
linetype specifier, since that is more obvious than saying
    plot 'data' with boxes lt bkg
than
    plot 'data' with boxes lt -2

But is it worth changing the syntax in every command
that accepts line type?



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

Re: Plot placement, revisited

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

> Then, the box feature of key could have an option of "transparent |
> opaque" with the obvious behavior.

I would like this option. It could be
     set key transparent     ... the current, default
     set key opaque [color ...]

where color specs are those as for labels.

However, is there a color number for background? I.e.
   set key opaque color lt -2
or like that?

I think I was stucked several times not being able to draw a label in the
background colour. I wish this number gets introduced (it may need
transfer of the knowledge from terminal to gnuplot).
---
PM

gnuplot not license-compatible with GPL software

[Roland S. <st...@de...>]

Hi,

while I understand that the name gnuplot is independent from the GNU
project or the FSF, I find it annoying that through a different license,
I'm not allowed to link this software with GPL programs, most
importantly, with GNU readline.

Please consider issuing gnuplot under the GPL.

Thank you very much!

Roland Stigge

key and patches

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

I've cleaned up some of the layout code motivated by better control of 
key placement.  It wasn't too bad.  Basically, it was the layout and 
positioning of the key that was a hodge-podge of case statements here 
and there.  After organizing some things a bit more, there seems to have 
been a few bits of cruft in there.  (I.e., code setting variables that 
weren't used before being set to something else.)

I think it is a good start and you will probably like it.  With left, 
right, center, top, bottom one can choose one of 9 automatic locations 
either inside or outside of the graph boundary.  The words "outside" and 
"under" aren't quite backward compatible, but they are very close to 
compatible.  The <position> has been enhanced in that 'left', 'right', 
'center', 'bottom', 'top' control the alignment with respect to the 
point.  (Think of the key as a gnuplot label.)  However, issuing one of 
those position keywords without the <position> will cause the key to go 
back to automatic mode.  (Again, darn near backward compatible.)  The 
mods only apply for 2d plots.  3d plot key layout should be discussed 
before making any changes.  There is some command-line documentation. 
 There is a demo called 'key.dem' which will immediately give you the 
idea of how auto/manual positioning works.

The patches are on SourceForge.  If you want to try, the order of patch 
application would be:

key_28jul2004.patch     (cleaner enumerations but unaltered gnuplot 
behavior)
with_image_29jul2004.patch
add_key_29jul2004.patch

Fair warning:  Don't take this as too crass, but I won't be updating 
these patches anymore beyond the near future.

Dan

Re: Code questions (strings and other things)

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

On Wednesday 28 July 2004 12:27 am, Hans-Bernhard Broeker wrote:

> >[use of malloc() rather than gp_malloc() in gnuplot proper is a bug] 
> > getcolor.c in particular is an offender in this regard.
> 
> Caution, there.  getcolor.c gets compiled into gnuplot_x1.c, too.

If necessary, gnuplot_X11.c provide something like
(void *) gp_alloc(x,y) {malloc(x)}

> Evaluation shouldn't be necessary --- but parsing the expression will be.
> That's why I at one point suggested the
> 
> 	''+{rest of expression}
> 
> hack.  It starts off with a string literal, so isstring() will
> recognize it

That doesn't solve the problem of user-defined functions.

S1 = "+{some expression based on x}
S2 = "+{some other expression based on y}
sfunc(x,y) = S1(x)+S2(y)

The current structures for storing function evaluation chains
do not provide a place to store the information that sfunc()
was generated from string-valued functions.  So when you hit
a command like

	splot sfunc(1,2) using 1:2:3

there is no way for the parsing code to figure out that 
sfunc(1,2) specifies a data file name (maybe "dataset_1.run2")
rather than a numerical function.  That is the specific problem I am
stuck on at the moment.   

The only way out I have come up with so far is to peek ahead
in the command line to see that there is a "using <foo>" component.
This would only be legal if it is a plot in data mode rather than
function mode.  But currently the "using" spec is not mandatory,
so failing to find one does not rule out a data plot.

Would it be acceptable to solve this problem by saying
"if the file name is not a string constant, then a 'using' specification
is required"?

> How about cloning const_express and having the copy return an error code
> rather than bailing out by itself?

const_express by itself does nothing but trigger the expression
evaluation code and then return the result.   The int_error() messages
come from deep inside the expression evaluation recursion.
In particular the problem comes from commands like
	plot func(x) using lines

If "x" were a constant, then func(x) would either return a number or
a string and the parsing code could tell what to do in either case.
But since "x" is a dummy variable, the evaluation code issues int_error
with the message
	undefined variable: x

I need to look harder at the code that implements "show at {expression}".
It is possible that this code could be modified to trace the data type 
through to the final output type.

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

Re: Code questions (strings and other things)

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

>> 
>> In what sense do you mean the memory use code dies dramatically?
>
> If you enable CHECK_HEAP_USE, then gnuplot redefines  free()
> to be an internal function 
> 	# define free(x) checked_free(x)
>
> gp_alloc() allocates extra space and puts a checksum in the allocated
> chunk of memory, which is checked when it is freed.
> If the chuck was allocated directly with malloc() rather than gp_alloc()
> then it doesn't contain this padding, and the attempt to validate this
> "extra" space in the allocated chunk produces a segfault.
>
>> PS:  Why isn't gpfree, gp_free; consistent with gp_alloc, etc.?
>
> I wondered that as well.
>

It was a long time ago, but my guess is I was looking for some
particular leak or scribble, and the code was already using a
gp_alloc() wrapper, but was using free() directly. As a quick hack,
redefining free() was enough for what I was trying to do.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Plot placement, revisited

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

On Tue, 27 Jul 2004, Daniel J Sebald wrote:

> Since on the subject of plot/key placement.  I notice there is a bit of 
> code for making the plot grid avoid the key box so that the lines don't 
> interfere with what is in the key.  That is good.  However, notice that 
> the same isn't done for the plot curves.  Those will write in the same 
> space as the key.  I wonder if the plot lines as well should not 
> interfere with the key.

I've discussed this with users occasionally, and came to the opinion that
the data are more important than the key ---- in a scientific plotting
program, data is king, all else is secondary.  I.e. if the key falls right
in the middle of a data set, it's the key that should yield, not the data.

As to actively blanking out the key box area --- that's going to be
trickier than you think.  IIRC the key is output intermixed with the data,
so there is currently not point during the execution of a multi-dataset
'plot' command at which all data is drawn, but none of the key.

Splitting that up would be another rather major reorganization.

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

Re: Code questions (strings and other things)

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

On Tue, 27 Jul 2004, Ethan Merritt wrote:

> Any insight on the following questions?
> 
> util.c:
> ======
> The routines os_error() and int_error() are identical
> except for some VMS-specific conditional code in os_error() 

That conditional is not really VMS-specific. The real difference is
right in the #else branch of that: the perror() call. 

In a nutshell: os_error is used to report errors detected by the OS (i.e.
decode errno to a readable message and show it), int_error is for error
conditions internal to gnuplot.

> gp_alloc()
> ==========
> I assume the intent is to use this function everywhere
> rather than to use malloc() directly. 

Well, everywhere in the code that goes into gnuplot itself.  gplt_x11.c
and the other platform-specific drivers don't use it.

> So is it correct that all uses of malloc() are bugs?

Essentially yes.


> getcolor.c in particular is an offender in this regard.

Caution, there.  getcolor.c gets compiled into gnuplot_x1.c, too.

> Should the guidelines in CodeStyle mention this restriction?

Yes.

> How to re-work isstring()?
> ========================
> This question arises in connection with adding support
> for string variables, and in particular for string-valued
> functions.
> 
> Right now, the routine isstring() checks for the next
> character of the input line being either a single quote
> or a double quote.
> 
> Several people have suggested extending this to test
> for a string constant (current code already does this),
> a user-defined variable containing a string (this is easy)
> or an expression returning a string.
> 
> This last case is driving me nuts.  I cannot figure out how
> to determine the return type of an expression without
> evaluating it. 

Evaluation shouldn't be necessary --- but parsing the expression will be.
That's why I at one point suggested the

	''+{rest of expression}

hack.  It starts off with a string literal, so isstring() will
recognize it.

> But in too many cases, trying to evaluate
> the next token on the input line using const_express()
> triggers int_error() rather than returning.  Any ideas?

How about cloning const_express and having the copy return an error code
rather than bailing out by itself?

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

Re: Code questions (strings and other things)

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

> 
> In what sense do you mean the memory use code dies dramatically?

If you enable CHECK_HEAP_USE, then gnuplot redefines  free()
to be an internal function 
	# define free(x) checked_free(x)

gp_alloc() allocates extra space and puts a checksum in the allocated
chunk of memory, which is checked when it is freed.
If the chuck was allocated directly with malloc() rather than gp_alloc()
then it doesn't contain this padding, and the attempt to validate this
"extra" space in the allocated chunk produces a segfault.

> PS:  Why isn't gpfree, gp_free; consistent with gp_alloc, etc.?

I wondered that as well.


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

Re: Code questions (strings and other things)

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

Ethan Merritt wrote:

>gp_alloc()
>==========
>I assume the intent is to use this function everywhere
>rather than to use malloc() directly.  Without this
>restriction, gnuplot's memory use code in alloc.c dies
>dramatically if you use the free() macro.
>So is it correct that all uses of malloc() are bugs?
>getcolor.c in particular is an offender in this regard.
>Should the guidelines in CodeStyle mention this restriction?
>

In what sense do you mean the memory use code dies dramatically?  The 
gp_alloc() routine could be made a definition or a function, e.g., in 
alloc.h define

#if USE_MEMORY_CHECK
    generic *gp_alloc __PROTO((size_t size, const char *message));
    generic *gp_realloc __PROTO((generic *p, size_t size, const char 
*message));
    void gpfree __PROTO((generic *p));
    #define alloc <some kind of error macro saying "use gp_alloc">
    #define realloc <some kind of error macro saying "use gp_realloc">
    #define free <some kind of error macro saying "use gpfree">
#else
    #define gp_alloc alloc
    #define gp_realloc realloc
    #define gpfree free
#endif

That will force developers to use gp_alloc consistently, but users--who 
likely won't know how to use gp_alloc--can leave that code out.

Dan

PS:  Why isn't gpfree, gp_free; consistent with gp_alloc, etc.?

Re: Plot placement, revisited

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

Since on the subject of plot/key placement.  I notice there is a bit of 
code for making the plot grid avoid the key box so that the lines don't 
interfere with what is in the key.  That is good.  However, notice that 
the same isn't done for the plot curves.  Those will write in the same 
space as the key.  I wonder if the plot lines as well should not 
interfere with the key.

That breaking up of the grid lines seems like a low level function to 
me.  An alternate method of achieving a similar effect is to allow the 
grid lines and plot lines to be drawn, but then put the key over the top 
by first drawing a rectangular filled polygon to cover up or "erase" 
whatever is on the plot.  This scheme works for PostScript I'm sure.  It 
seems like X11 should work as well.  How about the other terminals like 
PDF, JPEG, etc.?  A filled polygon is probably a tad slower at the 
driver level than would be truncating the grid/plot lines, but not too 
noticeable I'd think.

Then, the box feature of key could have an option of "transparent | 
opaque" with the obvious behavior.  I think that would actually simplify 
the gnuplot code.  For example, as part of this

    /* Calculate space for keys to prevent grid overwrite the

is a comment

/* FIXME!!!
** pm 22.1.2002: if key->user_pos.scalex or scaley == first_axes or 
second_axes,
** then the graph scaling is not yet known and the box is positioned 
incorrectly;
** you must do "replot" to avoid the wrong plot ... bad luck if output 
does not
** go to screen */

Would a scheme like I describe get rid of this problem?

Are there situations where no grid lines yet the data/traces fall inside 
the key?  Could that be accomplished with some additional option, e.g., 
plot all of these is some specifiable... if that's a word... order or 
"depth", e.g., "set key box opaque 1" (default)

3. grid lines
2. plots (covers grid lines)
1. key (covers grid lines and plots)

or "set key box opaque 2"

1. grid lines
2. key (covers grid lines)
3. plots (covers grid lines and key)

or "set key box opaque 3" (same as "set key box transparent")

Thoughts?

Dan

Code questions (strings and other things)

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

Any insight on the following questions?

util.c:
======
The routines os_error() and int_error() are identical
except for some VMS-specific conditional code in os_error() 
and a call to PRINT_SPACES_UNDER_PROMPT in os_error() 
instead of a newline in int_error().

Do we really need both routines?  What is the intended
use of os_error() as opposed to int_error()?

gp_alloc()
==========
I assume the intent is to use this function everywhere
rather than to use malloc() directly.  Without this
restriction, gnuplot's memory use code in alloc.c dies
dramatically if you use the free() macro.
So is it correct that all uses of malloc() are bugs?
getcolor.c in particular is an offender in this regard.
Should the guidelines in CodeStyle mention this restriction?


How to re-work isstring()?
========================
This question arises in connection with adding support
for string variables, and in particular for string-valued
functions.

Right now, the routine isstring() checks for the next
character of the input line being either a single quote
or a double quote.

Several people have suggested extending this to test
for a string constant (current code already does this),
a user-defined variable containing a string (this is easy)
or an expression returning a string.

This last case is driving me nuts.  I cannot figure out how
to determine the return type of an expression without
evaluating it. But in too many cases, trying to evaluate
the next token on the input line using const_express()
triggers int_error() rather than returning.  Any ideas?

SIde Note:   I did not add any special code to generate
string-valued user-defined functions.   As soon as even
one type of expression evaluates to a string, the existing
code generates them automatically in response to a
command like:
    myfunc(x) = <expression returning string>
e.g.
    f1(x) = "constant"
    f2(x) = sprintf("fmt",var)
    f3(x) = f1(x)+f2(x)

So, if we decide *not* to allow user-defined 
string functions, we still need a way to detect that
a function returns a string if only so we can forbid
someone to use it in a function definition.
In other words, this doesn't necessarily make the
problem of detection go away.



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