gnuplot-beta

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>]

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

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: 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: 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