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

Re: Plot placement, revisited (memory leak)

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

Daniel J Sebald wrote:

> Ethan Merritt wrote:
>
>> I quite agree with you that the current setup has lots of problems.
>> I thought a bit about trying to introduce explicit code to control the
>> number of rows and columns. Then I looked at the code and shuddered.
>>
>
> Now I see what you are saying.  There is code for the key all over 
> "graphics.c". 


And also graph3d.c has some of the similar code replicated... not good.

The "show key" may have a memory leak.  There is a magic number for 
memory allocation:

    char *str = gp_alloc(30, "show_key");

and, actually, the fact the string gets pumped to stderr means there 
really isn't any need for "str".  Anyway, the above allocation is done 
*every* time the routine is entered.  But the free is only done 
conditionally on KEY_AUTO_PLACEMENT.

I created a script file with "show key" repeated several times. 
 Watching system memory, when KEY_AUTO_PLACEMENT is active, loading that 
file does nothing to system memory.  But after "set key 30,30", calling 
said script file builds up system memory.

Dan

Re: Plot placement, revisited

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

Ethan Merritt wrote:

>I quite agree with you that the current setup has lots of problems.
>I thought a bit about trying to introduce explicit code to control the
>number of rows and columns. Then I looked at the code and shuddered.
>

Now I see what you are saying.  There is code for the key all over 
"graphics.c".

And I think I see why the "set key below" always causes space removed 
irregardless of the "bmargin" setting.  It isn't conditioned the way 
"set key out" and "rmargin" is, ie for TOUT it's

    if (rmargin < 0) {
<snip>
      /* adjust for outside key */
      if (key->flag == KEY_AUTO_PLACEMENT && key->hpos == TOUT) {
          xright -= key_col_wth * key_cols;
          keybox.xl = xright + (int) (t->h_tic);
      }
<snip>
    } else

