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

Re: pgnuplot+wgnuplot does not accept binary from pipe

[Tatsuro M. <tma...@ya...>]

Hello Hans


Thank you for your explanation.

> It has to be pointed out that this document is not specific to wgnuplot. 
>   "help plot data binary" is the same for all versions of gnuplot on all 
> platforms

I have known it. However, since the wgnuplot does not accept the binary data from the pipe, it should
be stated somewhere.
Can you add a sentense like the following?

In case of wgnuplot, the binary data from the pipe cannot be accepted due to the limitation of its
interative console.


> The snapshot doesn't actually show that.  What you're looking at is 
> wgnuplot trying to read all bytes you promised it.  But some apparently 
> got eaten.
> 
> The problem boils down to this: wgnuplot doesn't really have a 
> non-interactive mode the same way other platforms do, and binary data 
> cannot really be in-lined, because they lack a recognizable EOF.

I understand completely.  I will think another way to send data to the wguplot.  Perhaps I have to use
a file.

Thanks a lot!!

Regards

Tatsuro
 


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

gp422os2

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

Finally I've got working my favourite OS/2 Warp again ... under qemu 0.9.0 
on OpenSUSE. It needed to replace IBM's DASD and S506 disk drivers by those 
from Daniela Engert (the two famous dani*.zip), and now the old hard disk 
image can be up and running.

I've recompiled gnuplot 4.2.2 (including the latest fixes) for OS/2. I wish 
somebody with the appropriate rights puts
  http://gnuplot.sourceforge.net/development/binaries/gp422os2.zip
into the Download section on SourceForge.

The binary has been tested by another OS/2 user and all the demos passed.
Thanks to let me know the latest gnuplot version is really needed!

Currently, only the "pause mouse" including "pause mouse key" are not 
implemented. I've filled in bug report
#1886635 "OS/2: pause mouse not implemented".

---
PM

Re: svg terminal is unsupported in djgpp gnuplot 4.2.2

[Hans-Bernhard B. <HBB...@t-...>]

Tatsuro MATSUOKA wrote:
> gnuplot> set term svg
>                   ^
>          unknown or ambiguous terminal type; type just 'set terminal' for a list
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>          
> Is this a bug ?

Not quite.  It's a completely accurate message: in this gnuplot binary, 
'svg' is an ambiguous terminal name.  It could match either 'svga' or 
'svg'.  And somebody decided that gnuplot should output an error message 
in this case.

The code is supposed to be able to recognize an exact match and report 
it in spite of the ambiguity, but somehow this failed.

Re: pgnuplot+wgnuplot does not accept binary from pipe

[Hans-Bernhard B. <HBB...@t-...>]

Tatsuro MATSUOKA wrote:

> In the help of the wgnuplot, Plot-data-BINARY DATA FILES: 

It has to be pointed out that this document is not specific to wgnuplot. 
  "help plot data binary" is the same for all versions of gnuplot on all 
platforms.

> see the snapshot : wgplt080204.png at
> http://www.geocities.jp/tmgpltwin/Files/Files.html

> After wgnuplot stopped, it cannot accept code nor keybord anymore.

The snapshot doesn't actually show that.  What you're looking at is 
wgnuplot trying to read all bytes you promised it.  But some apparently 
got eaten.

The problem boils down to this: wgnuplot doesn't really have a 
non-interactive mode the same way other platforms do, and binary data 
cannot really be in-lined, because they lack a recognizable EOF.

Re: svg terminal is unsupported in djgpp gnuplot 4.2.2 (Sorry again)

[Tatsuro M. <tma...@ya...>]

Hi

Sorry my careless writing mail again.
Please ignore the previous one.
**************
My previous mail is lack of care.
Excure me for that.
>I somtimes use djgpp gnuplot 4.2.2 because it is light and
> it accepts pipe completely unlike pgnuplot+wgnuplot. 

I do not want to say pgnuplot is meaningless.
It is a very important tool for realizing pipe in the windows environments.

However, its potential is limited. For examle, I cannot the output result from the pipe.
I wrote the successive plots C program using pipe.
Because the pipe realized by pgnuplot is only forwarding the command and I could not get the any
information of gnuplot message from the pipe.  This prevented me to judge whether plot was done or not
from pipe. I instead wrote a dummy file making code like "set out 'dummy'; set out"  after plot
command in the gnuplot script and waited for dummy file made by while loop in C code.

If I colud get message of gnuplot from the pipe, 
the program should be more simple and comprehensive.

What I would like to say is the followings:

The combination of the pgnuplot and the wgnuplot does not equal to the console mode gnuplot from the
view point of the pipe operation.  That fact should be described in the help or some documents in the
gnuplot.


Because I did not know the fact, I was confused.  After I read the code of pgnuplot, I realized the
fact. After that I wrote the tricky code to overcome the problem.
However the fact is written in the gnuplot documents.  Perhaps I did not confused.
I did write from the first the code using dummy file.


My hope is only, it is documented, no further modifications of wgnuplot are desired.

Regards

Tatsuro


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: svg terminal is unsupported in djgpp gnuplot 4.2.2

[Tatsuro M. <tma...@ya...>]

Hi

My previous mail is lack of care.
Excure me for that.
> I somtimes use djgpp gnuplot 4.2.2 because it is light and
>  it accepts pipe completely unlike pgnuplot+wgnuplot. 

I do not want to say pgnuplot is meaningless.
It is a very important tool for realising pipe in the windows environments.

However, its potail is limited. For examle, I cannot the output result from the pipe.
Sometimes it is important to write the succesive plot from C program using pipe.
I could not judge whether plot is done or not from pipe. I instead wrote a dummy file making code
(like "set out 'dummy'; set out" ) after plot command in the gnuplot script and wait by while loop to
confirm the file 'dummy' is produced.

