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

stringvars patch from a users point of view

[<wie...@fr...>]

I've just tried the stringvars patch.
It adds some really nice and useful features.

Nevertheless I have some comments from a users point of view, in the
hope they are useful:

Even without the patch, I'm not completely happy about how gnuplot
parses its command input. It's often tricky to say if a token is a
key word or a variable name. For example:

  gnuplot> plot "-" witt lines
           undefined variable: witt

This error message is a little bit surprising.=20
So far, at least strings could be recognized at first glance. Now it
goes

  gnuplot> n =3D 1
  gnuplot> tc =3D "label"
  gnuplot> set label n tc at 1, 1
                          ^
           textcolor colorspec not recognized

OK, this case might be recoverable with "help set label". But it's
not really the fault of the user.=20
[BTW: Isn't the parser meant to be greedy? Then I would expect it
to first test if "tc" can be some kind of string. Not that this
would be a good idea...]

But I don't know a solution either.
The straight forward approach would be to disallow all key words as
variable names.
There too many key words (+abbreviations) for this being viable, I
know. And it would break script compatibility.
Maybe to demand ''.tc is not that bad.


The second issue is about the "late evaluation". I like

  set label %sprintf("foo %f", var)%

=46rom the users point of view, it's not a string but a string valued
expression, which is evaluated at plot time. If ordinary quotes are
used, it would be expected to be constant and unevaluated.



And once more: Thanks for this great piece of work.
Juergen

Warning in compiling Gnuplot

[Harald H. <h.h...@tu...>]

For some time, I get following warning for each compiled file:

In file included from misc.h:40,
                 from misc.c:37:
syscfg.h:453: warning: useless keyword or type name in empty declaration
syscfg.h:453: warning: empty declaration

And this is the part of the file syscfg.h:

#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# if ! HAVE__BOOL
#  ifdef __cplusplus
typedef bool _Bool;
#  else
typedef unsigned char _Bool;   /* This is line 453 */
#  endif
# endif
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
#endif

If I am renaming _Bool to something different or if I comment out the
whole line, the warnings dissappear, and everything still works fine.

Does somebody know why _Bool is defined in syscfg.h? How can we find out
if it is already defined and only define it if necessary?

I am using gcc 3.4.1 with a SuSE 8.0 system.

Another thing: Is it really necessary to define true and false if
__cplusplus is defined?

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: Run in an X window - Feature request.

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

Daniel J Sebald wrote:

> For now, I just made it so that if you supply an XID number, plot 0 
> will acquire that XID and start plotting to it. 


I had to do this because the x11.trm routine X11_graphics() is always 
called.  And in there is one of the commands

#ifndef USE_MOUSE
    PRINT1("G%d\n", X11_plot_number);
#else
#ifndef OS2
    PRINT2("G%d %lu\n", X11_plot_number, windowid);
#else
    PRINT3("G%d %lu %i\n", X11_plot_number, windowid, getpid());
#endif
#endif

which implies that if a window ID is to be passed into gnuplot_x11, the 
plot in question has to be one with a plot #.

 From my way of thinking, there is really no need for x11.trm to keep 
track of the plot number.  (Or is there something there about the mouse 
that I don't understand?)  The "current_plot" is selected within 
gnuplot_x11 via the

 > set term x11 #

or

 > set term x11 window #

command.  If after that, a lone 'G' is sent across the pipe to reset the 
graphics state of the plot.  gnuplot_x11 will just use the 
'current_plot".  That's what I'm thinking anyway.

Dan

Re: Run in an X window - Feature request.

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

I can't believe it, but an initial attempt at getting gnuplot to run in 
some exterior X11 window shows positive results.

Attached is a patch, but my upfront warning is this patch is a 
proof-of-concept, out-and-out hack. (!!!)  I can clean things up for a 
better patch to start from, but I really can't think too much about the 
organization of windows and their behavior right now.  I.e., should 
numbered plots be able to accept an exterior X11 window ID?  Should 
negative plot numbers be disallowed and then inside gnuplot_x11 a 
negative number means an exterior X11 window?  Should gnuplot_x11 be 
able to close the exterior X11 windows, or should only the outside 
application be able to do so?  (I'm fairly certain that you want the 
window number at the "set term" option, because it is easy to have 
multiple exterior windows.)  Lots of questions here to consider, the 
answers of which will influence how things are programmed.  In other 
words, I think it is fairly easy to make this work, but thinking it 
through is tougher than the programming.

For now, I just made it so that if you supply an XID number, plot 0 will 
acquire that XID and start plotting to it.  The gnuplot dimensions will 
not match the application screen dimensions until you resize the 
application window.  (Some code will be needed for gnuplot_x11 to read 
the window dimensions from the existing X window rather than setting the 
dimensions after creating a window.)

Well, I tested this in Netscape (7.01), and the trick is to find the 
proper XID number, as the Netscape window has about a dozen descendents.

1)  Open a Netscape window.  Run

xwininfo -tree

click on the Netscape window and you'll see a bunch windows and 
dimensional characteristics.  You want one near the bottom of the list 
that represents the window in which one usually views webpages.  (If you 
select the parent window, gnuplot plots behind all the stuff in the 
Netscape X window.  The plots will only be visible when the window is 
resized.)  Look for the first or second window from the bottom that 
seems to have the right dimensions.  As an example, here is the output 
of a tree of my test:

xwininfo: Window id: 0x220002b "Netscape"

  Root window id: 0x4d (the root window) (has no name)
  Parent window id: 0x1019595 (has no name)
     1 child:
     0x220002c (has no name): ()  679x555+0+0  +275+22
        1 child:
        0x220002d (has no name): ()  679x555+0+0  +275+22
           1 child:
           0x220003f (has no name): ()  679x555+0+0  +275+22
              1 child:
              0x2200040 (has no name): ()  679x555+0+0  +275+22
                 3 children:
                 0x2200091 (has no name): ()  677x405+2+128  +277+150
                    1 child:
                    0x2200092 (has no name): ()  677x405+0+0  +277+150
                       1 child:
                       0x2200093 (has no name): ()  677x405+0+0  +277+150
                          1 child:
                          0x2200094 (has no name): ()  677x405+0+0  +277+150
                             1 child:
                             0x220009b (has no name): ()  677x405+0+0  
+277+150
                                1 child:
                                0x220009c (has no name): ()  
677x405+0+0  +277+150
                                   1 child:
                                   0x220009d "Gnuplot": ()  677x405+0+0  
+277+150
                 0x22000a2 (has no name): ()  1x1+290+39  +565+61
                    1 child:
                    0x22000a3 (has no name): ()  1x1+0+0  +565+61
                 0x22000a0 (has no name): ()  16x16+290+39  +565+61
                    1 child:
                    0x22000a1 (has no name): ()  16x16+0+0  +565+61

Notice the window near the bottom for which gnuplot_x11 has given it a 
name.  (It is about 150 less than the parent window in the y-dimension 
because of all the menus near the top of netscape.)

2)  So, having done the tree and finding what you think is the proper 
"view" window, start gnuplot then type

 > set term x11 window '0x220009d'
 > load 'all.dem'

where you would substitute the XID number from your tree.  Resize the 
Netscape window.

If this is what people had in mind, I can flesh out the patch (if you 
give me a proposal for how window id/plot # should be organized) and 
then pass it over to Ethan or David for SourceForge.  I don't think I 
want to maintain this one right now, even though it is probably fairly 
straightforward.

Daniel

Re: Strange bit of code in the WITH_IMAGE patchset

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

Daniel J Sebald wrote:

> Also, gnuplot seems to get a bit confused with this negative number 
> logarithm thing.


I've come across some other problems, e.g., small blips sometimes show 
up in the corners of the borders when in log scale (they're outside the 
borders, when the tics are on this inside), and I think once I somehow 
got the 'L' key action the opposite direction (coordinate system for the 
mouse seems to not match gnuplot).  It is difficult to pin down an 
replicate this, so "needs a bit of work" is all I can conclude.  I don't 
think this is a big concern right now.

Dan

Re: Strange bit of code in the WITH_IMAGE patchset

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

Petr Mikulik wrote:

>>What would be a really nice wish-list item is if the mouse position and
>>its vicinity to the axes on the plot were to select which axis to apply
>>the logarithm to.  That is, move the cross-hairs closer to the x-axis and
>>the x-axis is made logarithmic when 'l' is pressed.
>>    
>>
>
>That's not wish, that's reality: hotkey 'L'.
>Works for 'plot'.
>

Well I'll be (again)...  In some sense, it might be better to have just 
the 'L' version.  Or, more like 'l'/mouse for the spatial dimensions and 
'L' for the non-spatial dimension, i.e., color axis.  With 'l' the way 
it is, I concluded there wasn't this option of selecting the axis.

Anyway, for 'L', why is it that the y dimension logarithm can handle 
negative numbers, but the x dimension can't?  Also, gnuplot seems to get 
a bit confused with this negative number logarithm thing.  For example, 
here are a sequency of actions where I attempt a logarithm on the x axis 
having negative numbers (should I submit a bug report on this one?):

plot sin(x)

(attempted 'L' on x-axis)

gnuplot>          x range must be greater than 0 for log scale

(attempted zooming afterward)

gnuplot>
gnuplot> set xr[1.0062869233e-05:0.644869690507]; set 
yr[8.98846567431e+307:8.98846567431e+307]; set x2r[-4.99728:-0.190528]; 
set y2r[ 8.98847e+307: 8.98847e+307]
                                                                                                                                       
^
         undefined value

(attempted selecting point on plot)

gnuplot>
gnuplot> set xr[1.0062869233e-05:0.0947528474583]; set 
yr[8.98846567431e+307:8.98846567431e+307]; set x2r[-4.99728:-1.02341]; 
set y2r[ 8.98847e+307: 8.98847e+307]
                                                                                                                                       
^
         undefined value

gnuplot>
gnuplot> set xr[1.0062869233e-05:0.818279120655]; set 
yr[8.98846567431e+307:8.98846567431e+307]; set x2r[-4.99728:-0.0870985]; 
set y2r[ 8.98847e+307: 8.98847e+307]
                                                                                                                                        
^
         undefined value

gnuplot>
gnuplot> set xr[1.0062869233e-05:49.3148459717]; set 
yr[8.98846567431e+307:8.98846567431e+307]; set x2r[-4.99728: 1.69298]; 
set y2r[ 8.98847e+307: 
8.98847e+307]                                                                                                                                     
^
         undefined value

(attempted replot)

gnuplot> replot

gnuplot> plot sin(x)
                    ^
         Can't plot with an empty y range!

Re: Run in an X window - Feature request.

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

Dave Denholm wrote:

>...
>
>DestroyNotify event, serial 11, synthetic NO, window 0x700000d,
>    event 0x700000d, window 0x7000011
>
>DestroyNotify event, serial 11, synthetic NO, window 0x700000d,
>    event 0x700000d, window 0x700000d
>
>
>
>(not sure why I got it twice ..?)
>

It appears two different windows are issuing a DestroyNotify event. 
 (Perhaps those little control knobs in the upper right hand corner are 
child windows.)  First a child window is issuing the event, and then the 
window itself.  Using the -child option of xwininfo:

xwininfo: Window id: 0x1e0029a "> /home/sebald"

  Root window id: 0x4d (the root window) (has no name)
  Parent window id: 0x1000edd (has no name)
     3 children:
     0x1e002ab (has no name): ()  1x1+-1+-1  +43+401
     0x1e002a2 (has no name): ()  486x316+0+0  +44+402
     0x1e0029e (has no name): ()  15x316+489+0  +533+402

And then the xev:

DestroyNotify event, serial 13, synthetic NO, window 0x1e0029a,
    event 0x1e0029a, window 0x1e0029e

DestroyNotify event, serial 13, synthetic NO, window 0x1e0029a,
    event 0x1e0029a, window 0x1e0029a

That last child window (0x1e0029e) is issuing the initial event.  That 
would be my guess.

Dan

Re: Run in an X window - Feature request.

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

Daniel J Sebald <dan...@ie...> writes:

> Dave Denholm wrote:
>
>>>Dave Denholm wrote:
>>>
>>Also, when a client dies (disconnects), the X server will kill any
>>resources (eg windows) with an ID in the range allocated to that
>>client. So who creates the window dictates the id which dictates when
>>it gets cleaned up if either party dies. But this is a very minor
>>detail.
>>
>
> Not necessarily.  There is a X error handler in gnuplot_x11.  If when
> the outside app dies it is the one that gets the error message and
> Gnuplot never gets the error message, then that needs to be looked
> at. It could be that it causes no harm if Gnuplot thinks the window is
> still valid.
>

X error handlers are slighly different : because X is asynchronous,
errors arrive as events, rather than as replies to requests.


It may be that the X server will send an event (unmap notify ?) to all
interested parties.

Simple experiment : xev can take a window id to watch (by default it
opens a new window)

so make an xterm, use xwininfo to find its id, then

$ xev -id 0x700000d
 
to receive events from it.

Now kill the window, and lo and behold...

...

DestroyNotify event, serial 11, synthetic NO, window 0x700000d,
    event 0x700000d, window 0x7000011

DestroyNotify event, serial 11, synthetic NO, window 0x700000d,
    event 0x700000d, window 0x700000d



(not sure why I got it twice ..?)

So we should be okay here...


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

Re: Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

Petr Mikulik wrote:

>>Should configure.in issue an error message if
>>
>>--enable-with-image --disable-binary-data-file
>>
>>is selected?
>>    
>>
>
>Yes.
>  
>

OK.  I'll set it up that way.

Dan

Re: Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

> So the general rule should be BINARY_DATA_FILE can be defined
> independently, but if WITH_IMAGE is defined, BINARY_DATA_FILE must be
> defined.  Should configure.in issue an error message if
>
> --enable-with-image --disable-binary-data-file
>
> is selected?

Yes.

--
PM

Re: Run in an X window - Feature request.

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

Dave Denholm wrote:

>>Dave Denholm wrote:
>>    
>>
>Also, when a client dies (disconnects), the X server will kill any
>resources (eg windows) with an ID in the range allocated to that
>client. So who creates the window dictates the id which dictates when
>it gets cleaned up if either party dies. But this is a very minor
>detail.
>  
>

Not necessarily.  There is a X error handler in gnuplot_x11.  If when 
the outside app dies it is the one that gets the error message and 
Gnuplot never gets the error message, then that needs to be looked at. 
 It could be that it causes no harm if Gnuplot thinks the window is 
still valid.

Dan

Re: problems about endian

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

> 1) On our environment (Solaris 2.6 on SPARC machine, thus big
> endian), we had to modify
>
>  df_endianess_type df_bin_file_endianess_reset = DF_LITTLE_ENDIAN;
>
> to
>
>  df_endianess_type df_bin_file_endianess_reset = DF_BIG_ENDIAN;
>
> in datafile.c. If not so, we fail running "binary.dem". I hope
> such modification will be done automatically by configure script.