but for TUNDER, it's

    if (key->flag == KEY_AUTO_PLACEMENT) {
        if (key->vpos == TUNDER) {
<snip>
        ybot += key_entry_height * key_rows + (int) ((t->v_char) * 
(ktitl_lines + 1));
        ybot += (int)(key->height_fix * (t->v_char));
        } else {
<snip>
    }

Dan

Re: Plot placement, revisited

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

Hans-Bernhard Broeker wrote:

>On Fri, 23 Jul 2004, Daniel J Sebald wrote:
>
>  
>
>>If you recall, there was a discussion of precisely controlling the size 
>>of a plot.  It concerned how labels would take away space from the plot 
>>so that the eventual size of the borders was random, or at least not 
>>known to the user.  The solution was to set the margins to 0, for which 
>>the values specified in "size" matched the borders of the plot. 
>>    
>>
>
>Not quite.  You just have to set the margins to value other than the
>default, so gnuplot doesn't auto-size them.  It doesn't strictly have to
>be zero.
>

Oh.  I didn't know that.  Or I did but didn't make the connection. 
 There is still a bit of uncertainty, isn't there?  If I specify the 
margin to 1, for example, I'm not sure what the character height is in 
terms of plot units.  Hence, subtract that unknown quantity from the 
plot size and the size ends up with some uncertainty.


>>But there is a similar situation with the key.  When the key is 
>>specified as "below", that uses up space, so again "set size X,Y" is no 
>>longer the precise size of the borders. 
>>    
>>
>
>It is, if you set bmargin to a value large enough to let the key fit
>below the graph.
>

That isn't the behavior I see.  No matter what value of bmargin I use, 
the height of the plot becomes shorter when "set key below" is used. 
 The uncertainty could be dealt with if a key and margin were similar 
between the multiplots.  But in this case I only want a key for the 
bottom plot.

>That said, I like the suggestion.  But for now, we're not quite done with
>the "with pixels" stuff yet, are we?  I think that should take priority
>now.
>

Yeah.  (Just got ants in my pants to finish something.)  I recently 
checked that all the hunks in the image patch still work with CVS.

Dan

Re: Plot placement, revisited

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

On Fri, 23 Jul 2004, Daniel J Sebald wrote:

> If you recall, there was a discussion of precisely controlling the size 
> of a plot.  It concerned how labels would take away space from the plot 
> so that the eventual size of the borders was random, or at least not 
> known to the user.  The solution was to set the margins to 0, for which 
> the values specified in "size" matched the borders of the plot. 

Not quite.  You just have to set the margins to value other than the
default, so gnuplot doesn't auto-size them.  It doesn't strictly have to
be zero.

> But there is a similar situation with the key.  When the key is 
> specified as "below", that uses up space, so again "set size X,Y" is no 
> longer the precise size of the borders. 

It is, if you set bmargin to a value large enough to let the key fit
below the graph.

That said, I like the suggestion.  But for now, we're not quite done with
the "with pixels" stuff yet, are we?  I think that should take priority
now.

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

Re: Plot placement, revisited

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

Ethan Merritt wrote:

>On Friday 23 July 2004 12:09 pm, Daniel J Sebald wrote:
>  
>
>>It would be nice to be able to control the "max no cols" vs. "max no 
>>row" independent of the autoplacement.  As it stands, there is no 
>>"above" autoplacement, only "below";  and there is the using up space 
>>issue I've mentioned.
>>    
>>
>
>I quite agree with you that the current setup has lots of problems.
>I thought a bit about trying to introduce explicit code to control the
>number of rows and columns. Then I looked at the code and shuddered.
>

Just a bit disorganized, I think.  Not too bad.

>Then I thought some more and decided that a better goal was to
>work toward generalizing the setup in a different way.  I started by
>moving all the key-specific data into a single structure, with the idea
>that one could then support multiple keys.
>

I thought of the multiple keys thing too.  Not how to do it, but the 
possibility of doing it.


>  Rather than trying to 
>control the column layout with a key, you would instead assign
>half the plots, say, to one key box and the other half to a second
>key box.   Each box could be separately positioned in x and y.
>It would look to the user something like
>
>	set key 1 title "First Half" at x1, y1
>	set key 2 title "The Rest" at x2, y2
>	plot 'data' u 1:2 key 1 title "whatever, \
>                    '' u 1:3 key 2 title "whatever"
>
>and so on.
>
>I never got any further than that in coding, but anyway that's my
>suggestion as to what we might aim for.
>

You are directing, then, which key the signal should go into.  I like 
that.  That sort of fits the general philosophy of gnuplot.

Walking across town, I've sort of concluded that keywords 
"horizontal/vertical" would be more appropriate than "maxcols/maxrows". 
 I'll attempt a simple patch to introduce these keywords.  Not a full 
implementation, but something that at least allows me to manually 
position a horizontal key so I can finish the plot I'm after.

Dan

Re: Plot placement, revisited

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

On Friday 23 July 2004 12:09 pm, Daniel J Sebald wrote:
> 
> It would be nice to be able to control the "max no cols" vs. "max no 
> row" independent of the autoplacement.  As it stands, there is no 
> "above" autoplacement, only "below";  and there is the using up space 
> issue I've mentioned.

I quite agree with you that the current setup has lots of problems.
I thought a bit about trying to introduce explicit code to control the
number of rows and columns. Then I looked at the code and shuddered.

Then I thought some more and decided that a better goal was to
work toward generalizing the setup in a different way.  I started by
moving all the key-specific data into a single structure, with the idea
that one could then support multiple keys.  Rather than trying to 
control the column layout with a key, you would instead assign
half the plots, say, to one key box and the other half to a second
key box.   Each box could be separately positioned in x and y.
It would look to the user something like

	set key 1 title "First Half" at x1, y1
	set key 2 title "The Rest" at x2, y2
	plot 'data' u 1:2 key 1 title "whatever, \
                    '' u 1:3 key 2 title "whatever"

and so on.

I never got any further than that in coding, but anyway that's my
suggestion as to what we might aim for.


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

Plot placement, revisited

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

If you recall, there was a discussion of precisely controlling the size 
of a plot.  It concerned how labels would take away space from the plot 
so that the eventual size of the borders was random, or at least not 
known to the user.  The solution was to set the margins to 0, for which 
the values specified in "size" matched the borders of the plot.  That 
worked fine.

But there is a similar situation with the key.  When the key is 
specified as "below", that uses up space, so again "set size X,Y" is no 
longer the precise size of the borders.  There is an option for 
specifying the location of the key, "set key x,y", which does not use up 
space.  That would work, but unfortunately there seems no way to 
independently control "maximize number of columns" vs. "maximize number 
of rows".  Instead, here is the control structure within the code:

    if (key->flag == KEY_AUTO_PLACEMENT) {
        if (key->vpos == TUNDER) {
            /* maximise no cols, limited by label-length */
        } else {
            /* maximise no rows, limited by ytop-ybot */
        }
    }

It would be nice to be able to control the "max no cols" vs. "max no 
row" independent of the autoplacement.  As it stands, there is no 
"above" autoplacement, only "below";  and there is the using up space 
issue I've mentioned.

Depending upon the interior lines of the plot, someone might even want 
to have a "maximize no cols" and place it somewhere within the borders. 
 So, I would argue for making these independent.  That is, perhaps a 
"maxcols"/"maxrows" key word.  Imagine there were independent keywords

right, left, center, bottom, top
maxcols, maxrows
inside, outside

The first set of keywords would control the 9 possible "default" locations.

1 2 3
4 5 6
7 8 9

1 - left top
2 - top center
3 - top right
4 - left center
5 - center
6 - right center
7 - bottom left
8 - center bottom
9 - right bottom

(#5 seems like a goofy choice, but so be it.)

Also, the same combinations make sense no matter if you say 
independently "outside" versuse "inside".  Same for "maxcols" vs. "maxrows".

Then, in one sense, the current keywords "outside" and "below" actually 
have multiple meaning.  "outside" really means "outside, right/center, 
maxrows"; "below" really means "outside, bottom/center, maxcols".

Dan

Re: Visual basic Interface

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

On Thu, 22 Jul 2004, Justace Clutter wrote:

> I think that a starting point can also be the kile application. 

If he were on Linux, that would be a useful way to start off.  But not on
MS Windows, where gnuplot works rather differently from Unix/X11 builds.

MS Windows doesn't subscribe to the concept of GUI applications having a
connection to a command line (standard input/output channels) --- like
gnuplot running in an xterm (or piped to a controlling application), and
gnuplot_x11 does the graphical I/O.

That's where pgnuplot.exe comes in.  It's a console app, so it can
be run via pipes.  It then runs an instance of the normal windows
gnuplot and feeds all the characters arriving at its stdin to the
message queue of wgnuplot.

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

Re: Visual basic Interface

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

Justace Clutter wrote:

>I think that a starting point can also be the kile application.  There
>is a gnuplot interface there.  It is done in QT for linux but I am sure
>that it can be somewhat instructive.  You could also just write a
>frontent for it to create a gnuplot command list and then pipe that to
>an instance of gnuplot.  That will save you from a lot of low level
>stuff.
>  
>

Justace,

Please explain what kile and QT are.  This rentor98 may be a newbie... 
like myself.  I gather what you are saying is that this person may want 
to seek out similar applications to Excel but for which there is plenty 
of documentation available about building the software?

My advice is to heed Hans' warning.  My experience with low-level stuff 
on a Microsoft platform is frustration.  First, I got sucked in, 
thinking "oh all I need do is modify this or that and then ba-da-bing". 
 But then I got to the point of having to interface with drivers and 
DLLs.  Some frustrating system errors for legitimate reasons like parity 
failures, or what not.  So then I thought I could go to Microsoft's web 
site and get the tools to recompile a driver.  That lead to lots of 
searching and when I found something that looked applicable, I had a zip 
file full of so many files I didn't know where to start.  It's as though 
you can't dip your toes in the water, you have to become an all out 
Microsoft developer.

In my case I then sought out solutions in linux.  I learned a lot about 
launching subprocesses, building and installing drivers, low level I/O, etc.

Dan

Re: Visual basic Interface

[Justace C. <pro...@co...>]

I think that a starting point can also be the kile application.  There
is a gnuplot interface there.  It is done in QT for linux but I am sure
that it can be somewhat instructive.  You could also just write a
frontent for it to create a gnuplot command list and then pipe that to
an instance of gnuplot.  That will save you from a lot of low level
stuff.

Justace

On Thu, 2004-07-22 at 18:11, Hans-Bernhard Broeker wrote:
> On Thu, 22 Jul 2004 ren...@ya... wrote:
> 
> > I want to build an interface with Visual basic 6.0 for
> > a project in my school.
> 
> I'm not sure you'll be up to this unless you have some
> serious lower-level programming experience with Windows.
> 
> Get yourself the gnuplot sources, and look at the source to the
> pgnuplot.exe program.  If you don't understand what you see there, odds
> are you won't be able to pull this off.

Re: Visual basic Interface

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

On Thu, 22 Jul 2004 ren...@ya... wrote:

> I want to build an interface with Visual basic 6.0 for
> a project in my school.

I'm not sure you'll be up to this unless you have some
serious lower-level programming experience with Windows.

Get yourself the gnuplot sources, and look at the source to the
pgnuplot.exe program.  If you don't understand what you see there, odds
are you won't be able to pull this off.

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

Re: simultaneous GIF and PNG support

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

On Thu, 22 Jul 2004, Ethan Merritt wrote:

> For the 4.1 development I think that we should
> feed 'set term gif' through the new driver also.

Agreed.  With GIF support back in current libgd, the old gif.trm is no
longer needed for anything, so it may as well be ditched.

> But what about the 4.0.<finalpatch> source?

4.0 is supposed to be a stable branch.  I.e. only bug fixes and 
desperately needed new features.  I say we wait for user feedback
to decide if they want GIF badly enough to warrant porting such
changes over from 4.1 to 4.0.

> Oh, and there's another annoyance.  Pattern-fill broke in libgd version
> 2.0.27 and it's still broken in 2.0.28.  

Does Tom Boutell know about that?

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

Re: Question on debugging memory use

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

On Thu, 22 Jul 2004, Ethan Merritt wrote:

> The existence of the routine gp_alloc(mem,"tag label") suggests that
> some such facility was intended, but since there is no corresponding
> routine gp_free I don't see how to use it for this purpose.  

There is a checked_free() instead, and free() is defined to it.  See
alloc.h:67

# define free(x) checked_free(x)

> Is there some clever way of asking for a dump of the currently
> allocated memory chunks?  

I don't think so.  But feel free to inspect alloc.c for yourself.

In a nutshell, all it should take is to compile with CHECK_HEAP_USE
defined, and you'll get a report if anything goes wrong.  OTOH, it's
usually quite a bit easier to use existing external tools for this.  E.g.
valgrind, or glibc's malloc() debugging facilities. ElectricFence should
suffice, too.

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

simultaneous GIF and PNG support

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

The following note now appears on Tom Boutell's web site:

07/21/04: gd 2.0.28 has been released. gd 2.0.28 restores support
for reading and writing GIF images. There is also a fix for a possible 
problem in gdImageTrueColorToPalette.


And, in fact, after installing gd 2.0.28 gnuplot will configure
itself to support GIF, PNG, and JPEG through the gd library.

However, our conditional code sets up GIF output through the
old gif.trm rather than the new gd.trm, so many new features
are not supported.   

For the 4.1 development I think that we should
feed 'set term gif' through the new driver also.

But what about the 4.0.<finalpatch> source?


Oh, and there's another annoyance.  
Pattern-fill broke in libgd version 2.0.27 and it's still broken
in 2.0.28.  So for the moment you must trade off gif support
for pattern-fill support.

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

Re: Question on debugging memory use

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

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

> I would like to audit the memory allocation and deallocation
> for strings during a gnuplot run, to make sure there are no
> memory leaks.
>
> The existence of the routine gp_alloc(mem,"tag label") suggests that
> some such facility was intended, but since there is no corresponding
> routine gp_free I don't see how to use it for this purpose.  
> Is there some clever way of asking for a dump of the currently
> allocated memory chunks?  It would be nice to see the tag labels
> as well, but I can worry about that later if indeed it proves necessary
> to trace down a memory leak.
>
> I see some code in alloc.c marked
>    #ifdef CHECK_HEAP_USE
> but it is not obvious to me how to use it.
>

Looks like something I might have added.

The basic idea is that every block allocated by gnuplot has a header and a footer
added. These have checksums which detect whether the app has scribbled (just)
outside the allocated area.

The header is an instance of frame_struct, which records the reason.

(Usually I link these blocks together so that one can walk the list
 validating each block, but I don't seem to have done that here.
)

The leak check looks like it is simply a means to ensure that the net memory
usage has not changed between two points. So you can put
start_leak_check() at the start of a plot, and end_leak_check at the end.

Things like user-defined functions obviously consume memory, so it's not
going to help with that.

But you could test for memory leaks during string expressions by putting it
around the body of the print command, for example. Then just print various
expressions to see what happens.


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

Visual basic Interface

[<ren...@ya...>]

Hello. 

I found gnuplot in the web and I think it is great.

I want to build an interface with Visual basic 6.0 for
a project in my school.

I wonder if you can give me some information of your
code to build that interface.

The objective of that project is to replace the prompt
that gnuplot use by a control panel.

Let me be more specific. I know that Excel use simple
graphics and I want to make profesional graphics with
the style of gnuplot. The Interface will let me select
the data of the excel sheet that I want to graphic,
using the mouse pointer selecting x, y or z. And then
I will generate the graphic.

I hope you can give me a little hand.

Thanks.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Question on debugging memory use

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

I would like to audit the memory allocation and deallocation
for strings during a gnuplot run, to make sure there are no
memory leaks.

The existence of the routine gp_alloc(mem,"tag label") suggests that
some such facility was intended, but since there is no corresponding
routine gp_free I don't see how to use it for this purpose.  
Is there some clever way of asking for a dump of the currently
allocated memory chunks?  It would be nice to see the tag labels
as well, but I can worry about that later if indeed it proves necessary
to trace down a memory leak.

I see some code in alloc.c marked
   #ifdef CHECK_HEAP_USE
but it is not obvious to me how to use it.

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

Re: Main branch core dump in fillbetween.dem

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

Hans-Bernhard Broeker writes:
> On Wed, 21 Jul 2004, Ethan Merritt wrote:
> 
> > yerrorbars draws a vertical line for each data point in the input file.  
> 
> Ah.  Yep, that sound reasonable.  And you checked that patch in already
> anyway, so this discussion is somewhat moot, isn't it?

 It's fixed in the latest cvs. Thanks, Ethan!

Re: Late evaluation (was: Re: [ gnuplot-Patches-992149 ] String ...)

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

On Thu, 22 Jul 2004, Volker Dobler wrote:

> Hans-Bernhard Broeker <br...@ph...> schrieb am 22.07.04 04:08:18:
> > 
> > gnuplot> set arrow 1 from x, y to x, a(0)
> > gnuplot> show arrow
> > 
> > arrow 1, linetype 1, linewidth 1.000 nofilled back
> > from (2, 1, 0) to (2, 2, 0)
> > 
> > In the light of this, I hope you can see how the only part about your
> > proposal I really don't agree with is the fact that it introduces late
> > evaluation only for strings. I do agree that late evaluation is a useful
> > tool to add. But I disagree about it being useful for strings _only_.
> > 
> 
> That's a clear example why I think "late evaluation" as proposed is
> a bad idea for the users:  Labels might change their text, but stay
> at the same location, even if text and location "depend" on the
> same variable:

You didn't read my post close enough, it seems.  You, like I originally
did, assume late evaluation will *always* be done --- but that's not the
case.  Late evaluation will be a separate feature which has nothing in
particular to do with string expressions.

> From my personal usage of gnuplot, I have to admit, that I do 
> not see, why something like
>   
> gnuplot> f(x) = sprintf("%7.5f",x)
> 
> is necesseary.  What problem can be solved by this user-defined
> function which cannot (or at least not eaily) be solved by other
> means?

The same kind that most users currently solve by defining functions
like

	f(x) = a*x**2 + b*x + c

when they ocould just as well re-type that expression every time they will
now write f(x):  it saves typing and makes it easier to model final
commands by some textbook or internal representation the user is working
with.

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

Re: Late evaluation (was: Re: [ gnuplot-Patches-992149 ] String ...)

[Volker D. <v.d...@we...>]

Hans-Bernhard Broeker <br...@ph...> schrieb am 22.07.04 04:08:18:
> 
> gnuplot> set arrow 1 from x, y to x, a(0)
> gnuplot> show arrow
> 
> arrow 1, linetype 1, linewidth 1.000 nofilled back
> from (2, 1, 0) to (2, 2, 0)
> 
> In the light of this, I hope you can see how the only part about your
> proposal I really don't agree with is the fact that it introduces late
> evaluation only for strings. I do agree that late evaluation is a useful
> tool to add. But I disagree about it being useful for strings _only_.
> 

That's a clear example why I think "late evaluation" as proposed is
a bad idea for the users:  Labels might change their text, but stay
at the same location, even if text and location "depend" on the
same variable:

gnuplot> a=0
gnuplot> set label sprintf("Center: %g",a) at a,1
gnuplot> plot [some function with a as parameter]
gnuplot> fit [fuction of a] [some datafile] via a,...
gnuplot> replot

The second plot would have a label at 0,1 with
text "Center 3.2" if fitting a would yield a=3.2.
At least, thats how I (and I think HBB too) understood "late evaluation".
This seems very convienient for the user:   He needs just _one_
set title sprintf("Fited: a=%g, b=%g",a,b), do some fitting and issue
replots and the titles will reflect the values.
But is it really such a burden to copy the 
"set title sprintf('Fited: a=%g, b=%g',a,b)" before each replot?
I think no.  It anyway would confuse users if this "late evaluation"
happened only for the text string, and not the position of the label.

I agree with Hans-Bernhard, that a _full_ "late evalaution" with
special syntax would be a nice feature.  But as stated:  It should be
clear from syntax, that this string/real/integer-value will be 
re-evaluated each time this cunstruct is beeing output to the
device.

From my personal usage of gnuplot, I have to admit, that I do 
not see, why something like
  
gnuplot> f(x) = sprintf("%7.5f",x)

is necesseary.  What problem can be solved by this user-defined
function which cannot (or at least not eaily) be solved by other
means?

Volker

--
Volker Dobler
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: Late evaluation (was: Re: [ gnuplot-Patches-992149 ] String ...)

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

> 	later(sprintf("%g", y))
> 	later(x);
>
> or, shorter
>
> 	$(sprintf("%g", y))
> 	$(x)

I would prefer the later() function; it would be advantage to have the
'late' evaluation for real-value functions as well. Maybe, there could be
a synonym  sPrintf() = later(sprintf())  (aka \def vs \gdef in TeX).
I don't like the syntax with $ because it breaks for call'ed scripts.

---
PM

Re: Main branch core dump in fillbetween.dem

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

On Wed, 21 Jul 2004, Ethan Merritt wrote:

> yerrorbars draws a vertical line for each data point in the input file.  

Ah.  Yep, that sound reasonable.  And you checked that patch in already
anyway, so this discussion is somewhat moot, isn't it?
> 

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

Late evaluation (was: Re: [ gnuplot-Patches-992149 ] String ...)

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

On Wed, 21 Jul 2004, Ethan Merritt wrote:

> Let me start with a plea to drop the term "late evaluation",
> which I think is side-tracking the current discussion.

Objection, on the grounds that a shared understanding of what that term
means, and what the relation between that and the string variable/function
support you're coding is *exactly* the core of the entire discussion we're
(still) having.

In a very small nutshell: your patchset, combined adds two things:

1) string variables, expressions and functions
2) late evaluation of a special type of string literals:
    'sprintf("%g", x)'  as expressions.