What I would like to say that it should be stated that the combination of the pgnuplot and the
wgnuplot does not equal to the console mode gnuplot in the help or some documents in the gnuplot.

Regards

Tatsuro

  


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

svg terminal is unsupported in djgpp gnuplot 4.2.2

[Tatsuro M. <tma...@ya...>]

Hi

I somtimes use djgpp gnuplot 4.2.2 because it is light and
 it accepts pipe completely unlike pgnuplot+wgnuplot. 

I found one contradiction in the djgpp gnuplot 4.2.2 .

I executed 'set terminal' to see Available terminal types.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
gnuplot> set terminal

Available terminal types:
             aifm  Adobe Illustrator 3.0 Format
              cgm  Computer Graphics Metafile
            corel  EPS format for CorelDRAW
             dumb  ascii art for anything that prints text
              dxf  dxf-file for AutoCad (default size 120x80)
            eepic  EEPIC -- extended LaTeX picture environment
              emf  Enhanced Metafile format
            emtex  LaTeX picture environment with emTeX specials
         epslatex  LaTeX picture environment using graphicx package
     epson_180dpi  Epson LQ-style 180-dot per inch (24 pin) printers
      epson_60dpi  Epson-style 60-dot per inch printers
      epson_lx800  Epson LX-800, Star NL-10, NX-1000, PROPRINTER ...
              fig  FIG graphics language for XFIG graphics editor
          hp2623A  HP2623A and maybe others
           hp2648  HP2648 and HP2647
           hp500c  HP DeskJet 500c, [75 100 150 300] [rle tiff]
             hpdj  HP DeskJet 500, [75 100 150 300]
             hpgl  HP7475 and relatives [number of pens] [eject]
           hpljii  HP Laserjet series II, [75 100 150 300]
             hppj  HP PaintJet and HP3630 [FNT5X9 FNT9X17 FNT13X25]
           imagen  Imagen laser printer
Press return for more:
            latex  LaTeX picture environment
               mf  Metafont plotting standard
              mif  Frame maker MIF 3.00 format
               mp  MetaPost plotting standard
          nec_cp6  NEC printer CP6, Epson LQ-800 [monocrome color draft]
          okidata  OKIDATA 320/321 Standard
              pbm  Portable bitmap [small medium large] [monochrome gray color]
             pcl5  HP Designjet 750C, HP Laserjet III/IV, etc. (many options)
       postscript  PostScript graphics, including EPSF embedded files (*.eps)
          pslatex  LaTeX picture environment with PostScript \specials
            pstex  plain TeX with PostScript \specials
         pstricks  LaTeX picture environment with PSTricks macros
              qms  QMS/QUIC Laser printer (also Talaris 1200 and others)
            starc  Star Color Printer
              svg  W3C Scalable Vector Graphics driver
             svga  IBM PC/Clone with Super VGA graphics board ["fontname"]
      tandy_60dpi  Tandy DMP-130 series 60-dot per inch graphics
          texdraw  LaTeX texdraw environment
             tgif  TGIF X11 [mode] [x,y] [dashed] ["font" [fontsize]]
         tkcanvas  Tk/Tcl canvas widget [perltk] [interactive]
             tpic  TPIC -- LaTeX picture environment with tpic \specials
          unknown  Unknown terminal type - not a plotting device
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++          


There lists:
      svg  W3C Scalable Vector Graphics driver

However          
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
gnuplot> set term svg
                  ^
         unknown or ambiguous terminal type; type just 'set terminal' for a list
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
         
Is this a bug ?

++++++++++++++++++++++++++++++++++
Evironments
gnuplot 4.2.2 djgpp on Win XP(pro and Personal)

Regards

Tatsuro



--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: pgnuplot+wgnuplot does not accept binary from pipe (error correction)

[Tatsuro M. <tma...@ya...>]

Hi
This is just a error correction.
Sorry for my carelessness.

> see the snapshot : wgplt080204.png at
> http://www.geocities.jp/tmgpltwin/Files/Files.htm

> see the snapshot : wgplt080204.png at
> http://www.geocities.jp/tmgpltwin/Files/Files.html


--- Tatsuro MATSUOKA <tma...@ya...> wrote:
Hi 

In the help of the wgnuplot, Plot-data-BINARY DATA FILES: 

General binary data can be entered at the command line via the special file name '-'.  However,
this
is intended for use through a pipe where programs can exchange binary data, not for keyboards.  

However this could not be done for  pgnuplot+wgnuplot.
I sent the data from the octave via pipe to pgnuplot.
The pgnuplot merely sends data a byte by a byte using win32 api to wgnuplot.
So this phenomenon comes from wgnuplot.

