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

Building issues under Solaris 9

[Christopher C. <Chr...@jp...>]

Hello,

    I am not certain that I am emailing the proper address but this is 
the address I saw on the development page.

    I am using Solaris 9 and attempting to build the latest CVS version 
4.1 for a scientist who needs to use a feature only under 4.1 apparently.

    I tried the sample unix makefile with no success so then I grabbed 
the required versions of autoconf, m4, etc. and tried to follow the 
directions on the page.

    The process hangs/waits with ./prepare:

opik{root}76# ./prepare
rm -f Makefile.am Makefile.amt
sed -n '1,/^##m4-files-begin/p' Makefile.am.in > Makefile.amt
echo EXTRA_DIST = README Makefile.am.in buildvms.com config.* \
  djconfig.sh make_vms.com term_pc.h makefile.* | fmt | \
  (tr '\012' @; echo) |sed 's/@$/%/;s/@/ \\@/g' |tr @% '\012 ' >> 
Makefile.amt
sed -n '/^##m4-files-end/,$p'  >> Makefile.amt


    What tips do you have for building (other than on the dev. page).

    Thanks.

Re: [ gnuplot-Bugs-1225866 ] slowdown in readline()?

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

On Sunday 26 June 2005 02:21 pm, Holger Hellwig wrote:
> thank you very much for your time and efforts!! I will check about the kicker 
> application in more detail, maybe an update to KDE3.4.1 will do, as soon as 
> available,

I have discovered that at some point the "-noevents" flag 
stopped working properly.   Could you please re-do one or more
of your tests using the  "-nofeedback" flag instead?
E.g.

	./gnuplot_x11 -nofeedback < file.x11
or
	echo "plot sin(x)" | gnuplot -nofeedback -persist


		thanks,

			Ethan


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

user-defined function & string file name

[Taro S. <no...@gm...>]

Hello.  This is my first attempt at filing a potential bug report.=20
Please let me know if I'm doing something inappropriate here.=20
Especially if this is not a good place to do this, please point me to
the right direction.  I like the cvs version of gnuplot so much that
I'd like to keep submitting if I find any bugs in future.

It seems the gnuplot has difficulty distinguishing a user-defined
function and a string file name stored in a variable.  I have an ASCII
data file "xy.dat" with the following content:

BEGIN xy.dat-------------------
0       0
1.1     0.9
2.3     2.1
2.9     3.2
END----------------------

and wish to overplot a straight line.  If I do

BEGIN plot.okay.gp-------------------
reset
f(x) =3D x
plot f(x), 'xy.dat' u 1:2
pause -1
END----------------------

The plot comes out fine, but if I store the data file name in a string as i=
n

BEGIN plot.nogood.gp-------------------
reset
f(x) =3D x
fdat =3D 'xy.dat'
plot f(x), fdat u 1:2
pause -1
END----------------------

then gnuplot complains:

"plot.nogood.gp", line 4: warning: encountered a string when expecting a nu=
mber
"plot.nogood.gp", line 4: NB: you cannot plot a string-valued function

Thanks for your time,
Taro