I fully support 1), but object to 2) in its current shape, for reasons of
user interface clarity and future extensibility.

Now, the long version of the above:  As far as I can see, we all agree
upon 1), but somewhere along the way we lost track of what you're doing,
and thought 2) was the *only* kind of string expression evaluation you're
proposing. Well, at least that what threw me off.  

So I suggest we take 1) for granted, and concentrate on 2).

> Whatever it may mean to different people, I don't think it is
> a useful way of thinking about my patchsets.

Well, then let me point out what it means (by my understanding, which I do
hope is pretty standard): in any language where functions or macros are
defined whose final value depend on other variable's values, it's a
central design question when to to actually resolve those unknowns into
known values and compute the result of the function/macro, i.e. "evaluate"  
them: at the time the function/macro is defined, or at the time it's value
is actually used.  The latter case is called "late evaluation".

In other words, 'late evaluation' means you store the expression as
it was entered, and only substitute values for the variables the
moment you need the value.

> The evaluation is never "late"; it happens when it happens.

That statement makes no sense.  If it happens at a later stage than it
could have been done at, it is late.

Let me show you how this distinction translates into gnuplot:

gnuplot> x = 1
gnuplot> y = x
gnuplot> a(b)=x
gnuplot> print y, a(0)
1 1
gnuplot> x = 2
gnuplot> print y, a(0)
1 2