I've patched it by THIS_COMPILER_ENDIAN

> 2) Some data in demo/ seem to be for little endian, so we need
> the following modification to run "image.dem" on big endian
> environment:

Committed to cvs, thank.

---
PM

Re: problems about endian

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

Shigeharu TAKENO wrote:

>shige 09/03 2004
>----------------
>
>I tested current gnuplot of cvs version and found some problem.
>
>1) On our environment (Solaris 2.6 on SPARC machine, thus big
>endian), we had to modify 
>
> df_endianess_type df_bin_file_endianess_reset = DF_LITTLE_ENDIAN;
>
>to 
>
> df_endianess_type df_bin_file_endianess_reset = DF_BIG_ENDIAN;
>
>in datafile.c. If not so, we fail running "binary.dem". I hope
>such modification will be done automatically by configure script.
>

In this case, the binary files for binary.dem are generated on your 
machine.  So, yes the above default is a problem.  I don't think this 
needs to be done necessarily by the configure script.  Rather, changing 
the line

    df_bin_file_endianess_default = df_bin_file_endianess_reset;

inside df_unset_datafile_binary() to

    df_bin_file_endianess_default = THIS_COMPILER_ENDIAN;

Should fix matters.

>2) Some data in demo/ seem to be for little endian, so we need 
>the following modification to run "image.dem" on big endian 
>environment:
>

In this case the data files have already been created on a little endian 
machine.  This is an oversight.  I will test the patch below and add a 
fix for the issue above, then see how it behaves on your machine.

Thank you for the patch Shigeharu,

Dan