Re: [Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

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

On Saturday 25 June 2005 06:50 am, you wrote:
>
> yes, it uses an eval stack. But it's a "pure" estack. When a udf
> function is invoked, the parameters are copied off the estack into
> some other storage. What I'm suggesting a small change to leave them
> on the estack, with a frame being pushed. This gets round the problem
> of having an upper limit number on the number of dummy variables,
> without having to set aside storage to copy parameters.
>
> Looking at the 4.0 sources, f_calln() in internal.c has to
>
>     for (i = 0; i < MAX_NUM_VAR; i++)
>         save_dummy[i] = udf->dummy_values[i];
>
> I'm proposing that we (er... someone !)  changes this so that,
> instead, f_calln() lays down some notion of frame linkage in the
> estack, so that it can find dummy parameters.

OK. I get it now, at least conceptually.
I think you are/were more familiar with the inner workings of the
evaluation code than I am.

It looks to me that there is also a less drastic, though less elegant,
fix. Instead of pre-reserving a fixed size array in the udft_entry
structure, we could allocate the space dynamically immediately prior
to the code you quote above.

--- f_calln.c.orig      2005-06-25 15:14:01.620104672 -0700
+++ f_calln.c   2005-06-25 15:16:07.559958904 -0700
@@ -13,12 +13,13 @@
     if (!udf->at) {            /* undefined */
        int_error(NO_CARET, "undefined function: %s", udf->udf_name);
     }
-    for (i = 0; i < MAX_NUM_VAR; i++)
-       save_dummy[i] = udf->dummy_values[i];
-    /* if there are more parameters than the function is expecting */
-    /* simply ignore the excess */
     (void) pop(&num_params);
+    num_pop = num_params.v.int_val;
+    udf->dummy_values = gp_alloc(sizeof(struct value) * num_pop);
+    for (i = 0; i < num_pop; i++)
+       save_dummy[i] = udf->dummy_values[i];



It also looks to me that there is an overflow flaw in the current
code.  It tries to "ignore the excess parameters" by popping them into
the dummy_values array first, and then overwriting them with the actual
parameters up to MAX_NUM_VAR.  If the number of parameters to be thrown
away itself exceeds MAX_NUM_VAR, it will end up trashing whatever
is next in the malloc heap.

internal.c 198:
    /* if there are more parameters than the function is expecting */
    /* simply ignore the excess */
    (void) pop(&num_params);
    if (num_params.v.int_val > MAX_NUM_VAR) {
        /* pop the dummies that there is no room for */
        num_pop = num_params.v.int_val - MAX_NUM_VAR;
        for (i = 0; i < num_pop; i++)
            (void) pop(&(udf->dummy_values[i]));
    }

Hmmm. Let's see...
gnuplot> f(x) = sin(x)
gnuplot> print f(pi,1,2)
1.0
gnuplot> print f(pi/2,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,
17,18,19,20,21,22,23,24,25,26,27,28,29,30)
gnuplot> Segmentation fault

So indeed there is room to improve this code.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

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

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

> On Friday 24 June 2005 12:11 pm, you wrote:
>> >> How about changing these arrays to hold dynamically
>> >> allocated pointers instead.  [[...]]
>>
>> - how are string literals in expressions represented?
>
> A string literal that is part of a user-defined function is held in
> a dynamically-allocated udv in the pre-built evaluation stack for
> that function.

Hmm - not sure what you mean by the pre-built eval stack - I know
gnuplot fairly intimately back in 3.6 but that was a while ago now.

I was thinking of expressions mostly for user-defined functions, but
there are also the expressions which are anonymous, but which are
evaluated many times (eg  plot ... using  )


> In any case, when the string is referenced during the course of evaluating
> an expression, a copy of the string is made by allocating dynamic storage.
> This temporary copy is pushed/popped/dereferenced using the stack during
> the expression evaluation, and freed again at the end of evaluation.
>
>> When I was 
>>   deliberating over this area, I was tending towards having the notion
>>   of a string pool associated with an exression. The pool would
>>   survive for as long as the expression did, and if that meant the
>>   expression was stored in a user-defined fn, then the string pool
>>   would persist.
>
> If I understand correctly, that is what it currently does.
> But I don't quite follow the use of the word "pool", except insofar
> as the strings exist in the heap managed by malloc() via gp_alloc().
>

Okay... I had invented a scheme using a pool simply to avoid the pain
of having to clean up when the expression itself was freed. Rather
than having an arbitrary number of pointers to strings stored
elsewhere, I had in mind one lump of memory associated with the
expression, and then string literals were stored within that
pool, and the "action" to access the string literal stored an index into
that pool, rather than a direct pointer (so that as the pool grows, we
don't need to fixup pointer). Then since all expressions (or action
tables) have one constant-pool pointer, there is only one lump of
memory to free when the expression gets deleted. But this is just a
detail.

>>   If that approach was used, then the names of the dummy variables
>>   could be stored in that string pool.
>
> There you lost me.  The dummy variable names are independent of
> any particular function, and must be available to the parser before
> any user-defined functions have been defined.  Unless, as before,
> by "stored in that pool" you mean "dynamically allocated by gp_alloc()"?
>

Ah - sorry - perhaps I'm being stupid. I vaguelly recalled that the
dummy variable names were preserved in order to be able to echo them
back to the user when listing / saving udf's. But it probably just
saves the entire expression as a string. So it doesn't need to keep
the names of the variables.



Perhaps MAX_NUM_VAR is being misused - it is the size of an array to
store the current "global" dummy names, but also gets used as the size
of array for parameters passed to fns.


>> - the other aspect of MAX_NUM_VAR is to actually have space for the
>>   values during (recursive) expression parsing. My recollection is
>>   that gnuplot used to have a fixed area for the parameter values, and
>>   when recursing into a udf, would copy the old values into temporary
>>   space, and put the new values into the globals. I don't know if this

yeah...

/* user-defined function table entry */
typedef struct udft_entry {
    struct udft_entry *next_udf; /* pointer to next udf in linked list */
    char *udf_name;		/* name of this function entry */
    struct at_type *at;		/* pointer to action table to execute */
    char *definition;		/* definition of function as typed */
    t_value dummy_values[MAX_NUM_VAR]; /* current value of dummy variables */
} udft_entry;


Okay, not globals, but a dummy_values[] array stored with each udf.


>>   is still how it works. But a much more elegant solution would be to
>>   use an evaluation stack. (I work on java vm's these days, so it's
>>   obvious where this idea comes from...)
>
> It does use an evaluation stack.  Currently the stack is of fixed size
>    eval.c:  static struct value stack[STACK_DEPTH];
> but I think it would be straightforward to make it dynamically evaluated
> instead. The push() routine would have to check whether the stack needs
> to be expanded via realloc().
>


yes, it uses an eval stack. But it's a "pure" estack. When a udf
function is invoked, the parameters are copied off the estack into
some other storage. What I'm suggesting a small change to leave them
on the estack, with a frame being pushed. This gets round the problem
of having an upper limit number on the number of dummy variables,
without having to set aside storage to copy parameters.

Looking at the 4.0 sources, f_calln() in internal.c has to

    for (i = 0; i < MAX_NUM_VAR; i++)
        save_dummy[i] = udf->dummy_values[i];

copy the old parameters out into some spare space (since this might be
a recursive call, presumably), then copy the parameters off the stack
into the dummy_values for the udf, and then resume resume. And then on
return, it has to copy back the saved ones into the current
dummy_values[]


I'm proposing that we (er... someone !)  changes this so that,
instead, f_calln() lays down some notion of frame linkage in the
estack, so that it can find dummy parameters.

Then f_pushd() [push dummy variable onto estack] is changed to not
fetch it from the (fixed size) array in the udf defn, but instead,
fetch from lower down in the estack.

And returning from a udf just removes the linkage, actually pops the
fn parameters off the caller's estack, and pushes the result.


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

Re: Setjmp(), longjmp() in gnuplot

[<br...@ph...>]

Ethan Merritt wrote:
> I see. So your new driver is C++ only?  That is already a potential
> problem since the rest of the gnuplot is distinctly not C++ code.
> I fear it will limit the number of platforms on which your new
> driver will actually compile and link into gnuplot successfully.

Not any more than the fact that the desired output system for that 
driver being C++ already limited it.  I.e. if wxWidgets runtime and 
development support exists on the box, there's nothing to stop a gnuplot 
build from using them.

If there's an actual problem to be caused by this, it'll be that the 
link of the entire gnuplot will now have to be done with the C++ 
compiler's linker presets.  I.e. we'll pull in the C++ startup code.  On 
  less sane platforms, that could indeed cause trouble.

Re: [Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

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

On Friday 24 June 2005 12:11 pm, you wrote:
> >> How about changing these arrays to hold dynamically
> >> allocated pointers instead.  [[...]]
>
> - how are string literals in expressions represented?

If a literal string appears in-line on a single command line, then it
has no continuing existence.  It exists as part of the command line
being parsed.

String variables do have continuing existence, in dynamically-allocated
storage associated with the udv for that variable name.

A string literal that is part of a user-defined function is held in
a dynamically-allocated udv in the pre-built evaluation stack for
that function.

In any case, when the string is referenced during the course of evaluating
an expression, a copy of the string is made by allocating dynamic storage.
This temporary copy is pushed/popped/dereferenced using the stack during
the expression evaluation, and freed again at the end of evaluation.

> When I was 
>   deliberating over this area, I was tending towards having the notion
>   of a string pool associated with an exression. The pool would
>   survive for as long as the expression did, and if that meant the
>   expression was stored in a user-defined fn, then the string pool
>   would persist.

If I understand correctly, that is what it currently does.
But I don't quite follow the use of the word "pool", except insofar
as the strings exist in the heap managed by malloc() via gp_alloc().

>   If that approach was used, then the names of the dummy variables
>   could be stored in that string pool.

There you lost me.  The dummy variable names are independent of
any particular function, and must be available to the parser before
any user-defined functions have been defined.  Unless, as before,
by "stored in that pool" you mean "dynamically allocated by gp_alloc()"?

> - the other aspect of MAX_NUM_VAR is to actually have space for the
>   values during (recursive) expression parsing. My recollection is
>   that gnuplot used to have a fixed area for the parameter values, and
>   when recursing into a udf, would copy the old values into temporary
>   space, and put the new values into the globals. I don't know if this
>   is still how it works. But a much more elegant solution would be to
>   use an evaluation stack. (I work on java vm's these days, so it's
>   obvious where this idea comes from...)

It does use an evaluation stack.  Currently the stack is of fixed size
   eval.c:  static struct value stack[STACK_DEPTH];
but I think it would be straightforward to make it dynamically evaluated
instead. The push() routine would have to check whether the stack needs
to be expanded via realloc().


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: x11 color resources

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

On Friday 24 June 2005 02:15 pm, Petr Mikulik wrote:
> I didn't like the gray x11 window background when running gnuplot on a 
> computer cluster ... then I have noticed that on some computers the 
> following in .Xdefault (+ xrdb ...) works always
>  	gnuplot.background: white
> but this only on some
>  	gnuplot*background: white

The x.y form of an X11 resource takes precedence over the x*y form.
I suspect that on your machines where setting gnuplot*background has 
no effect, it is because there is also an active gnuplot.background
resource that remains in effect.
 
> And the following does not work at all:
> gnuplot.textColor: red

Right. Nothing in the current gnuplot source looks for such
a resource.  If it is mentioned in the docs, it must date back to
an obsolete version.  
 
> Gnuplot docs contains only the "gnuplot*background" notation. Is it OK?

Yes.  
We cannot possibly replicate the entire set of X11 documentation
just to explain things that affect gnuplot the same way they affect
all other X11 programs.


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

Re: make gnuplot.tex fails due to PS_COMMON_OPTS1,2, PS_COMMON_DOC1,2

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

>> Building
>>  	make gnuplot.tex    (.pdf, .dvi, .html)
>>
>> in docs/ fails due to wrong positioning of macros PS_COMMON_OPTS1,2,
>> PS_COMMON_DOC1,2 in allterm.h.
>
> It builds just fine for me here.
> Which part of the tool chain are you getting an error from?

I do:

$./configure; make
$cd docs
$ make tex
Building allterm.h
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src -I../term 
-I/usr/X11R6/include -I/usr/include -I/usr/local/include -g -O2 
-DALL_TERM_DOC -c ./doc2tex.c
In file included from doc2x.h:70,
                  from doc2tex.c:63:
allterm.h:1005: error: `PS_COMMON_OPTS1' undeclared here (not in a function)
allterm.h:1005: error: initializer element is not constant
allterm.h:1005: error: (near initialization for `termtext[991]')
allterm.h:1005: error: parse error before string constant
allterm.h:1007: error: `PS_COMMON_OPTS2' undeclared here (not in a function)
allterm.h:1007: error: initializer element is not constant
allterm.h:1007: error: (near initialization for `termtext[992]')
allterm.h:1025: error: `PS_COMMON_DOC1' undeclared here (not in a function)
allterm.h:1025: error: initializer element is not constant
allterm.h:1025: error: (near initialization for `termtext[1009]')
allterm.h:1025: error: parse error before string constant
allterm.h:2652: error: `PS_COMMON_OPTS1' undeclared here (not in a function)
allterm.h:2652: error: initializer element is not constant
allterm.h:2652: error: (near initialization for `termtext[2627]')
allterm.h:2652: error: parse error before "PS_COMMON_OPTS2"
...
allterm.h:2992: error: parse error before string constant
make: *** [doc2tex.o] Error 1

---
PM

Re: make gnuplot.tex fails due to PS_COMMON_OPTS1,2, PS_COMMON_DOC1,2

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

On Friday 24 June 2005 02:22 pm, Petr Mikulik wrote:
> Building
>  	make gnuplot.tex    (.pdf, .dvi, .html)
> 
> in docs/ fails due to wrong positioning of macros PS_COMMON_OPTS1,2, 
> PS_COMMON_DOC1,2 in allterm.h.

It builds just fine for me here.
Which part of the tool chain are you getting an error from?

I always build tex and pdf documentation when testing the cvs tree,
so I am reasonably sure I would have noticed immediately if 
something had introduced problems.


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

make gnuplot.tex fails due to PS_COMMON_OPTS1,2, PS_COMMON_DOC1,2

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

Building
 	make gnuplot.tex    (.pdf, .dvi, .html)

in docs/ fails due to wrong positioning of macros PS_COMMON_OPTS1,2, 
PS_COMMON_DOC1,2 in allterm.h.

It seems epslatex.trm uses them before they are included via 
START_HELP(00psglobal). Could someone fix it?

---
PM

x11 color resources

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

I didn't like the gray x11 window background when running gnuplot on a 
computer cluster ... then I have noticed that on some computers the 
following in .Xdefault (+ xrdb ...) works always
 	gnuplot.background: white
but this only on some
 	gnuplot*background: white

And the following does not work at all:
gnuplot.textColor: red

Gnuplot docs contains only the "gnuplot*background" notation. Is it OK?

---
PM

Re: Replot in epslatex terminal

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

> Yes, of course.  I understood that. But I though your point was that
> making them visible to the user allows you to change them explicitly.
> erroneous file containing the erroneous file and then continue on
> in the same sequence as before.

Yes.

---
PM

Re: Setjmp(), longjmp() in gnuplot

[<tim...@en...>]

Thanks to your different points of view, I finally got it working !

Nigel has the most "C++ friendly" solution, but I think I'm not enough=20
experiences with exceptions to override bail_to_command_line() with them.

However, as Ethan and Dave proposed, I can do my own setjump in the=20
thread which is sending the command. As I can't come back from a=20
longjump to my gui thread (because it contains c++ objects), I simply=20
have to use another thread. This "worker thread" has no object, so it is=20
"setjmp - safe". It verifies if it is called from the longjump to avoid=20
sending the command again.

This way, I only need to add a test to bail_to_command_line() to call=20
the good longjmp().

I hope you'll find this solution convenient !

Timoth=C3=A9e


P.S. : Here's a gift : http://tipote.free.fr/wxt2.png
A screenshot of the current state of the terminal

Re: Setjmp(), longjmp() in gnuplot

[<tim...@en...>]

Ethan Merritt wrote:

>On Friday 24 June 2005 01:42 pm, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>Ethan Merritt wrote:
>>   =20
>>
>> The remaining problem is that setjmp/longjmp were=20
>>designed for C, not C++.
>>   =20
>>
>I see. So your new driver is C++ only?=20
>
It is C++ only, but until now I have managed to mix C and C++ without=20
problems. I have added a few lines in configure.in (for both c++ and=20
wxwidgets), written my terminal as a common wxt.trm whith C++ functions=20
defined in an external wxt.cpp file.

>That is already a potential problem since the rest of the gnuplot is dis=
tinctly not C++ code.
>I fear it will limit the number of platforms on which your new
>driver will actually compile and link into gnuplot successfully.
>We'll find out, I guess.
> =20
>
According to c++ documentation, it should not be a problem (provided we=20
have a c++ compiler for the desired platform ;-). The C and C++ files=20
are compiled by their respective compilers, and then the C++ one link=20
everything. It works at least on my machine.

>>So if I initialize the =20
>>longjump when creating my terminal thread, it doesn't delete the old=20
>>window but open a new one when longjmp is used ! However, it does not=20
>>segfault... So the solution may be to check if another window is opened=
=20
>>and destroy it before to continue. That doesn't seem very efficient.
>>   =20
>>
>
>Can't you do the same thing as the x11 driver?  When you send a new
>plot command the driver looks to see if there is an existing window and =
if
>so uses it.  If there is no existing window then it opens a new one.
>See the difference?  You check for an old window, but instead of destoyi=
ng
>it you just use it explicitly for the new plot also.
> =20
>
I think that all this setjmp/longjmp stuff makes it difficult. I've=20
tried some combinations, and even if objects are not destroyed, they are=20
not usable ! I can't tell anything to the frame.

On the other hand, I wrote things so that when user closes the terminal=20
window, in fact he only hides it, so on next plot it is still available=20
and it is asked to unhide. But setjmp/longjmp are not the same problem=20
unfortunately !

Timoth=C3=A9e

Timoth=C3=A9e

Re: [Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

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

Jonathan Thornburg <jt...@ae...> writes:

> On Thu, 2 Jun 2005, Ethan Merritt wrote:
>
>> On Wednesday 25 May 2005 05:03 am, Lars Hecking wrote:
>>>
>>> may I ask to advance the #define'd compile-time parameter
>>>      MAX_NUM_VAR
>>> in src/syscfg.h from 5 to something like 20 or so?  :-)
>>
>> The arrays that use MAX_NUM_VAR are horribly wasteful,
>> particularly if we bump it up to a larger number.
>>  e.g.:     char c_dummy_var[MAX_NUM_VAR][MAX_ID_LEN+1];
>> would be reserving 20*50 chars of storage to hold what
>> is usually 2-3 instances of single-characters names like
>> "u", "v" or "w".
>>
>> How about changing these arrays to hold dynamically
>> allocated pointers instead.  [[...]]


This reminds me of some work I had planned long ago (when I had time
to help out on gnuplot). A couple of thoughts... 


- how are string literals in expressions represented ?  When I was
  deliberating over this area, I was tending towards having the notion
  of a string pool associated with an exression. The pool would
  survive for as long as the expression did, and if that meant the
  expression was stored in a user-defined fn, then the string pool
  would persist.

  If that approach was used, then the names of the dummy variables
  could be stored in that string pool.


- the other aspect of MAX_NUM_VAR is to actually have space for the
  values during (recursive) expression parsing. My recollection is
  that gnuplot used to have a fixed area for the parameter values, and
  when recursing into a udf, would copy the old values into temporary
  space, and put the new values into the globals. I don't know if this
  is still how it works. But a much more elegant solution would be to
  use an evaluation stack. (I work on java vm's these days, so it's
  obvious where this idea comes from...)

  Basically, there is one block of memory for estack. Each function
  has a frame on the stack. When a fn is invoked, the frame of a
  function overlaps the estack of the previous one.

  eg

  g(x,y,z)=x+y+z
  f(x,y,z)=6 + g(x+2, y+3, 42)

gnuplot> show at f(10,11,12) 

        pushc 10
        pushc 11
        pushc 12
        pushc 3
        calln f
          pushc 6
          pushd1 f dummy
          pushc 2
          plus
          pushd2  dummy
          pushc 3
          plus
          pushc 42
          pushc 3
          calln g
            pushd1 g dummy
            pushd2  dummy
            plus
            pushc 2
            pushd
            plus
          plus

consider estack growing from left to right.

push parameters

10 11 12

invoke f : I assume the 3 is a parameter count (ie linkage). This
becomes the start of the frame for f, with the parameter values still
on the bit of the stack belonging to the caller. (Or we could consider
this bit of the estack to be shared)

10 11 12 | 3 |

start interpreting f. The pushd1 (push dummy 1) reaches down in the
estack to retrieve the parameter values from the top of the estack of
the caller.

10 11 12 | 3 | 6 10 2

plus

10 11 12 | 3 | 6 12

so on until we invoke g

10 11 12 | 3 | 6 12 14 42 | 3 | 

etc.


When a function exits, we merely take the value on top of the estack,
remove the linkage, and push the value back on top of the estack. so
the net effect is to pop the parameters and push the result.


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

Re: Setjmp(), longjmp() in gnuplot

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

On Friday 24 June 2005 01:42 pm, Timoth=C3=A9e Lecomte wrote:
> Ethan Merritt wrote:
>=20
> >
> >I would think the proper fix is to re-initialize the longjump at the
> >start of each thread creation.  Then if you get an error it will jump
> >to a per-thread error handler and exit the thread cleanly.
> > =20
> >
> I have just tried it. The remaining problem is that setjmp/longjmp were=20
> designed for C, not C++.

I see. So your new driver is C++ only?  That is already a potential
problem since the rest of the gnuplot is distinctly not C++ code.
I fear it will limit the number of platforms on which your new
driver will actually compile and link into gnuplot successfully.
We'll find out, I guess.

> So if I initialize the =20
> longjump when creating my terminal thread, it doesn't delete the old=20
> window but open a new one when longjmp is used ! However, it does not=20
> segfault... So the solution may be to check if another window is opened=20
> and destroy it before to continue. That doesn't seem very efficient.

Can't you do the same thing as the x11 driver?  When you send a new
plot command the driver looks to see if there is an existing window and if
so uses it.  If there is no existing window then it opens a new one.
See the difference?  You check for an old window, but instead of destoying
it you just use it explicitly for the new plot also.



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

Re: Setjmp(), longjmp() in gnuplot

[<tim...@en...>]

Ethan Merritt wrote:

>Caveat: I don't really understand how your new terminal type is supposed
>to work.  So maybe I have the wrong end of the stick here...
>
>On Friday 24 June 2005 11:45 am, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>As far as I understand, this would be perfect if I had not to use a=20
>>separate thread for my terminal. Indeed, I want to send a command from=20
>>the terminal (through a menu for example) to gnuplot. I use events=20
>>defined in mouse.c, and more precisely a "command" event (which doesn't=
=20
>>seem to be used very often, or maybe in OS/2 only). The do_event(event)=
=20
>>is executed in my gui thread. When an error appears on the command, we=20
>>obtain a longjump which is invalid for *this* gui thread... and it ends=
=20
>>with a segmentation fault.
>>   =20
>>
>
>I would think the proper fix is to re-initialize the longjump at the
>start of each thread creation.  Then if you get an error it will jump
>to a per-thread error handler and exit the thread cleanly.
> =20
>
I have just tried it. The remaining problem is that setjmp/longjmp were=20
designed for C, not C++. In particular, longjmp doesn't do any extra=20
work needed by C++, such as deleting objects. So if I initialize the=20
longjump when creating my terminal thread, it doesn't delete the old=20
window but open a new one when longjmp is used ! However, it does not=20
segfault... So the solution may be to check if another window is opened=20
and destroy it before to continue. That doesn't seem very efficient.

>>Another solution would be to build the terminal as a separate process,=20
>>like x11 or os/2 ones. But I think it's not an optimal design.
>>So I would be pleased if somebody can give me a tip in order to deal=20
>>with this issue ;-) .
>>   =20
>>
>
>I might understand better if you would briefly describe the flow of
>control you are trying to achieve.  What does the new terminal type do
>that existing terminals do not handle already?  Is the user expected to =
run
>gnuplot from a command line, but when 'set term wxwidgets' is selected a=
=20
>separate control window appears?   Or does the user run a wrapping progr=
am
>that executes gnuplot underneath with the terminal pre-set to communicat=
e with
>the wrapping layer? =20
>
>If it's the latter, then I'm not sure you even  need a new terminal type.
>You may be able to use 'set term x11' and direct the output to an embedd=
ed
>panel of the wrapping program (see patchset #1027032).  I'm not saying t=
his
>is the best thing to do, but I point it out as a possibility.
> =20
>
I will try to explain briefly.
I write a terminal like the x11, postscript, etc. So I use the standard=20
gnuplot interactive command line, type "set terminal wxt" and then any=20
plot command makes the plot window appears, as the x11 terminal works=20
for example. The window is opened in a thread inside gnuplot main=20
process. Thus, your precedent remark is pertinent.
I want to implement extra interactivity menus or toolbar. So I want to=20
send commands back to the command interpreter. I do that with do_event=20
which is precisely written for it.

Regards
Timoth=C3=A9e

Re: Replot in epslatex terminal

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

On Friday 24 June 2005 11:25 am, Petr Mikulik wrote:
> >> New gnuplot global variables PLOT_NUMBER and PAGE_NUMBER?
> >
> > You mean, so that you can at any time reset the sequence, or force the
> > next plot to have a particular number?
> > Sure. That could be part of it, if you like.
> 
> Those variables would be incremented by gnuplot at each "plot" or 
> multiplot+plot, respectively.

Yes, of course.  I understood that. But I though your point was that
making them visible to the user allows you to change them explicitly.
For instance, if you were to make a mistake while creating a sequence of
plots interactively you could do PLOT_NUMBER = PLOT_NUMBER -1
before fixing the error and replotting.  This would overwrite the
erroneous file containing the erroneous file and then continue on 
in the same sequence as before. 

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

Re: Replot in epslatex terminal

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

>> New gnuplot global variables PLOT_NUMBER and PAGE_NUMBER?
>
> You mean, so that you can at any time reset the sequence, or force the
> next plot to have a particular number?
> Sure. That could be part of it, if you like.

Those variables would be incremented by gnuplot at each "plot" or 
multiplot+plot, respectively.

---
PM

Re: Replot in epslatex terminal

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

On Friday 24 June 2005 10:51 am, Petr Mikulik wrote:
> > 	FILENAME(plotno) = sprintf("./plot_%02d.eps",plotno)
> > 	set output sequential FILENAME
> >
> > Each plot command would increment plotno and trigger the creation of a
> > new output file.
> 
> New gnuplot global variables PLOT_NUMBER and PAGE_NUMBER?

You mean, so that you can at any time reset the sequence, or force the
next plot to have a particular number?
Sure. That could be part of it, if you like.


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

Re: help exit

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

> Then you didn't look in the right place.  Here's the end of "help fit"
> in a .gih-based version, as an example:
>
> Subtopics available for fit:
>    adjustable_parameters               beginners_guide   control
>    error             error_estimate    errors            guide
>    multi-branch      parameters        starting_values   tips
>
> Subtopic for fit:  <input cursor here>
>
> If you type "tips" here, it'll put you to the same node otherwise reached by 
> "help fit tips".

Yes, but this table is for few items, and it appers on the button, as an 
inherent part of the particular help text. This cannot be considered as a 
common header what Daniel has proposed.

> In Windows, you get a collection of clickable links to the sub-nodes instead.

It does not use .gih, but its own GUI-driven help file.

---
PM

Re: Replot in epslatex terminal

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

> 	FILENAME(plotno) = sprintf("./plot_%02d.eps",plotno)
> 	set output sequential FILENAME
>
> Each plot command would increment plotno and trigger the creation of a
> new output file.

New gnuplot global variables PLOT_NUMBER and PAGE_NUMBER?

---
PM

Re: help exit

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

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

> On Thursday 23 June 2005 07:44 am, Petr Mikulik wrote:
>> I propose this text:
>> 
>> 
>>   The commands `exit` and `quit`, as well as the END-OF-FILE character
>>   (usually  Ctrl-D) terminate input from the current input stream: terminal
>>   session,  pipe, and file input (pipe).
>> 
>>   If input streams are nested (inherited `load` scripts), then reading will
>>   continue in the parent stream. When the top level stream is closed, the
>>   program itself will exit.
>> 
>>   See "help batch/interactive" for more details.
>
> Looks OK to me.
>

Just trying now (inspired by earlier suggested text), gnuplot can have
a sequence of top-level streams.

$ gnuplot <(echo print 3) - <(echo print 4)
3
gnuplot> print 6*7
42
gnuplot> exit
4


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

Re: Setjmp(), longjmp() in gnuplot

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

Timoth=E9e Lecomte <tim...@en...> writes:

> Hello !
>
> I keep working on the wxwidgets terminal, and I am now facing a
> difficult problem.
>
> When there are errors on a command line, gnuplot uses its functions
> int_error(token, string) to inform the user and stop parsing the
> command line. This function prints an error message and then calls
> bail_to_command_line() which is simply a wrapper for the standard
> longjmp(env) function. This is similar to "goto", and puts the program
> in its initial state by restoring the registers set in main().
>

It is *currently* "simply a wrapper" for longjmp. A good while ago, I
went through replacing lots of explicit longjmp calls with this
wrapper, precisely so that the behaviour could be changed in a central
way if it turned out to be necessary.

> As far as I understand, this would be perfect if I had not to use a
> separate thread for my terminal. Indeed, I want to send a command from
> the terminal (through a menu for example) to gnuplot. I use events
> defined in mouse.c, and more precisely a "command" event (which
> doesn't seem to be used very often, or maybe in OS/2 only). The
> do_event(event) is executed in my gui thread. When an error appears on
> the command, we obtain a longjump which is invalid for *this* gui
> thread... and it ends with a segmentation fault.
>
> I can't simply delete the longjump, as it is necessary to stop command
> line parsing. If I do it, gnuplot either seems to enter in a infinite
> loop or terminante with an other segfault.
>


Can't you just augment / replace bail_to_command_line() to make it do
what you need ?  Or you could save the existing jmpbuffer and do
another setjmp to basically intercept the longjmp calls, letting you
do any extra work, before you longjmp back to the original setjmp
location.




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