As you see, a(b) picks up the modified value of x, but y doesn't. That is
late evaluation in action.

Now, the goal which your 'sprintf() inside quotes' method addresses is
that there's currently no way at all to do "even later" evaluation of the
parameters that get stored by the various 'set' commands.  In other words,
the actually stored parameters currently can't be expressions --- they're
all fixed values that have been computed from the actual expressions at
the time of the 'set' command:

gnuplot> set arrow 1 from x, y to x, a(0)
gnuplot> show arrow

        arrow 1, linetype 1, linewidth 1.000  nofilled back
          from (2, 1, 0) to (2, 2, 0)

In the light of this, I hope you can see how the only part about your
proposal I really don't agree with is the fact that it introduces late
evaluation only for strings.  I do agree that late evaluation is a useful
tool to add.  But I disagree about it being useful for strings _only_.

I'm aware that an approach that does this from the outside instead of the
inside of string literals will be harder to implement, because it'll have
to be done as part of command line parsing, and will have repercussions
pretty much all through the program.  But I'm stricly opposed to any
syntax that can't be applied to numerical late evaluation, too. I think a
syntax like

	later(sprintf("%g", y))
	later(x);

or, shorter

	$(sprintf("%g", y))
	$(x)

would be strongly preferrable, even at the cost of extra work at source
level.