>----- from here -----
>--- demo/image.dem.ORG	Thu Sep  2 19:28:10 2004
>+++ demo/image.dem	Fri Sep  3 17:13:09 2004
>@@ -347,7 +347,7 @@
> print "displayed on the graph."
> print ""
> set title "2d binary data example where record length is part of command"
>-splot 'scatter2.bin' binary record=30,30,29,26 using 1:2:3
>+splot 'scatter2.bin' binary endian=little record=30,30,29,26 using 1:2:3
> pause -1 "Hit return to continue"
> reset
> 
>@@ -496,20 +496,20 @@
> set yrange [-1:1]
> set label 1 "Temporal data having one generated coordinate" at 2.25,1.5 center
> set title 'Along the x-axis' 0,-0.5
>-plot 'sine.bin' binary array=201 dx=0.01 origin=(0,0) format='%f' using 1 with lines
>+plot 'sine.bin' binary endian=little array=201 dx=0.01 origin=(0,0) format='%f' using 1 with lines
> unset label 1
> set size 0.5,0.48
> set origin 0.5,0.47
> set xrange [-1:1]
> set yrange [0:2]
> set title 'Along the y-axis'
>-plot 'sine.bin' binary array=201 dx=0.01 origin=(0,0) rotate=0.5pi format='%f' with lines
>+plot 'sine.bin' binary endian=little array=201 dx=0.01 origin=(0,0) rotate=0.5pi format='%f' with lines
> set size 0.5,0.48
> set origin 0.25,0.0
> set xrange [-2.2:0.7]
> set yrange [-2.2:0.7]
> set title 'Along a 225 degree projection'
>-plot 'sine.bin' binary array=201 dx=0.01 rotate=225d origin=(0,0) format='%f' using 1 with lines
>+plot 'sine.bin' binary endian=little array=201 dx=0.01 rotate=225d origin=(0,0) format='%f' using 1 with lines
> unset multiplot
> pause -1 "Hit return to continue"
> reset
>@@ -525,7 +525,7 @@
> set xrange [20:100]
> set yrange [0:800]
> set zrange [0.2:1.8]
>-splot 'scatter2.bin' binary record=30,30,29,26 origin=(25,0,0),(50,0,0),(75,0,0),(100,0,0) format='%f%f' using (0):2:3
>+splot 'scatter2.bin' binary endian=little record=30,30,29,26 origin=(25,0,0),(50,0,0),(75,0,0),(100,0,0) format='%f%f' using (0):2:3
> pause -1 "Hit return to continue"
> reset
> 
>@@ -540,7 +540,7 @@
> set xrange [20:100]
> set yrange [0:800]
> set zrange [0.2:1.8]
>-splot 'scatter2.bin' binary record=30,26 skip=360,348 origin=(50,0,0),(100,0,0) format='%f%f' using (0):2:3
>+splot 'scatter2.bin' binary endian=little record=30,26 skip=360,348 origin=(50,0,0),(100,0,0) format='%f%f' using (0):2:3
> pause -1 "Hit return to continue"
> reset
> 
>@@ -561,7 +561,7 @@
> set xrange [-1.3:1.3]
> set yrange [-1.3:1.3]
> # The sinusoid has period T=8/7.  Also, dx=0.01.  So solving 8/7 dt = 2/3 pi dx, we get dt = 0.018326.
>-plot 'sine.bin' binary array=201 dt=0.018326 origin=(0,0) format='%f' using 1 with lines
>+plot 'sine.bin' binary endian=little array=201 dt=0.018326 origin=(0,0) format='%f' using 1 with lines
> pause -1 "Hit return to continue"
> reset
> 
>@@ -745,8 +745,8 @@
> set xrange [-1.5:3.5]
> set yrange [-1.5:3.5]
> set cbrange [0:1]
>-plot '-' binary array=2x2 dx=2 format="%float" using 1:2:3 with rgbimage,\
>-     '-' binary record=4 format="%char" using 1:2 with points pt 7 ps 2 lt -1
>+plot '-' binary endian=little array=2x2 dx=2 format="%float" using 1:2:3 with rgbimage,\
>+     '-' binary endian=little record=4 format="%char" using 1:2 with points pt 7 ps 2 lt -1
> 
> pause -1 "Hit return to continue"
> reset
>----- to here -----
>+========================================================+
> Shigeharu TAKENO     NIigata Institute of Technology
>                       kashiwazaki,Niigata 945-1195 JAPAN
> sh...@ie...   TEL(&FAX): +81-257-22-8161
>+========================================================+
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: Run in an X window - Feature request.

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

Daniel J Sebald <dan...@ie...> writes:

> Dave Denholm wrote:
>
>>Daniel J Sebald <dan...@ie...> writes:
>>
>>
>>>Please explain more.  This number you give is some kind of existing X
>>>window for which gnuplot_x11 (the program that interprets the X11
>>>terminal commands) is to take over?  The application in mind is that
>>>there is some X11 window open some where and you want to launch
>>>gnuplot to construct plots within that X11 window?
>>>
>>>
>>
>>That would be my guess. An alternative would be that gnuplot should
>>create a new window whose parent is the given window. I can't think of
>>any particular benefit of the latter scheme off-hand.
>>
>
> That's what Ethan proposed.
>
>> It would be a
>>private window filling the same area as the original, which would be
>>hidden, but that just means the real window owner can't interact with
>>the gnuplot window.
>>
>
> Which is what one wants, I assume.  No?
>

Well, the thing is... if gnuplot uses the window directly, then the
application *can* choose to leave it entirely up to gnuplot, or it
*can* interact with it (eg resize it, etc).

Having gnuplot create a new window makes it harder for the app to
inteact with it if that's what it wants to do.

ie it is very easy to make a window and never touch it again. It is
slightly harder to find a new window. But the owning window would
receive events about the child being created, so it's not impossible.

Also, when a client dies (disconnects), the X server will kill any
resources (eg windows) with an ID in the range allocated to that
client. So who creates the window dictates the id which dictates when
it gets cleaned up if either party dies. But this is a very minor
detail.