see the snapshot : wgplt080204.png at
http://www.geocities.jp/tmgpltwin/Files/Files.htm
(http://www.geocities.jp/tmgpltwin/Files/Files.html)

After wgnuplot stopped, it cannot accept code nor keybord anymore.

If this is the limitation of wgnuplot, please rewrite the help of the above for the wgnuplot.

Environment
wgnuplot 4.2.2 on winXP(personal)

Regards

Tatsuro



--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gnuplot-beta mailing list
gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta



--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

pgnuplot+wgnuplot does not accept binary from pipe

[Tatsuro M. <tma...@ya...>]

Hi 

In the help of the wgnuplot, Plot-data-BINARY DATA FILES: 

General binary data can be entered at the command line via the special file name '-'.  However, this
is intended for use through a pipe where programs can exchange binary data, not for keyboards.  

However this could not be done for  pgnuplot+wgnuplot.
I sent the data from the octave via pipe to pgnuplot.
The pgnuplot merely sends data a byte by a byte using win32 api to wgnuplot.
So this phenomenon comes from wgnuplot.

see the snapshot : wgplt080204.png at
http://www.geocities.jp/tmgpltwin/Files/Files.htm

After wgnuplot stopped, it cannot accept code nor keybord anymore.

If this is the limitation of wgnuplot, please rewrite the help of the above for the wgnuplot.

Environment
wgnuplot 4.2.2 on winXP(personal)

Regards

Tatsuro



--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: linux svga terminals

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

On Friday 01 February 2008 15:41, Don Taber wrote:
> The linux and vgagl terminals for the Linux console use
> svgalib.  Older versions of svgalib required that binaries
> linked to it be installed suid to access the video hardware.
> Gnuplot will not make the linux terminals available if 
> getuid returns nonzero.
> 
> However, recent versions of svgalib (1.9.x) employ a kernel
> module (svgalib_helper.ko) and binaries linking it do not
> need to be installed suid.  Typical installations will
> create a udev rule like:
> 
> KERNEL=="svga*", NAME="%k", MODE="0660", GROUP="video"
> 
> So to give nonroot users console video access, you just
> create a "video" group and add them to it.

That's interesting. I wouldn't have thought group access
was sufficient.

Be that as it may, the bigger question is "Does it work?"
In 8 years of periodic tries, with a serious effort at the
time of the 4.0 and 4.2 releases, I have never once managed
to build a working version of svgalib support into gnuplot.
It either does nothing useful, locks up the machine, or
scribbles random garbage on the screen.

I would be delighted if you are willing to send me privately
a working linux executable, so I can at least see how it is
_supposed_ to work.

What's your secret recipe?

	Ethan
 
> I have added an additional configuration step when deciding
> to compile in the linux terminal.  If --with-linux-vga is
> requested and the library successfully found, I then
> check for the availability of the kernel module.  If that
> test is successfull, I define an additional symbol to be
> inserted in config.h, SVGALIB_HELPER.  When is defined
> code related to checking euid and toggling root
> privileges is not compiled.
> 
> I am no kind of autoconf guru, but I think I did it right.
> I patched configure.in and config.hin.  It works fine
> for me with a 2.6 kernel and svgalib 1.9.25, and I don't
> think it will break anything.  But someone with
> genuine (TM) autoconf knowledge should check it.
> 
> Patch against recent CVS follows.
> 
> Don Taber
> -----------------------------------------------------------
> 
> 
> diff -ru gnuplot.orig/config.hin gnuplot/config.hin
> --- gnuplot.orig/config.hin	2008-02-01 12:42:11.000000000 -0800
> +++ gnuplot/config.hin	2008-02-01 12:39:23.000000000 -0800
> @@ -395,6 +395,9 @@
>  /* Define if this is a Linux system with SuperVGA library. */
>  #undef LINUXVGA
>  
> +/* Define if svgalib uses svgalib_helper kernel module. */
> +#undef SVGALIB_HELPER
> +
>  /* Define if you want to use the MGR Window system. */
>  #undef MGR
>  
> diff -ru gnuplot.orig/configure.in gnuplot/configure.in
> --- gnuplot.orig/configure.in	2008-02-01 12:44:55.000000000 -0800
> +++ gnuplot/configure.in	2008-02-01 12:39:18.000000000 -0800
> @@ -228,6 +228,11 @@
>       LINUXSUID='chown root $(bindir)/gnuplot; chmod u+s $(bindir)/gnuplot'
>       TERMLIBS="-lvga $TERMLIBS"],
>      with_linux_vga=no)
> +  if modprobe -n svgalib_helper ; then
> +     with_svgalib_helper=yes
> +     AC_DEFINE(SVGALIB_HELPER,1,
> +               [ Define if svgalib uses svgalib_helper kernel module. ])
> +  fi
>  fi
>  
>  dnl TODO: simplify, get rid of GGI_SUPPORT
> @@ -1143,7 +1148,9 @@
>    else
>      AC_MSG_RESULT([  vgagl terminal ((s)vga console): no (requires vgagl)])
>    fi
> -  AC_MSG_RESULT([    SECURITY NOTICE: SVGAlib requires that gnuplot is installed suid root!])
> +  if test "$with_svgalib_helper" != yes; then
> +     AC_MSG_RESULT([    SECURITY NOTICE: SVGAlib without kernel helper module requires that gnuplot is installed suid root!])
> +  fi
>  else
>    AC_MSG_RESULT([  linux terminal (vga console): no (use --with-linux-vga to enable,])
>    AC_MSG_RESULT([                                       requires SVGAlib)])
> diff -ru gnuplot.orig/src/plot.c gnuplot/src/plot.c
> --- gnuplot.orig/src/plot.c	2008-02-01 12:42:28.000000000 -0800
> +++ gnuplot/src/plot.c	2008-02-01 12:40:11.000000000 -0800
> @@ -285,8 +285,10 @@
>  
>  #ifdef LINUXVGA
>      LINUX_setup();		/* setup VGA before dropping privilege DBT 4/5/99 */
> +#ifndef SVGALIB_HELPER
>      drop_privilege();
>  #endif
> +#endif
>  /* make sure that we really have revoked root access, this might happen if
>     gnuplot is compiled without vga support but is installed suid by mistake */
>  #ifdef __linux__
> diff -ru gnuplot.orig/term/linux.trm gnuplot/term/linux.trm
> --- gnuplot.orig/term/linux.trm	2008-02-01 12:42:42.000000000 -0800
> +++ gnuplot/term/linux.trm	2008-02-01 12:39:57.000000000 -0800
> @@ -122,8 +122,10 @@
>  
>      LINUX_graphics_allowed = FALSE;
>  
> +#ifndef SVGALIB_HELPER
>      if (geteuid() != 0)
>  	return;			/* if we aren't root, we cannot init graphics */
> +#endif
>  
>      if ((pipe = popen("/usr/bin/tty", "r")) != NULL) {
>  	line[0] = 0;
> @@ -152,9 +154,13 @@
>  	}
>      }
>      if (LINUX_graphics_allowed) {
> +#ifndef SVGALIB_HELPER
>  	take_privilege();
> +#endif
>  	vga_init();
> +#ifndef SVGALIB_HELPER
>  	drop_privilege();
> +#endif
>      } else {
>  	/* err - shouldn't we give up root uid whatever happens ?
>  	 * or perhaps vga_init() does it ?
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

linux svga terminals

[Don T. <dt...@to...>]

The linux and vgagl terminals for the Linux console use
svgalib.  Older versions of svgalib required that binaries
linked to it be installed suid to access the video hardware.
Gnuplot will not make the linux terminals available if 
getuid returns nonzero.

However, recent versions of svgalib (1.9.x) employ a kernel
module (svgalib_helper.ko) and binaries linking it do not
need to be installed suid.  Typical installations will
create a udev rule like:

KERNEL=="svga*", NAME="%k", MODE="0660", GROUP="video"

So to give nonroot users console video access, you just
create a "video" group and add them to it.

I have added an additional configuration step when deciding
to compile in the linux terminal.  If --with-linux-vga is
requested and the library successfully found, I then
check for the availability of the kernel module.  If that
test is successfull, I define an additional symbol to be
inserted in config.h, SVGALIB_HELPER.  When is defined
code related to checking euid and toggling root
privileges is not compiled.

I am no kind of autoconf guru, but I think I did it right.
I patched configure.in and config.hin.  It works fine
for me with a 2.6 kernel and svgalib 1.9.25, and I don't
think it will break anything.  But someone with
genuine (TM) autoconf knowledge should check it.

Patch against recent CVS follows.

Don Taber
-----------------------------------------------------------


diff -ru gnuplot.orig/config.hin gnuplot/config.hin
--- gnuplot.orig/config.hin	2008-02-01 12:42:11.000000000 -0800
+++ gnuplot/config.hin	2008-02-01 12:39:23.000000000 -0800
@@ -395,6 +395,9 @@
 /* Define if this is a Linux system with SuperVGA library. */
 #undef LINUXVGA
 
+/* Define if svgalib uses svgalib_helper kernel module. */
+#undef SVGALIB_HELPER
+
 /* Define if you want to use the MGR Window system. */
 #undef MGR
 
diff -ru gnuplot.orig/configure.in gnuplot/configure.in
--- gnuplot.orig/configure.in	2008-02-01 12:44:55.000000000 -0800
+++ gnuplot/configure.in	2008-02-01 12:39:18.000000000 -0800
@@ -228,6 +228,11 @@
      LINUXSUID='chown root $(bindir)/gnuplot; chmod u+s $(bindir)/gnuplot'
      TERMLIBS="-lvga $TERMLIBS"],
     with_linux_vga=no)
