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