>>Could even specify the root window to draw to !
>>
>>Slight hassle is making sure you use the right colormap, since it's
>>already set up.
>>
>>
>>Another way of communicating the info to gnuplot, rather than on
>>command line, would be to stash properties on the root window. Then
>>gnuplot can search for them when it starts up.
>>
>
> I'm not sure how that would work.  I'll try passing the window ID into
> an x11 window and see if I can plot to it.  Then maybe pass the patch
> on to the list for someone with more knowledge about X.
>
>>>Right now, X11 windows in gnuplot_x11 are created then saved in a
>>>linked list.  The key identifier for the list is the window number
>>>which can be specified as part of the "set term" command.  E.g.,
>>>
>>>set term x11 25
>>>
>>>What would you propose for this window number at the system command
>>>line to be organized with the window number used as part of the linked
>>>list? Just use the number you give as the plot window number in the
>>>linked list?
>>>
>>
>>
>>Could perhaps choose plot number of -1 to mean the predefined window ?
>>
>>Creating a plot with term_number -1 creates a plot structure in the
>>linked list as usual, but rather than calling pr_window() to set up
>>a new window, just set plot->window to the given id.
>>
>>


Actually, 0 (or the default) is probably better - the chances are that
someone using gnuplot in this way is not going to be using the
multiple-window mode, so it may as well use the supplied window id
directly.



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

Re: Run in an X window - Feature request.

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

On Fri, 3 Sep 2004, Donald Burns wrote:

> I'm not sure what is the best way to do it is. For my part I'm looking
> to embed gnuplot into simple tcl/tk scripts. 

In that case 'set term tkcanvas' just might be more immediately useful
than waiting for a modification to the X11 driver.

[And please, everybody, cut down quoted material to the fragment you're
actually referring to. And if remotely possible, try to follow-up *below*
quoted material, so things appear in proper reading order.]


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

Re: Run in an X window - Feature request.

[Donald B. <dm...@re...>]

Well Gentlemen, I'm touched by the enthusiasm for this simple idea.
Excuse me while I think out loud.

I'm not sure what is the best way to do it is. For my part I'm looking
to embed gnuplot into simple tcl/tk scripts. I suppose the command line
version: gnuplot --window 0xDCBA4321, is simple and very flexible. On
the other hand I intuitively feel passing it as option to the "set term
x11 window 0xDCBA4321" uses a familiar interface. Both of course would
work admirably.

For a tcl/tk interface the code to embed a gnuplot window would be
something like:-

frame .myframe				# Create a frame for gnuplot
pack .myframe				# Pack it so we can see it
set gnuplotwindow [winfo id .myframe]	# get the windows id for gnuplot
					# open gnuplot in our window
set gpfd [open "|$gnuplot --window $gnuplotwindow 2>/dev/tty" r+]

..only much more professionally written! ;-)

I hadn't appreciated that the x11 driver supported multiple windows. If
so the I would guess setting the window identifier would probably make
more sense as an option to the driver and not as a command line switch.

But here's a question. Would any sort of window do or does it have to be
a special type? One for the X windows guru's I think.

I think in the first instance a command line switch would allow us to
play see what the potential and pitfalls are. Does anybody fancy doing a
quick and dirty hack? teeheehee! :-)

On Fri, 2004-09-03 at 03:30, Daniel J Sebald wrote:
> Dave Denholm wrote:
> 
> >Daniel J Sebald <dan...@ie...> writes:
> >
> >  
> >
> >>Please explain more.  This number you give is some kind of existing X
> >>window for which gnuplot_x11 (the program that interprets the X11
> >>terminal commands) is to take over?  The application in mind is that
> >>there is some X11 window open some where and you want to launch
> >>gnuplot to construct plots within that X11 window?
> >>
> >>    
> >>
> >
> >That would be my guess. An alternative would be that gnuplot should
> >create a new window whose parent is the given window. I can't think of
> >any particular benefit of the latter scheme off-hand.
> >
> 
> That's what Ethan proposed.
> 
> > It would be a
> >private window filling the same area as the original, which would be
> >hidden, but that just means the real window owner can't interact with
> >the gnuplot window.
> >
> 
> Which is what one wants, I assume.  No?
> 
> >Could even specify the root window to draw to !
> >
> >Slight hassle is making sure you use the right colormap, since it's
> >already set up.
> >
> >
> >Another way of communicating the info to gnuplot, rather than on
> >command line, would be to stash properties on the root window. Then
> >gnuplot can search for them when it starts up.
> >
> 
> I'm not sure how that would work.  I'll try passing the window ID into 
> an x11 window and see if I can plot to it.  Then maybe pass the patch on 
> to the list for someone with more knowledge about X.
> 
> >>Right now, X11 windows in gnuplot_x11 are created then saved in a
> >>linked list.  The key identifier for the list is the window number
> >>which can be specified as part of the "set term" command.  E.g.,
> >>
> >>set term x11 25
> >>
> >>What would you propose for this window number at the system command
> >>line to be organized with the window number used as part of the linked
> >>list? Just use the number you give as the plot window number in the
> >>linked list?
> >>    
> >>
> >
> >
> >Could perhaps choose plot number of -1 to mean the predefined window ?
> >
> >Creating a plot with term_number -1 creates a plot structure in the
> >linked list as usual, but rather than calling pr_window() to set up
> >a new window, just set plot->window to the given id.
> >
> >
> >  Also, there has to be some way to check that the pointer
> >  
> >
> >>passed to gnuplot_x11, e.g., 0x0179AC5F, is valid.  Just using it as a
> >>pointer could easily crash gnuplot_x11  if someone enters a bad number
> >>at the system command line.  Is there some function for testing this
> >>in X11?
> >>
> >>    
> >>
> >
> >It isn't a pointer (probably) - it's an X ID. (If you're interested,
> >the X server assigns each client a block of ID's, and then the client
> >assigns IDs to resources as it creates them. But that's all hidden inside
> >xlib. Just allows the traffic to be mostly-client-to-server, rather
> >than requiring lots of round trips. I used to do a lot of work at
> >low-level X protocol ;-)
> >
> 
> Hey great, that will be helpful.
> 
> >You can use  xwininfo  to find the id of any window you click on.
> >
> 
> Well I'll be...  I was looking all over my window panel and window 
> manager for just such a utility.  Thank you.
> 
> Dan
> 
> 