+  if modprobe -n svgalib_helper ; then
+     with_svgalib_helper=yes
+     AC_DEFINE(SVGALIB_HELPER,1,
+               [ Define if svgalib uses svgalib_helper kernel module. ])
+  fi
 fi
 
 dnl TODO: simplify, get rid of GGI_SUPPORT
@@ -1143,7 +1148,9 @@
   else
     AC_MSG_RESULT([  vgagl terminal ((s)vga console): no (requires vgagl)])
   fi
-  AC_MSG_RESULT([    SECURITY NOTICE: SVGAlib requires that gnuplot is installed suid root!])
+  if test "$with_svgalib_helper" != yes; then
+     AC_MSG_RESULT([    SECURITY NOTICE: SVGAlib without kernel helper module requires that gnuplot is installed suid root!])
+  fi
 else
   AC_MSG_RESULT([  linux terminal (vga console): no (use --with-linux-vga to enable,])
   AC_MSG_RESULT([                                       requires SVGAlib)])
diff -ru gnuplot.orig/src/plot.c gnuplot/src/plot.c
--- gnuplot.orig/src/plot.c	2008-02-01 12:42:28.000000000 -0800
+++ gnuplot/src/plot.c	2008-02-01 12:40:11.000000000 -0800
@@ -285,8 +285,10 @@
 
 #ifdef LINUXVGA
     LINUX_setup();		/* setup VGA before dropping privilege DBT 4/5/99 */
+#ifndef SVGALIB_HELPER
     drop_privilege();
 #endif
+#endif
 /* make sure that we really have revoked root access, this might happen if
    gnuplot is compiled without vga support but is installed suid by mistake */
 #ifdef __linux__
diff -ru gnuplot.orig/term/linux.trm gnuplot/term/linux.trm
--- gnuplot.orig/term/linux.trm	2008-02-01 12:42:42.000000000 -0800
+++ gnuplot/term/linux.trm	2008-02-01 12:39:57.000000000 -0800
@@ -122,8 +122,10 @@
 
     LINUX_graphics_allowed = FALSE;
 
+#ifndef SVGALIB_HELPER
     if (geteuid() != 0)
 	return;			/* if we aren't root, we cannot init graphics */