Since there's nothing one can do with late evaluation that one couldn't
also achieve without it (by changing the order of commands, possibly
re-loading a saved series of commands), I suggest we keep this part of the
patch collection out of the CVS tree and go for a mode broadly scoped
implementation of that feature.

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

Re: Main branch core dump in fillbetween.dem

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

On Wednesday 21 July 2004 05:35 pm, Hans-Bernhard Broeker wrote:
> 
> Hmm... what with your recent joining of filledboxes and filledcurves, can
> filled rectangles still be supported by a terminal driver if there are no
> filledcurves?

Yes.
The parameters to term->fillbox are different than the parameters
to term->filled_polygon.   Any terminal that has support for
filled_polygon can use it to implement fillbox, or not, or make it
conditional.  Core routines that used to call term->fillbox still do so. 

> At least for the case at hand (dumb.trm), 
> term->filled_box() isn't supported either.  Whereas an attempt to
> dense-fill yerrorbars might well come out too huge in file size to be
> useful

yerrorbars draws a vertical line for each data point in the input file.  
That is half the number of lines you would get by drawing both 
curves with lines. Yerrorbars is what the docs say you get if you
specify an "inappropriate" 3-column plotting style, and it turns out to
look quite reasonable in this case. Even the output on the dumb
terminal looks sensible.

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