problems about endian

[Shigeharu T. <sh...@ie...>]

shige 09/03 2004
----------------

I tested current gnuplot of cvs version and found some problem.

1) On our environment (Solaris 2.6 on SPARC machine, thus big
endian), we had to modify 

 df_endianess_type df_bin_file_endianess_reset = DF_LITTLE_ENDIAN;

to 

 df_endianess_type df_bin_file_endianess_reset = DF_BIG_ENDIAN;

in datafile.c. If not so, we fail running "binary.dem". I hope
such modification will be done automatically by configure script.

2) Some data in demo/ seem to be for little endian, so we need 
the following modification to run "image.dem" on big endian 
environment:

----- from here -----
--- demo/image.dem.ORG	Thu Sep  2 19:28:10 2004
+++ demo/image.dem	Fri Sep  3 17:13:09 2004
@@ -347,7 +347,7 @@
 print "displayed on the graph."
 print ""
 set title "2d binary data example where record length is part of command"
-splot 'scatter2.bin' binary record=30,30,29,26 using 1:2:3
+splot 'scatter2.bin' binary endian=little record=30,30,29,26 using 1:2:3
 pause -1 "Hit return to continue"
 reset
 
@@ -496,20 +496,20 @@
 set yrange [-1:1]
 set label 1 "Temporal data having one generated coordinate" at 2.25,1.5 center
 set title 'Along the x-axis' 0,-0.5
-plot 'sine.bin' binary array=201 dx=0.01 origin=(0,0) format='%f' using 1 with lines
+plot 'sine.bin' binary endian=little array=201 dx=0.01 origin=(0,0) format='%f' using 1 with lines
 unset label 1
 set size 0.5,0.48
 set origin 0.5,0.47
 set xrange [-1:1]
 set yrange [0:2]
 set title 'Along the y-axis'
-plot 'sine.bin' binary array=201 dx=0.01 origin=(0,0) rotate=0.5pi format='%f' with lines
+plot 'sine.bin' binary endian=little array=201 dx=0.01 origin=(0,0) rotate=0.5pi format='%f' with lines
 set size 0.5,0.48
 set origin 0.25,0.0
 set xrange [-2.2:0.7]
 set yrange [-2.2:0.7]
 set title 'Along a 225 degree projection'
-plot 'sine.bin' binary array=201 dx=0.01 rotate=225d origin=(0,0) format='%f' using 1 with lines
+plot 'sine.bin' binary endian=little array=201 dx=0.01 rotate=225d origin=(0,0) format='%f' using 1 with lines
 unset multiplot
 pause -1 "Hit return to continue"
 reset
@@ -525,7 +525,7 @@
 set xrange [20:100]
 set yrange [0:800]
 set zrange [0.2:1.8]
-splot 'scatter2.bin' binary record=30,30,29,26 origin=(25,0,0),(50,0,0),(75,0,0),(100,0,0) format='%f%f' using (0):2:3
+splot 'scatter2.bin' binary endian=little record=30,30,29,26 origin=(25,0,0),(50,0,0),(75,0,0),(100,0,0) format='%f%f' using (0):2:3
 pause -1 "Hit return to continue"
 reset
 
@@ -540,7 +540,7 @@
 set xrange [20:100]
 set yrange [0:800]
 set zrange [0.2:1.8]
-splot 'scatter2.bin' binary record=30,26 skip=360,348 origin=(50,0,0),(100,0,0) format='%f%f' using (0):2:3
+splot 'scatter2.bin' binary endian=little record=30,26 skip=360,348 origin=(50,0,0),(100,0,0) format='%f%f' using (0):2:3
 pause -1 "Hit return to continue"
 reset
 
@@ -561,7 +561,7 @@
 set xrange [-1.3:1.3]
 set yrange [-1.3:1.3]
 # The sinusoid has period T=8/7.  Also, dx=0.01.  So solving 8/7 dt = 2/3 pi dx, we get dt = 0.018326.
-plot 'sine.bin' binary array=201 dt=0.018326 origin=(0,0) format='%f' using 1 with lines
+plot 'sine.bin' binary endian=little array=201 dt=0.018326 origin=(0,0) format='%f' using 1 with lines
 pause -1 "Hit return to continue"
 reset
 
@@ -745,8 +745,8 @@
 set xrange [-1.5:3.5]
 set yrange [-1.5:3.5]
 set cbrange [0:1]
-plot '-' binary array=2x2 dx=2 format="%float" using 1:2:3 with rgbimage,\
-     '-' binary record=4 format="%char" using 1:2 with points pt 7 ps 2 lt -1
+plot '-' binary endian=little array=2x2 dx=2 format="%float" using 1:2:3 with rgbimage,\
+     '-' binary endian=little record=4 format="%char" using 1:2 with points pt 7 ps 2 lt -1
 
 pause -1 "Hit return to continue"
 reset
----- to here -----
+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Strange bit of code in the WITH_IMAGE patchset

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

> What would be a really nice wish-list item is if the mouse position and
> its vicinity to the axes on the plot were to select which axis to apply
> the logarithm to.  That is, move the cross-hairs closer to the x-axis and
> the x-axis is made logarithmic when 'l' is pressed.

That's not wish, that's reality: hotkey 'L'.
Works for 'plot'.