+#endif
 
     if ((pipe = popen("/usr/bin/tty", "r")) != NULL) {
 	line[0] = 0;
@@ -152,9 +154,13 @@
 	}
     }
     if (LINUX_graphics_allowed) {
+#ifndef SVGALIB_HELPER
 	take_privilege();
+#endif
 	vga_init();
+#ifndef SVGALIB_HELPER
 	drop_privilege();
+#endif
     } else {
 	/* err - shouldn't we give up root uid whatever happens ?
 	 * or perhaps vga_init() does it ?

Re: bug in histogram plot with binary data?

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

On Friday 01 February 2008 00:29, Daniel J Sebald wrote:
> 
> I believe your fix is correct.  Feel free to check it in...

OK. Will do.

	Thanks


-- 
Ethan A Merritt

Re: No redraw with wxt and 'noraise'

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

> > I can understand where this may come from, but I have not been able to
> > reproduce it on my machine...
> 
> wxWidgets-devel: 2.8.4-0
> wxGTK: 2.6.3.3-30

I can also observer such a behaviour for "set term wx" ... only sometimes, 
not very reproducible ... just try a lot of "splot x", "splot 100*x", "splot 
y" commands with different time delay between entering these commands ... 
then sometimes the graph is not redrawn.

OpenSUSE 10.3, KDE 3.5.7, and:
wxWidgets-2.8.7-0.pm.1
wxGTK-compat-2.8.4.0-53
wxGTK-devel-2.8.4.0-53
wxGTK-2.8.4.0-53
pango-1.18.2-4
pango-devel-1.18.2-4
cairo-1.4.10-25
cairo-devel-1.4.10-25

---
PM

Re: bug in histogram plot with binary data?

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

Ethan Merritt wrote:
> Dan:
> 
> The binary data file supposedly contains 1 set of 7 points
> (yes the original poster counted wrong but it shouldn't matter since
> the error is on the *first* point, not the last one).
[snip]

OK, I follow now...


>>>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>--- gnuplot/src/datafile.c      2008-01-25 12:59:41.000000000 -0800
>>>+++ gnuplot-cvs/src/datafile.c  2008-01-30 23:01:30.000000000 -0800
>>>@@ -4937,7 +4937,7 @@
>>>                }
>>>            }
>>>        } else { /* Not matrix file, general binray. */
>>>-           df_datum = point_count;
>>>+           df_datum = point_count+1;   /* EAM DEBUG */
>>>            if (i != df_no_bin_cols) {
>>>                if (feof(data_fp)) {
>>>                    if (i != 0)
>>>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I believe your fix is correct.  Feel free to check it in...

The reason for not incrementing df_datum directly, as is done with ASCII case, is that datum could also come from the gnuplot binary matrix as well.  Hence the tie in to point_count.  However, I might have moved a hunk of code around at some point and the incrementing of point_count comes later:

	/* update point_count. ignore point if
	   point_count%everypoint != 0 */
	if (++point_count < firstpoint
	    || point_count > lastpoint
	    || (point_count - firstpoint) % everypoint != 0)
	    continue;
	/*}}} */

so point_count is still at -1 (first time) when df_datum was first set.  In the case of "array =" a different variable

		    v[output] = m_value*delta[0];

is used instead of df_datum.  Your change will mean both cases now start at 0.

Dan

Re: No redraw with wxt and 'noraise'

[Philipp K. J. <ja...@ie...>]

>
> I can understand where this may come from, but I have not been able to
> reproduce it on my machine...
> The origin of the problem is that the calls to wxWidgets and GTK to
> redraw the plot are sent from gnuplot main thread, whereas the main
> graphic events loop runs in a secondary thread. So there are cases where
> calls made in gnuplot main thread are not really executed until the
> secondary thread is woken up by the arrival of another event. I have
> already had to fix such problems, for example to make 'set term wxt
> close' close the window immediately. _However_, I am not able to
> reproduce what you describe, i.e. the plot not being redrawn until a
> mouse event arrives. I have tried 4.2.2 and gnuplot CVS, with compiz,
> metacity and kde4's kwin as window managers. Could you try with another
> window manager such as one of those ? I have wxGTK 2.8.6, could you tell
> me what wxGTK version you have ?
>

wxWidgets-devel: 2.8.4-0
wxGTK: 2.6.3.3-30

icewm 1.2.26-32 (not icewm-lite)

Re: nice %t

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

On Thursday 31 January 2008 12:45, Petr Mikulik wrote:
> According to the discussion at <bu...@oc...>:
>   Subject: Re: Mixed format for y-axis in semilogy
> a question is: how to get a "nice" %t? Something like %g?
> 
> Can the appropriate number of digits be decided automatically by gnuplot?

I don't know what's best, but I will point out that we also
get complaints about the current default of "%g".
See for example Feature Request #905693

There probably is no choice that will please everyone.

-- 
Ethan A Merritt

Re: nice %t

[<HBB...@t-...>]

Petr Mikulik wrote:

> a question is: how to get a "nice" %t? Something like %g? Here is an 
> example:
> 
> set format x "%t*10^{%T}"
> set xrange [1.1e8:1.8e8]
[...]
> Can the appropriate number of digits be decided automatically by gnuplot?

gnuplot doesn't doesn't really do that in the case of the default format 
"% g", either.  The Standard C functions of the *printf() family do it 
all by themselves, because they remove trailing zeroes in %g mode.

The real difference is between the %f and %g formats of printf():

	set ytics nomirror ; set y2tics
	set format y '% g'
	set format x '% f'
	set format y2 '% t'
	plot [1.01:1.08]  x, x axes x1y2

It might be possible to implement %t by use of %f instead of %g, but I 
wouldn't like to have to guarantee that there are no offensive consequences.

nice %t

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

According to the discussion at <bu...@oc...>:
  Subject: Re: Mixed format for y-axis in semilogy
a question is: how to get a "nice" %t? Something like %g? Here is an 
example:

set format x "%t*10^{%T}"
set xrange [1.1e8:1.8e8]
plot x

set format x "%.0t*10^{%T}"
replot

set format x "%.1t*10^{%T}"
replot

Can the appropriate number of digits be decided automatically by gnuplot?

---
PM

Re: bug in histogram plot with binary data?

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

Dan:

The binary data file supposedly contains 1 set of 7 points
(yes the original poster counted wrong but it shouldn't matter since
the error is on the *first* point, not the last one).

> The array=1:8 specification indicates that there are two single dimensional arrays of data, one 1 element long, another 8 elements long.  However, that doesn't seem to match what the user is intending if there are only 7 data points.  
> (There should be nine.)  Perhaps the user just wants array=7. 

Sorry for introducing that "array=1:8" artifact. The original failing command
was  
   plot "histdata.bin" binary record=8 format="%int" u 1
In trying to debug it, I tried substituting "array" for "record" but
apparently got it wrong.  Sorry for the confusion on that point but
the original error remains the same.


Binary data case:
-----------------
# Curve 0 of 1, 7 points
# Curve title: ""histdata.bin" binary record=11 format="%int" u 1"
Tabular output of plot style 392 not fully implemented
# x y type
-1  102  i
 0  42  i
 1  38  i
 2  28  i
 3  26  i
 4  108  i
 5  156  i


Ascii data case:
----------------
# Curve 0 of 1, 7 points
# Curve title: "'dump' u 2"
Tabular output of plot style 392 not fully implemented
# x y type
 0  102  i
 1  42  i
 2  38  i
 3  28  i
 4  26  i
 5  108  i
 6  156  i

The ascii file 'dump' was created by dumping the data
as read in from the binary file.

In the ascii input case it correctly starts the 'datum'
(column 0) at 0.

In reading the binary data file, it incorrectly starts
the 'datum' at -1.  

The comments in the source code say:
    df_datum = -1;              /* it will be preincremented before use */
and that is indeed true in the df_readascii() case.
But the code is differnt in df_readbinary().  I changed the obvious line,
but my concern is that even though it appears to fix the 1D case it may
not be correct for "array" or "matrix" cases.  Can you comment on that?

	Ethan


On Thursday 31 January 2008 00:11, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > On Wednesday 30 January 2008 12:42, Ethan Merritt wrote:
> > 
> >>I help is needed from someone more familiar with the binary data modes.
> >>Anyone care to take over this bug report?
> > 
> > 
> > 
> > The following one-liner makes your test case work.
> > 
> > However, I am *not* applying this to CVS because I just don't understand
> > the code well enough.  The binary read code at this point is not parallel 
> > to the ascii input code, which simply does ++df_datum as it goes.
> > Why is this different?  Is it correct?  Will it break other things?
> > I don't know.
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > --- gnuplot/src/datafile.c      2008-01-25 12:59:41.000000000 -0800
> > +++ gnuplot-cvs/src/datafile.c  2008-01-30 23:01:30.000000000 -0800
> > @@ -4937,7 +4937,7 @@
> >                 }
> >             }
> >         } else { /* Not matrix file, general binray. */
> > -           df_datum = point_count;
> > +           df_datum = point_count+1;   /* EAM DEBUG */
> >             if (i != df_no_bin_cols) {
> >                 if (feof(data_fp)) {
> >                     if (i != 0)
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> > 
> > 
> >>On Wednesday 30 January 2008 12:15, Ralf Juengling wrote:
> >>
> >>>Here you go. The binary data is in intel pentium endianess
> >>>(whatever that is).
> >>
> >>Thanks. So far as I can tell from a quick test, the problem is
> >>not specific to histograms.  Any other plot type also gets incorrect
> >>x coordinates when using the binary read command on that data file.
> >>If I dump the contents after reading them in, I get this:
> >>
> >>gnuplot>  set style data linespoints
> >>gnuplot>  plot "histdata.bin" binary array=1:8 format="%int" using 1
> >>gnuplot> set table
> >>gnuplot> replot
> 
> The array=1:8 specification indicates that there are two single dimensional arrays of data, one 1 element long, another 8 elements long.  However, that doesn't seem to match what the user is intending if there are only 7 data points.  (There should be nine.)  Perhaps the user just wants array=7.
> 
> >>
> >># Curve 0 of 1, 7 points
> >># Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1"
> >># x y type
> >> 0  102  i
> 
> The above would be the first "line" of data.
> 
> >> 0  42  i
> >> 1  38  i
> >> 2  28  i
> >> 3  26  i
> >> 4  108  i
> >> 5  156  i
> 
> The rest constitutes the second "line" of data, even though there isn't enough to fill out eight elements.
> 
> Both of the above start at zero.  If you want the inherent x value assigned to begin at 1 with the above patch, that's fine.  (Is that what the ASCII data default is?  Then matching the two would be good.)
> 
> The thing that is a bit of a problem is what the table displays.  Curve 0 of 1 should maybe be curve 1 of 1, but more importantly, one might expect it to be Curve 1 of 2 and Curve 2 of 2 if the user specifies array=L1:L2, where L means "length".
> 
> However, this trait isn't unique to binary data.  Try the following:
> 
> Terminal type set to 'x11'
> gnuplot> set table
> gnuplot> plot '-' with lines
> input data ('e' ends) > 1
> input data ('e' ends) > 2
> input data ('e' ends) > 3
> input data ('e' ends) > 4
> input data ('e' ends) >
> input data ('e' ends) >
> input data ('e' ends) > 5
> input data ('e' ends) > 6
> input data ('e' ends) > 7
> input data ('e' ends) > 8
> input data ('e' ends) > e
> 
> # Curve 0 of 1, 9 points
> # Curve title: "'-'"
> # x y type
>  0  1  i
>  1  2  i
>  2  3  i
>  3  4  i
>  0  0  u
>  0  5  i
>  1  6  i
>  2  7  i
>  3  8  i
> 
> gnuplot>
> 
> The x-values assigned begin at 0.  There is an extra "undefined" in the middle, which doesn't happen for binary data.  Note that the comment says curve 0 of 1 (perhaps that is correct, i.e., multiple scan lines but still a single curve).  But 9 points instead of 8?
> 
> Dan
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: bug in histogram plot with binary data?

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

Ethan Merritt wrote:
> On Wednesday 30 January 2008 12:42, Ethan Merritt wrote:
> 
>>I help is needed from someone more familiar with the binary data modes.
>>Anyone care to take over this bug report?
> 
> 
> 
> The following one-liner makes your test case work.
> 
> However, I am *not* applying this to CVS because I just don't understand
> the code well enough.  The binary read code at this point is not parallel 
> to the ascii input code, which simply does ++df_datum as it goes.
> Why is this different?  Is it correct?  Will it break other things?
> I don't know.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot/src/datafile.c      2008-01-25 12:59:41.000000000 -0800
> +++ gnuplot-cvs/src/datafile.c  2008-01-30 23:01:30.000000000 -0800
> @@ -4937,7 +4937,7 @@
>                 }
>             }
>         } else { /* Not matrix file, general binray. */
> -           df_datum = point_count;
> +           df_datum = point_count+1;   /* EAM DEBUG */
>             if (i != df_no_bin_cols) {
>                 if (feof(data_fp)) {
>                     if (i != 0)
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> 
> 
>>On Wednesday 30 January 2008 12:15, Ralf Juengling wrote:
>>
>>>Here you go. The binary data is in intel pentium endianess
>>>(whatever that is).
>>
>>Thanks. So far as I can tell from a quick test, the problem is
>>not specific to histograms.  Any other plot type also gets incorrect
>>x coordinates when using the binary read command on that data file.
>>If I dump the contents after reading them in, I get this:
>>
>>gnuplot>  set style data linespoints
>>gnuplot>  plot "histdata.bin" binary array=1:8 format="%int" using 1
>>gnuplot> set table
>>gnuplot> replot

The array=1:8 specification indicates that there are two single dimensional arrays of data, one 1 element long, another 8 elements long.  However, that doesn't seem to match what the user is intending if there are only 7 data points.  (There should be nine.)  Perhaps the user just wants array=7.

>>
>># Curve 0 of 1, 7 points
>># Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1"
>># x y type
>> 0  102  i

The above would be the first "line" of data.

>> 0  42  i
>> 1  38  i
>> 2  28  i
>> 3  26  i
>> 4  108  i
>> 5  156  i

The rest constitutes the second "line" of data, even though there isn't enough to fill out eight elements.

Both of the above start at zero.  If you want the inherent x value assigned to begin at 1 with the above patch, that's fine.  (Is that what the ASCII data default is?  Then matching the two would be good.)

The thing that is a bit of a problem is what the table displays.  Curve 0 of 1 should maybe be curve 1 of 1, but more importantly, one might expect it to be Curve 1 of 2 and Curve 2 of 2 if the user specifies array=L1:L2, where L means "length".

However, this trait isn't unique to binary data.  Try the following:

Terminal type set to 'x11'
gnuplot> set table
gnuplot> plot '-' with lines
input data ('e' ends) > 1
input data ('e' ends) > 2
input data ('e' ends) > 3
input data ('e' ends) > 4
input data ('e' ends) >
input data ('e' ends) >
input data ('e' ends) > 5
input data ('e' ends) > 6
input data ('e' ends) > 7
input data ('e' ends) > 8
input data ('e' ends) > e

# Curve 0 of 1, 9 points
# Curve title: "'-'"
# x y type
 0  1  i
 1  2  i
 2  3  i
 3  4  i
 0  0  u
 0  5  i
 1  6  i
 2  7  i
 3  8  i

gnuplot>

The x-values assigned begin at 0.  There is an extra "undefined" in the middle, which doesn't happen for binary data.  Note that the comment says curve 0 of 1 (perhaps that is correct, i.e., multiple scan lines but still a single curve).  But 9 points instead of 8?

Dan

Re: bug in histogram plot with binary data?

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

On Wednesday 30 January 2008 12:42, Ethan Merritt wrote:
> I help is needed from someone more familiar with the binary data modes.
> Anyone care to take over this bug report?


The following one-liner makes your test case work.

However, I am *not* applying this to CVS because I just don't understand
the code well enough.  The binary read code at this point is not parallel 
to the ascii input code, which simply does ++df_datum as it goes.
Why is this different?  Is it correct?  Will it break other things?
I don't know.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/datafile.c      2008-01-25 12:59:41.000000000 -0800
+++ gnuplot-cvs/src/datafile.c  2008-01-30 23:01:30.000000000 -0800
@@ -4937,7 +4937,7 @@
                }
            }
        } else { /* Not matrix file, general binray. */
-           df_datum = point_count;
+           df_datum = point_count+1;   /* EAM DEBUG */
            if (i != df_no_bin_cols) {
                if (feof(data_fp)) {
                    if (i != 0)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


> On Wednesday 30 January 2008 12:15, Ralf Juengling wrote:
> > 
> > Here you go. The binary data is in intel pentium endianess
> > (whatever that is).
> 
> Thanks. So far as I can tell from a quick test, the problem is
> not specific to histograms.  Any other plot type also gets incorrect
> x coordinates when using the binary read command on that data file.
> If I dump the contents after reading them in, I get this:
> 
> gnuplot>  set style data linespoints
> gnuplot>  plot "histdata.bin" binary array=1:8 format="%int" using 1
> gnuplot> set table
> gnuplot> replot
> 
> # Curve 0 of 1, 7 points
> # Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1"
> # x y type
>  0  102  i
>  0  42  i
>  1  38  i
>  2  28  i
>  3  26  i
>  4  108  i
>  5  156  i
> 
> Can you confirm this on your setup?
> The thing is, I wrote the histogram code so I could probably fix it
> there if necessary.  But I am largely unfamiliar with the binary input
> code, and don't use it much myself.  So I don't know exactly what the
> issue might be.  Surely if it returns the wrong x coordinate in general,
> someone would have noticed by now?  But maybe not.  Or maybe you have
> hit a special case of some sort, though I don't know what it might be.
> 
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: No redraw with wxt and 'noraise'

[Allin C. <cot...@wf...>]

On Wed, 30 Jan 2008, Ethan Merritt wrote:

> On Monday 28 January 2008 17:34, Philipp K. Janert wrote:
> > I wonder whether anybody has seen this before?
> > Is this at all dependent on the window manager?
> > (I use IceWM.)
> 
> I cannot reproduce this behavior here, neither under KDE
> nor under IceWM.
> 
>     icewm-light-1.2.26-5mdv2007.0

Neither can I reproduce it on the gnome desktop with WM 
metacity 2.20.0: the plot is redrawn immediately.

Allin Cottrell

Re: No redraw with wxt and 'noraise'

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

On Monday 28 January 2008 17:34, Philipp K. Janert wrote:
> I wonder whether anybody has seen this before?
> Is this at all dependent on the window manager?
> (I use IceWM.)

I cannot reproduce this behavior here, neither under KDE
nor under IceWM.

    icewm-light-1.2.26-5mdv2007.0

> There is an interesting issue with the wxt terminal
> (on Linux, at least):
> 
> When I set up my terminal with the 'noraise' flag:
> 
> 	set t wxt noraise
> 
> Then the window is not raised after a plot command,
> instead the focus stays with the console window (so
> far, all is according to spec).
> 
> However, the window also does not receive a redraw
> event so that the old plot continues to be shown.
> The window is only redrawn (with the new plot) after 
> the mouse pointer enters the wxt window (or the
> window is raised).
> 
> My guess is that wxt does not generate a redraw
> event until the window system (X11) sends an event
> (souch as MOUSE_IN) to the window.
> 
> This does not seem to be a problem when using
> the old x11 terminal.
> 
> 
> Best,
> 
> 		Ph.
> 
> 
>         G N U P L O T
>         Version 4.2 patchlevel 2 
>         last modified 31 Aug 2007
>         System: Linux 2.6.18.2-34-default
> 
>         Copyright (C) 1986 - 1993, 1998, 2004, 2007
>         Thomas Williams, Colin Kelley and many others
> 
>         Type `help` to access the on-line reference manual.
>         The gnuplot FAQ is available from http://www.gnuplot.info/faq/
> 
>         Send bug reports and suggestions to 
> <http://sourceforge.net/projects/gnuplot>
> 
> Compile options:
> -READLINE  +LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> -NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  
> +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  
> 
> DRIVER_DIR     
> = "/home/janert/Gnuplot/Build/Release-4.2.2/build/libexec/gnuplot/4.2"
> GNUPLOT_PS_DIR 
> = "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4.2/PostScript"
> HELPFILE       
> = "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4.2/gnuplot.gih"
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: No redraw with wxt and 'noraise'

[Lutz M. <lut...@gm...>]

On Wednesday 30 January 2008 14:42:52 Timoth=E9e Lecomte wrote:
> Philipp K. Janert wrote:
> > When I set up my terminal with the 'noraise' flag:
> >
> > 	set t wxt noraise
> >
> > Then the window is not raised after a plot command,
> > instead the focus stays with the console window (so
> > far, all is according to spec).
> >
> > However, the window also does not receive a redraw
> > event so that the old plot continues to be shown.
> > The window is only redrawn (with the new plot) after
> > the mouse pointer enters the wxt window (or the
> > window is raised).
>
> I can understand where this may come from, but I have not been able to
> reproduce it on my machine...

I see the same behavior as Philipp on my machine, using gnuplot 4.2.2, kwin=
=20
3.5.7 as window manager, and wxGTK 2.8.4.

  Lutz

Re: No redraw with wxt and 'noraise'

[<tim...@lp...>]

Philipp K. Janert wrote:
> There is an interesting issue with the wxt terminal
> (on Linux, at least):
>
> When I set up my terminal with the 'noraise' flag:
>
> 	set t wxt noraise
>
> Then the window is not raised after a plot command,
> instead the focus stays with the console window (so
> far, all is according to spec).
>
> However, the window also does not receive a redraw
> event so that the old plot continues to be shown.
> The window is only redrawn (with the new plot) after 
> the mouse pointer enters the wxt window (or the
> window is raised).
>
> My guess is that wxt does not generate a redraw
> event until the window system (X11) sends an event
> (souch as MOUSE_IN) to the window.
>
> This does not seem to be a problem when using
> the old x11 terminal.
>
> I wonder whether anybody has seen this before?
> Is this at all dependent on the window manager?
> (I use IceWM.)
>
> Best,
>
> 		Ph.
>   
Hi Philipp,

I can understand where this may come from, but I have not been able to 
reproduce it on my machine...
The origin of the problem is that the calls to wxWidgets and GTK to 
redraw the plot are sent from gnuplot main thread, whereas the main 
graphic events loop runs in a secondary thread. So there are cases where 
calls made in gnuplot main thread are not really executed until the 
secondary thread is woken up by the arrival of another event. I have 
already had to fix such problems, for example to make 'set term wxt 
close' close the window immediately. _However_, I am not able to 
reproduce what you describe, i.e. the plot not being redrawn until a 
mouse event arrives. I have tried 4.2.2 and gnuplot CVS, with compiz, 
metacity and kde4's kwin as window managers. Could you try with another 
window manager such as one of those ? I have wxGTK 2.8.6, could you tell 
me what wxGTK version you have ?

Thank you,

Timothée



>
>         G N U P L O T
>         Version 4.2 patchlevel 2 
>         last modified 31 Aug 2007
>         System: Linux 2.6.18.2-34-default
>
>         Copyright (C) 1986 - 1993, 1998, 2004, 2007
>         Thomas Williams, Colin Kelley and many others
>
>         Type `help` to access the on-line reference manual.
>         The gnuplot FAQ is available from http://www.gnuplot.info/faq/
>
>         Send bug reports and suggestions to 
> <http://sourceforge.net/projects/gnuplot>
>
> Compile options:
> -READLINE  +LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> -NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  
> +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  
>
> DRIVER_DIR     
> = "/home/janert/Gnuplot/Build/Release-4.2.2/build/libexec/gnuplot/4.2"
> GNUPLOT_PS_DIR 
> = "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4.2/PostScript"
> HELPFILE       
> = "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4.2/gnuplot.gih"
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>