Re: Main branch core dump in fillbetween.dem

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

On Wed, 21 Jul 2004, Ethan Merritt wrote:

> On Wednesday 21 July 2004 04:44 am, Hans-Bernhard Broeker wrote:
> > 
> > Well, to put it none too subtly: terminal 'dumb' doesn't support PM3D
> > function filled_polygon, so graphics.c:1810 is calling NULL pointer.
> > Instant crash guaranteed.
> 
> I will fix the crash.  But what behavior is preferred in this case?
> 
> approximate with rectangles or yerrorbars rather than polygons
> (consistent with documentation),

Hmm... what with your recent joining of filledboxes and filledcurves, can
filled rectangles still be supported by a terminal driver if there are no
filledcurves?  At least for the case at hand (dumb.trm),
term->filled_box() isn't supported either.  Whereas an attempt to
dense-fill yerrorbars might well come out too huge in file size to be
useful.

> plot one or both of the curves with lines only
> (consistent with previous behaviour of filledcurves although
> not what the docs say),

IMHO that feels more sensible.  If the terminal can't fill, don't
try to coerce it.  We could change the docs instead.


> or
> 
> int_warn(NO_CARET,"plotting style not available for this terminal")

That would have to be an int_error(), I think.  That is, unless
you intend to avoid trying to call nonexistant terminal entries by
some additional code.

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