---
PM

Re: Strange bit of code in the WITH_IMAGE patchset

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

> The attached bit of code from mouse.c looks really odd.
>
> Is there really a reason for changing the behaviour of the
> 'l' hot-key (toggle log scale) depending on whether
> WITH_IMAGE is configured in or not?  If I understand
> correctly what this code does, it is now impossible to
> toggle the y-axis log scale if your current plot contains
> image data.   Is that intended?

The behaviour is intended, and it is similar to functionality of the 'l'
hotkey for 'splot'.

For 'plot with image', it makes really no sense to use log x/y axis.

Note that in 'plot' you can individually select an axis for being logged by
'L' + mouse position.

---
PM

Re: Run in an X window - Feature request.

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

Dave Denholm wrote:

>Daniel J Sebald <dan...@ie...> writes:
>
>  
>
>>Please explain more.  This number you give is some kind of existing X
>>window for which gnuplot_x11 (the program that interprets the X11
>>terminal commands) is to take over?  The application in mind is that
>>there is some X11 window open some where and you want to launch
>>gnuplot to construct plots within that X11 window?
>>
>>    
>>
>
>That would be my guess. An alternative would be that gnuplot should
>create a new window whose parent is the given window. I can't think of
>any particular benefit of the latter scheme off-hand.
>

That's what Ethan proposed.

> It would be a
>private window filling the same area as the original, which would be
>hidden, but that just means the real window owner can't interact with
>the gnuplot window.
>

Which is what one wants, I assume.  No?

>Could even specify the root window to draw to !
>
>Slight hassle is making sure you use the right colormap, since it's
>already set up.
>
>
>Another way of communicating the info to gnuplot, rather than on
>command line, would be to stash properties on the root window. Then
>gnuplot can search for them when it starts up.
>

I'm not sure how that would work.  I'll try passing the window ID into 
an x11 window and see if I can plot to it.  Then maybe pass the patch on 
to the list for someone with more knowledge about X.

>>Right now, X11 windows in gnuplot_x11 are created then saved in a
>>linked list.  The key identifier for the list is the window number
>>which can be specified as part of the "set term" command.  E.g.,
>>
>>set term x11 25
>>
>>What would you propose for this window number at the system command
>>line to be organized with the window number used as part of the linked
>>list? Just use the number you give as the plot window number in the
>>linked list?
>>    
>>
>
>
>Could perhaps choose plot number of -1 to mean the predefined window ?
>
>Creating a plot with term_number -1 creates a plot structure in the
>linked list as usual, but rather than calling pr_window() to set up
>a new window, just set plot->window to the given id.
>
>
>  Also, there has to be some way to check that the pointer
>  
>
>>passed to gnuplot_x11, e.g., 0x0179AC5F, is valid.  Just using it as a
>>pointer could easily crash gnuplot_x11  if someone enters a bad number
>>at the system command line.  Is there some function for testing this
>>in X11?
>>
>>    
>>
>
>It isn't a pointer (probably) - it's an X ID. (If you're interested,
>the X server assigns each client a block of ID's, and then the client
>assigns IDs to resources as it creates them. But that's all hidden inside
>xlib. Just allows the traffic to be mostly-client-to-server, rather
>than requiring lots of round trips. I used to do a lot of work at
>low-level X protocol ;-)
>

Hey great, that will be helpful.

>You can use  xwininfo  to find the id of any window you click on.
>

Well I'll be...  I was looking all over my window panel and window 
manager for just such a utility.  Thank you.

Dan

Re: Run in an X window - Feature request.

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

Daniel J Sebald <dan...@ie...> writes:

> Donald Burns wrote:
>
>>Hi there,
>>
>>I've been using gnuplot since about 1998 and I have to say it is one of
>>my favourite bits of software! Well done to all concerned!
>>
>>I often end up gluing together bits of software to make test rigs and
>>the like and it strikes me  that a couple of features would be really
>>nifty.
>>
>>- Being able to specify at execution time an X window in which to open
>>the X11 driver. Something like:- gnuplot --window 0x0179AC5F This would
>>allow very simple embeding in other applications.
>>
>
> Please explain more.  This number you give is some kind of existing X
> window for which gnuplot_x11 (the program that interprets the X11
> terminal commands) is to take over?  The application in mind is that
> there is some X11 window open some where and you want to launch
> gnuplot to construct plots within that X11 window?
>

That would be my guess. An alternative would be that gnuplot should
create a new window whose parent is the given window. I can't think of
any particular benefit of the latter scheme off-hand. It would be a
private window filling the same area as the original, which would be
hidden, but that just means the real window owner can't interact with
the gnuplot window.


Could even specify the root window to draw to !

Slight hassle is making sure you use the right colormap, since it's
already set up.


Another way of communicating the info to gnuplot, rather than on
command line, would be to stash properties on the root window. Then
gnuplot can search for them when it starts up.


> Right now, X11 windows in gnuplot_x11 are created then saved in a
> linked list.  The key identifier for the list is the window number
> which can be specified as part of the "set term" command.  E.g.,
>
> set term x11 25
>
> What would you propose for this window number at the system command
> line to be organized with the window number used as part of the linked
> list? Just use the number you give as the plot window number in the
> linked list?


Could perhaps choose plot number of -1 to mean the predefined window ?

Creating a plot with term_number -1 creates a plot structure in the
linked list as usual, but rather than calling pr_window() to set up
a new window, just set plot->window to the given id.


  Also, there has to be some way to check that the pointer
> passed to gnuplot_x11, e.g., 0x0179AC5F, is valid.  Just using it as a
> pointer could easily crash gnuplot_x11  if someone enters a bad number
> at the system command line.  Is there some function for testing this
> in X11?
>

It isn't a pointer (probably) - it's an X ID. (If you're interested,
the X server assigns each client a block of ID's, and then the client
assigns IDs to resources as it creates them. But that's all hidden inside
xlib. Just allows the traffic to be mostly-client-to-server, rather
than requiring lots of round trips. I used to do a lot of work at
low-level X protocol ;-)



You can use  xwininfo  to find the id of any window you click on.

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

Re: Run in an X window - Feature request.

[Donald B. <dm...@re...>]

On Thu, 2004-09-02 at 17:34, Ethan Merritt wrote:
> On Thursday 02 September 2004 09:00 am, Donald Burns wrote:
> >
> > - Being able to specify at execution time an X window in which to open
> > the X11 driver. Something like:- gnuplot --window 0x0179AC5F This would
> > allow very simple embeding in other applications.
> 
> That does indeed sound like a nice idea.
> Please log it as a Request For Enhancement on the SourceForge site,
> and someone will probably look into it.

I'll do that.
> 
> > - The ability to turn off the gnu readline input such that operation
> > down a pipe is reliable. At the moment I have two versions of gnuplot
> > kicking round: both with and without gnu readline.

> Which versions would those be, and what exactly goes wrong if
> you use gnu readline?   This sounds more like a bug report than
> a feature request, but you'll have to be more specific about 
> exactly what the bug is.  Ideally you would provide a simple test
> case that works with the built-in readline but fails with libreadline.
> That way we can actually have some way of debugging it.

The 3.7, 3.8 and 4.0 gnuplots hang on the pipe when using gnu readline.
And I have an idea this is docummented somewhere. The bug is in readline
I believe which use the select system call if I'm not mistaken.  

I will try and put together some simple TCL code that illustrates the
point.

Many Thanks

Donald.

Re: Run in an X window - Feature request.

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

Donald Burns wrote:

>Hi there,
>
>I've been using gnuplot since about 1998 and I have to say it is one of
>my favourite bits of software! Well done to all concerned!
>
>I often end up gluing together bits of software to make test rigs and
>the like and it strikes me  that a couple of features would be really
>nifty.
>
>- Being able to specify at execution time an X window in which to open
>the X11 driver. Something like:- gnuplot --window 0x0179AC5F This would
>allow very simple embeding in other applications.
>

Please explain more.  This number you give is some kind of existing X 
window for which gnuplot_x11 (the program that interprets the X11 
terminal commands) is to take over?  The application in mind is that 
there is some X11 window open some where and you want to launch gnuplot 
to construct plots within that X11 window?

Right now, X11 windows in gnuplot_x11 are created then saved in a linked 
list.  The key identifier for the list is the window number which can be 
specified as part of the "set term" command.  E.g.,

set term x11 25

What would you propose for this window number at the system command line 
to be organized with the window number used as part of the linked list? 
 Just use the number you give as the plot window number in the linked 
list?  Also, there has to be some way to check that the pointer passed 
to gnuplot_x11, e.g., 0x0179AC5F, is valid.  Just using it as a pointer 
could easily crash gnuplot_x11  if someone enters a bad number at the 
system command line.  Is there some function for testing this in X11?

Dan

Re: Run in an X window - Feature request.

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

On Thursday 02 September 2004 09:00 am, Donald Burns wrote:
>
> - Being able to specify at execution time an X window in which to open
> the X11 driver. Something like:- gnuplot --window 0x0179AC5F This would
> allow very simple embeding in other applications.

That does indeed sound like a nice idea.
Please log it as a Request For Enhancement on the SourceForge site,
and someone will probably look into it.

> - The ability to turn off the gnu readline input such that operation
> down a pipe is reliable. At the moment I have two versions of gnuplot
> kicking round: both with and without gnu readline.

Which versions would those be, and what exactly goes wrong if
you use gnu readline?   This sounds more like a bug report than
a feature request, but you'll have to be more specific about 
exactly what the bug is.  Ideally you would provide a simple test
case that works with the built-in readline but fails with libreadline.
That way we can actually have some way of debugging it.

Re: Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

Ethan Merritt wrote:

>On Thursday 02 September 2004 01:51 am, Daniel J Sebald wrote:
>  
>
>>Daniel J Sebald wrote:
>>    
>>
>>>Ethan A Merritt wrote:
>>>      
>>>
>>>>Is it intended to allow
>>>>    ./configure --enable-with-image --disable-binary-data-file
>>>>
>>>>If so, I suspect the following bit of code in plot2d.c will break
>>>>        
>>>>
>
>[which apparently it does]
>
>  
>
>>>So going beyond the attached patch to make images work with the old
>>>matrix/binary code would mean tacking in a few lines in df_3dmatrix.
>>>But that means passing in information about the plot style to
>>>df_3dmatrix().  That brings us back to the philosophical discussion of
>>>how best to do that in an organized fashion... 
>>>      
>>>
>
>I think the simpler thing is just to acknowledge that images are
>intrinsically binary data, and set it up so that the specific configuration
>command above is not accepted.  If you want image support, you
>also need to select binary file support.
>  
>

I have no problem with that approach.  [However, one can still enter 
data in (x,y,i) triples to use the image plot style, e.g.,

0  0  0.32
0  1  0.28
0  2  0.25
1  0  0.35
1  1  0.27
...

so there is some way of using images without having to require matrix 
binary or matrix ascii.]  I agree, the image plot style is of limited 
use without the more versatile binary file features.

So the general rule should be BINARY_DATA_FILE can be defined 
independently, but if WITH_IMAGE is defined, BINARY_DATA_FILE must be 
defined.  Should configure.in issue an error message if

--enable-with-image --disable-binary-data-file

is selected?  Or should BINARY_DATA_FILE be forced true whenever 
WITH_IMAGE is activated?

Dan