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

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

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

On Friday 05 March 2010 15:50:48 Manfred Schwarb wrote:
> 
> > On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > > > and had to apply
> > > > > 
> > > > > --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> > > > > +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> > > > > @@ -482,6 +482,7 @@
> > > > >      libgd_CPPFLAGS=`gdlib-config --cflags`
> > > > >      libgd_LDFLAGS=`gdlib-config --ldflags`
> > > > >      libgd_LIBS=`gdlib-config --libs`
> > > > > +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > > > >    elif test -d "$with_gd"; then
> > > > >      libgd_CPPFLAGS="-I$with_gd/include"
> > > > >      libgd_LDFLAGS="-L$with_gd/lib"
> > > > 
> > > > That seems like a problem with the libgd package configuration tool.
> > > > I'll forward a bug report in that direction if I can confirm it.
> > > > 
> > > > 	Ethan
> > 
> > I can't reproduce this problem. 
> > 
> > On my machines, neither libgd nor gnuplot as a whole requires libexpat,
> > which seems to be an XML parsing tool.
> > 
> 
> I think it comes from libfontconfig, newer libgd versions use it
> (I use some cvs version of libgd 2.0.36 at the moment):
> 
> # ldd /usr/lib64/libfontconfig.so
>         linux-vdso.so.1 =>  (0x00007fc1d544d000)
>         libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc1d4f90000)
>         libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc1d4d66000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007fc1d4a0b000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007fc1d47f5000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fc1d544e000)
> 
> # ldd /usr/local/lib/libgd.so
>         linux-vdso.so.1 =>  (0x00007fff9caea000)
>         libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fa27ef78000)
>         libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fa27ed42000)
>         libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa27eabc000)
>         libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fa27e894000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007fa27e67d000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007fa27e428000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007fa27e0cd000)
>         libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa27dea3000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fa27f3e7000)

Huh.  I also am using libgd 2.0.36, built from source.
It does link to libfreetype and to libfontconfig, but nowhere in the chain
is there a dependence on libexpat:

stonelion [3] ldd /home/local/src/gd-2.0.36/.libs/libgd.so.2
        linux-gate.so.1 =>  (0xffffe000)
        libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7851000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb771f000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb76fc000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb76c8000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7644000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7619000)
        libz.so.1 => /lib/libz.so.1 (0xb7606000)
        libm.so.6 => /lib/i686/libm.so.6 (0xb75de000)
        libc.so.6 => /lib/i686/libc.so.6 (0xb747d000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb745f000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7459000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7318000)
        /lib/ld-linux.so.2 (0xb78c0000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7314000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb730d000)
stonelion [4] ldd /usr/lib/libfontconfig.so.1
        linux-gate.so.1 =>  (0xffffe000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb762e000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb74ed000)
        libc.so.6 => /lib/i686/libc.so.6 (0xb738c000)
        libz.so.1 => /lib/libz.so.1 (0xb7379000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7373000)
        libm.so.6 => /lib/i686/libm.so.6 (0xb734b000)
        /lib/ld-linux.so.2 (0xb7700000)
stonelion [5] ldd /usr/lib/libxml2.so.2
        linux-gate.so.1 =>  (0xffffe000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7637000)
        libz.so.1 => /lib/libz.so.1 (0xb7624000)
        libm.so.6 => /lib/i686/libm.so.6 (0xb75fc000)
        libc.so.6 => /lib/i686/libc.so.6 (0xb749b000)
        /lib/ld-linux.so.2 (0xb7798000)
stonelion [6] ldd /usr/lib/libfreetype.so.6
        linux-gate.so.1 =>  (0xffffe000)
        libz.so.1 => /lib/libz.so.1 (0xb7762000)
        libc.so.6 => /lib/i686/libc.so.6 (0xb7601000)
        /lib/ld-linux.so.2 (0xb7813000)

So I certainly believe you that your machine is trying to pull in
libexpat, but I don't know where/why this dependency creeps in.
One of life's little mysteries :-)

	cheers,
		Ethan



> 
> But "gdlib-config --libs" gives:
> -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm
> 
> So it seems libgd does not add all needed libraries to gdlib-config.
> 
> 
> > And libpthread is pulled in by practically everything, so adding it
> > specifically to libgd_LIBS is redundant.
> > 
> > What was the error message you got before adding this line to
> > configure.in?
> > 
> 
> 
> from config.log:
> configure:11686: checking for gdImageStringFT in -lgd
> configure:11721: gcc  -o conftest -g -O2  -I/usr/local/include -static -s -L/usr/local/lib -L/usr/lib64 -L/lib conftest.c -lgd  -lm  -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype >&5
> /usr/local/lib/libgd.a(gdft.o): In function `gdFontCacheSetup':
> /tmp/libgd/gd-libgd-20/gdft.c:826: undefined reference to `pthread_mutex_init'
> /tmp/libgd/gd-libgd-20/gdft.c:829: undefined reference to `pthread_mutex_destroy'
> ...
> /usr/lib64/libfontconfig.a(fcxml.o): In function `FcConfigMessage':
> /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:476: undefined reference to `XML_GetCurrentLineNumber'
> /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:479: undefined reference to `XML_GetCurrentLineNumber'
> ...
> 
> 
> Cheers, Manfred

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

[Manfred S. <man...@gm...>]

> On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > > and had to apply
> > > > 
> > > > --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> > > > +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> > > > @@ -482,6 +482,7 @@
> > > >      libgd_CPPFLAGS=`gdlib-config --cflags`
> > > >      libgd_LDFLAGS=`gdlib-config --ldflags`
> > > >      libgd_LIBS=`gdlib-config --libs`
> > > > +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > > >    elif test -d "$with_gd"; then
> > > >      libgd_CPPFLAGS="-I$with_gd/include"
> > > >      libgd_LDFLAGS="-L$with_gd/lib"
> > > 
> > > That seems like a problem with the libgd package configuration tool.
> > > I'll forward a bug report in that direction if I can confirm it.
> > > 
> > > 	Ethan
> 
> I can't reproduce this problem. 
> 
> On my machines, neither libgd nor gnuplot as a whole requires libexpat,
> which seems to be an XML parsing tool.
> 

I think it comes from libfontconfig, newer libgd versions use it
(I use some cvs version of libgd 2.0.36 at the moment):

# ldd /usr/lib64/libfontconfig.so
        linux-vdso.so.1 =>  (0x00007fc1d544d000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc1d4f90000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc1d4d66000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fc1d4a0b000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fc1d47f5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc1d544e000)

# ldd /usr/local/lib/libgd.so
        linux-vdso.so.1 =>  (0x00007fff9caea000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fa27ef78000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fa27ed42000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa27eabc000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fa27e894000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fa27e67d000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa27e428000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa27e0cd000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa27dea3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa27f3e7000)


But "gdlib-config --libs" gives:
-ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm

So it seems libgd does not add all needed libraries to gdlib-config.


> And libpthread is pulled in by practically everything, so adding it
> specifically to libgd_LIBS is redundant.
> 
> What was the error message you got before adding this line to
> configure.in?
> 


from config.log:
configure:11686: checking for gdImageStringFT in -lgd
configure:11721: gcc  -o conftest -g -O2  -I/usr/local/include -static -s -L/usr/local/lib -L/usr/lib64 -L/lib conftest.c -lgd  -lm  -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype >&5
/usr/local/lib/libgd.a(gdft.o): In function `gdFontCacheSetup':
/tmp/libgd/gd-libgd-20/gdft.c:826: undefined reference to `pthread_mutex_init'
/tmp/libgd/gd-libgd-20/gdft.c:829: undefined reference to `pthread_mutex_destroy'
...
/usr/lib64/libfontconfig.a(fcxml.o): In function `FcConfigMessage':
/tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:476: undefined reference to `XML_GetCurrentLineNumber'
/tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:479: undefined reference to `XML_GetCurrentLineNumber'
...


Cheers, Manfred
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

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

Hello

On windows build (I have used the dynamic build), I do not use libexpat libraries. However, the
libexpat-1.dll is required for gnuplot execution.
I have looked around what requires libexpat.

In the fontconfig.pc, I found
***********
Libs.private:  -L/devel/dist/win32/expat-2.0.1-1/lib -lexpat
-L/devel/dist/win32/freetype-2.3.11-1/bin/../lib -lfreetype 
**********

For dynamic build, -lexpat is not required for linking but libexpat-1.dll is required for gnuplot
execution because the libexpat is privately linked with from the fontconfig.

Perhaps for static build, all libraries related might be required at link stage.

If the gdlib-config requires the fontconfig, the libexpat might be required through the fontconfig for
static build.

The above is my guess so that please see it as a reference.

Regards

Tatsuro
--- Ethan Merritt wrote:

> On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > > and had to apply
> > > > 
> > > > --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> > > > +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> > > > @@ -482,6 +482,7 @@
> > > >      libgd_CPPFLAGS=`gdlib-config --cflags`
> > > >      libgd_LDFLAGS=`gdlib-config --ldflags`
> > > >      libgd_LIBS=`gdlib-config --libs`
> > > > +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > > >    elif test -d "$with_gd"; then
> > > >      libgd_CPPFLAGS="-I$with_gd/include"
> > > >      libgd_LDFLAGS="-L$with_gd/lib"
> > > 
> > > That seems like a problem with the libgd package configuration tool.
> > > I'll forward a bug report in that direction if I can confirm it.
> > > 
> > > 	Ethan
> 
> I can't reproduce this problem. 
> 
> On my machines, neither libgd nor gnuplot as a whole requires libexpat,
> which seems to be an XML parsing tool.
> 
> And libpthread is pulled in by practically everything, so adding it
> specifically to libgd_LIBS is redundant.
> 
> What was the error message you got before adding this line to configure.in?
> 
> 	Ethan
> 
> ------------------------------------------------------------------------------
> Download Intel¢î Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

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

On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > and had to apply
> > > 
> > > --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> > > +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> > > @@ -482,6 +482,7 @@
> > >      libgd_CPPFLAGS=`gdlib-config --cflags`
> > >      libgd_LDFLAGS=`gdlib-config --ldflags`
> > >      libgd_LIBS=`gdlib-config --libs`
> > > +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > >    elif test -d "$with_gd"; then
> > >      libgd_CPPFLAGS="-I$with_gd/include"
> > >      libgd_LDFLAGS="-L$with_gd/lib"
> > 
> > That seems like a problem with the libgd package configuration tool.
> > I'll forward a bug report in that direction if I can confirm it.
> > 
> > 	Ethan

I can't reproduce this problem. 

On my machines, neither libgd nor gnuplot as a whole requires libexpat,
which seems to be an XML parsing tool.

And libpthread is pulled in by practically everything, so adding it
specifically to libgd_LIBS is redundant.

What was the error message you got before adding this line to configure.in?

	Ethan

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

[Manfred S. <man...@gm...>]

> On Friday 05 March 2010 06:52:39 Manfred Schwarb wrote:
> > 
> > Another thing: I recently did a static build, it was
> > a bit a pain. I had to manually set "#undef HAVE_PWD_H"
> 
> I don't see the connection there.  
> What does HAVE_PWD_H have to do with a static build?
> 

I get the following when compiling with gcc 4.4.1:

util.o: In function `getusername':
/tmp/gnuplot-4.4/src/util.c:1211: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking



> There was a post on the newsgroup recently that implicitly complained
> about HAVE_PWD_H for privacy reasons.  If there is now another down-side
> as well, I think we should get rid of this code.  The only thing it does
> is fill in extra information in the "author" field of a PostScript or
> PDF file header.
> 
> 
> > and had to apply
> > 
> > --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> > +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> > @@ -482,6 +482,7 @@
> >      libgd_CPPFLAGS=`gdlib-config --cflags`
> >      libgd_LDFLAGS=`gdlib-config --ldflags`
> >      libgd_LIBS=`gdlib-config --libs`
> > +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> >    elif test -d "$with_gd"; then
> >      libgd_CPPFLAGS="-I$with_gd/include"
> >      libgd_LDFLAGS="-L$with_gd/lib"
> 
> That seems like a problem with the libgd package configuration tool.
> I'll forward a bug report in that direction if I can confirm it.
> 
> 	Ethan

-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

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

On Friday 05 March 2010 06:52:39 Manfred Schwarb wrote:
> 
> Another thing: I recently did a static build, it was
> a bit a pain. I had to manually set "#undef HAVE_PWD_H"

I don't see the connection there.  
What does HAVE_PWD_H have to do with a static build?

There was a post on the newsgroup recently that implicitly complained
about HAVE_PWD_H for privacy reasons.  If there is now another down-side
as well, I think we should get rid of this code.  The only thing it does
is fill in extra information in the "author" field of a PostScript or
PDF file header.


> and had to apply
> 
> --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> @@ -482,6 +482,7 @@
>      libgd_CPPFLAGS=`gdlib-config --cflags`
>      libgd_LDFLAGS=`gdlib-config --ldflags`
>      libgd_LIBS=`gdlib-config --libs`
> +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
>    elif test -d "$with_gd"; then
>      libgd_CPPFLAGS="-I$with_gd/include"
>      libgd_LDFLAGS="-L$with_gd/lib"

That seems like a problem with the libgd package configuration tool.
I'll forward a bug report in that direction if I can confirm it.

	Ethan

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

[Manfred S. <man...@gm...>]

> 
> Although I think a 4.4.0 release is nearly ready, I have encountered
> a couple of last-minute glitches.
> 
> 1) Sometime between the 4.4.0-rc1 tarball creation and the current 
>    4.4 cvs, the targets "make clean" and "make distclean" have broken.
> 

I noticed, too. "make mostlyclean" seems to work though.


Another thing: I recently did a static build, it was
a bit a pain. I had to manually set "#undef HAVE_PWD_H" and
had to apply

--- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
+++ configure.in        2010-03-02 11:55:43.000000000 +0100
@@ -482,6 +482,7 @@
     libgd_CPPFLAGS=`gdlib-config --cflags`
     libgd_LDFLAGS=`gdlib-config --ldflags`
     libgd_LIBS=`gdlib-config --libs`
+    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
   elif test -d "$with_gd"; then
     libgd_CPPFLAGS="-I$with_gd/include"
     libgd_LDFLAGS="-L$with_gd/lib"


Otherwise, gnuplot 4.4 works fine for me.
Thanks!

Manfred

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

[sfeam (E. Merritt) <eam...@gm...>]

Although I think a 4.4.0 release is nearly ready, I have encountered
a couple of last-minute glitches.

1) Sometime between the 4.4.0-rc1 tarball creation and the current 
   4.4 cvs, the targets "make clean" and "make distclean" have broken.

   This is just really strange.  It doesn't stop you from building and
   installing the program - but you can't clean up afterwards.
   And it causes packaging errors from "make distcheck".

2) The x11 app-defaults file
On Saturday 20 February 2010, Hans-Bernhard Bröker wrote:
> Ethan Merritt wrote:
> > It seems that no matter where the X11 resources file is installed,
> > there are complaints.
> > 
> Or install it under ${pkgdatadir}, and let users decide what to about it.

  I've now changed it to install under ${pkgdatadir} and put notes in 
  INSTALL and NEWS.

Re: 4.4-rc1: sticky x-axis reversal

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

On Thursday 04 March 2010 11:30:59 Hans-Bernhard Bröker wrote:
> Hello everyone,
> 
> I've just received a bug report from a German-speaking user.  4.4-rc1 
> (and current 4.4 branch CVS) both fail on the following script:
> 
> set multiplot layout 1,2
> plot [2:0] sin(x)
> plot [0:2] sin(x)
> unset multiplot
> 
> The problem is that the axis of the second plot is reversed, too. 

Here is the ChangeLog entry for the commit that changed the behaviour:

2007-06-29  Ethan Merritt  <merritt@u.washington.edu>

        * src/axis.c (load_range): Revert change of 2004-03-15. This means
        that we do *not* clear the RANGE_REVERSE flag after applying the
        reversal. This is necessary for the upcoming "refresh" support, but
        also fixes a current bug:
        set xrange [*:*] reverse; plot <foo>;  <zoom; zoom; unzoom>
        flag is now clear, and subsequent plots are drawn backwards

So a simple reversion of the change would re-introduce a bug present in
4.2.anything:  
  zoom/unzoom flips the sign of an axis that was explicitly set to "reverse".

Not to say that this shouldn't be fixed, but it will require more than
simply reverting to the previous code.

4.4-rc1: sticky x-axis reversal

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

Hello everyone,

I've just received a bug report from a German-speaking user.  4.4-rc1 
(and current 4.4 branch CVS) both fail on the following script:

set multiplot layout 1,2
plot [2:0] sin(x)
plot [0:2] sin(x)
unset multiplot

The problem is that the axis of the second plot is reversed, too.  Since 
it really only applies for the time of a plot command, specifying an 
inverted axis interval like this shouldn't set the 'reverse' option, but 
it does:

gnuplot> p [2:0] sin(x)
gnuplot> show xr

         set xrange [ * : * ] reverse nowriteback  # (currently 
2.00000:0.00000] )

'set xrange [2:0]' is supposed to have this effect, but a temporary 
override inside a plot command isn't.

Re: Instructions to make wxtp terminal run on Mac OS X with patch

[Werner S. <sm...@ia...>]

Hi Miro,

> 
> I fully agree with that, but as far as I know there is currently no
> binary version of gnuplot available at all (one link doesn't work and
> the other one only claims to have PPC binaries which I wasn't able to
> download and would not work on my computer anyway).
> 
[....]
> Some mac fan would need to sit down and do it properly ... and it
> would take some time even without wxt (I would be glad to see that
> happen though).

This happened already - for octave on Mac OS X also an app bundle of
gnuplot 4.2.5 was provided - without the wxt terminal for obvious
reasons. I wrote about that here:

http://www.miscdebris.net/blog/2009/09/16/install-gnuplot-on-mac-os-x/

This is the easiest way to install gnuplot on mac os x, still I would
prefer to have gnuplot sit in /usr/local since gnuplot is just not an
"app". It's a terminal program used in a terminal/console window.

Regards,
Werner

> 
> Mojca


-- 
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10/134
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sm...@ia...  (GPG: EDCAF4A79)
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Re: Instructions to make wxtp terminal run on Mac OS X with patch

[Mojca M. <moj...@gm...>]

On Wed, Mar 3, 2010 at 09:37, Werner Smekal wrote:
>
>>> Thank you so much for contributing these fixes and instructions!
>>> I'm not sure how best to package them for use by other OSX users,
>>> but we'll find a way.
>>
>> It makes sense to ask developers of gnuplot packages for fink and
>> macports to try to adapt for the changes. This would be the easiest
>> way to get wxt terminal to mac users.
>
> But it should also be a package outside of fink and macport be provided.
> These projects (fink and macports) are cool, but not all want to compile
> for 2 hours until they can use gnuplot (and compiling all packages
> needed for pango takes a long time). And sadly more often then I would
> hope for I encounter some package which doesn't compile correctly (both
> for fink and macports) - quality is not right there IMO.

I fully agree with that, but as far as I know there is currently no
binary version of gnuplot available at all (one link doesn't work and
the other one only claims to have PPC binaries which I wasn't able to
download and would not work on my computer anyway).

I compile some programs for TeX community, but they have all the
libraries built in statically (the source repository provides all the
sources of libraries, so that I don't need to install anything special
in advance and compilation works out of the box).

Some mac fan would need to sit down and do it properly ... and it
would take some time even without wxt (I would be glad to see that
happen though).

Mojca

Re: Instructions to make wxtp terminal run on Mac OS X with patch

[Werner S. <sm...@ia...>]

>>
>> Thank you so much for contributing these fixes and instructions!
>> I'm not sure how best to package them for use by other OSX users,
>> but we'll find a way.
> 
> It makes sense to ask developers of gnuplot packages for fink and
> macports to try to adapt for the changes. This would be the easiest
> way to get wxt terminal to mac users.

But it should also be a package outside of fink and macport be provided.
These projects (fink and macports) are cool, but not all want to compile
for 2 hours until they can use gnuplot (and compiling all packages
needed for pango takes a long time). And sadly more often then I would
hope for I encounter some package which doesn't compile correctly (both
for fink and macports) - quality is not right there IMO.
> 
> (The best way would still be to have static linking or to ship the
> libraries together with gnuplot, but that definitely makes time to
> package it properly.)

Yup, wxWidgets can be compiled in statically and then a .pkg could be
provided whcih installs gnuplot in /usr/local/ - it should even be
possible that the GTK framework is downloaded automatically and
installed (if needed) or something like that (since gtk framework would
then be the only dependency which is needed).

But before that the wxt(p) terminal needs to be debugged, since there is
still some work to do.

Regards,
Werner

> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


-- 
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10/134
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sm...@ia...  (GPG: EDCAF4A79)
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Re: Instructions to make wxtp terminal run on Mac OS X with patch

[Mojca M. <moj...@gm...>]

On Tue, Mar 2, 2010 at 18:05, Ethan Merritt wrote:
> On Sunday 28 February 2010 23:58:20 Werner Smekal wrote:
>
>> here are the promised instructions to make the wxtp terminal run on
>> Mac OS X. Basically it's just downloading and installing the GTK
>> Framework for Mac OS X, applying the attached patch to the latest
>> gnuplot cvs and compile it. Below are much more detailed instructions
>> and comments.
>
> Thank you so much for contributing these fixes and instructions!
> I'm not sure how best to package them for use by other OSX users,
> but we'll find a way.

It makes sense to ask developers of gnuplot packages for fink and
macports to try to adapt for the changes. This would be the easiest
way to get wxt terminal to mac users.

(The best way would still be to have static linking or to ship the
libraries together with gnuplot, but that definitely makes time to
package it properly.)

Mojca

Re: Instructions to make wxtp terminal run on Mac OS X with patch

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

On Sunday 28 February 2010 23:58:20 Werner Smekal wrote:

> here are the promised instructions to make the wxtp terminal run on
> Mac OS X. Basically it's just downloading and installing the GTK
> Framework for Mac OS X, applying the attached patch to the latest
> gnuplot cvs and compile it. Below are much more detailed instructions
> and comments.

Thank you so much for contributing these fixes and instructions!
I'm not sure how best to package them for use by other OSX users,
but we'll find a way.

In any case, I'll try to update the patch set with your fixes.
At this point the patched source probably won't make it into the
initial 4.4 release, but it can go into CVS for wider testing and
then get queued for 4.4.1

	Ethan

Re: [Gnuplot-info] any more gray scale?

[Jon <dev...@gm...>]

Thanks, MATSUOKA, this is exactly what I want!

Sincerely,
Jun


2010/2/28 Tatsuro MATSUOKA <tma...@ya...>

> Hello
>
> This is one of the example.  Someone else will give you better solution.
> In the gnuplot, you can specify color like the below.
> plot sin(x) lt rgb "#FF00AA"#explicit RGB triple in hexadecimal
>
> The hexadecimal digits are like RRGGBB. The Red is FF, Green is 00, and
> Blue is AA.
>
> If you change the digits keeping Red=Green=Blue, you can control brightness
> ( darkness) of the gray
> color.  Note that '#FFFFFF' denotes white and "#000000" denotes black.
>
> Regards
>
> Tatsuro
>
> --- Jon  wrote:
>
> > I want to draw all my graphs in gray scale, is there way to specify this?
> > What I can find is dark and one scale of gray. Thanks,
> >
> ------------------------------------------------------------------------------
> > Download IntelПвю Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > gnuplot-info mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> >
>
>
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
>

Instructions to make wxtp terminal run on Mac OS X with patch

[Werner S. <sm...@ia...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

so here are the promised instructions to make the wxtp terminal run on
Mac OS X. Basically it's just downloading and installing the GTK
Framework for Mac OS X, applying the attached patch to the latest
gnuplot cvs and compile it. Below are much more detailed instructions
and comments.

*****************************************************************
* Installation instructions

0) Install XCode ;). Instructions were tested on Mac OS X 10.5.8, Intel.
I keep everything in the directory I work, so no files are installed in
the system.

I) Install gnuplot 4.4 on Mac OS X with wxWidgets Terminal (using
provided wxWidgets libraries, works but toolbar isn't working properly)

1) install GTK Framework
  a) Download the GTK_2.18.5-X11.pkg package from
http://r.research.att.com/ and install it
  b) Add to your .profile file in the home directory:
    export PATH=/Library/Frameworks/GTK+.framework/Resources/bin:$PATH

2) get latest gnuplot 4.4 from cvs (branch-4-4-stable) and apply patch
  a) export
CVSROOT=:pserver:ano...@gn...:/cvsroot/gnuplot
  b) cvs login     (use an empty password)
  c) cvs -z3 checkout -r branch-4-4-stable gnuplot
  d) cd gnuplot
  e) patch -p1 < path-to/wxt-as-process-20100301.diff
  f) ./prepare
  g) cd ..

3) compile gnuplot, in the same directory as the checked out gnuplot
directory do
  a) mkdir build
  b) cd build
  c) ../gnuplot/configure --prefix=$PWD/../local/ --with-readline=bsd
  d) check if you find at the end of the configure output
  wxt terminal: yes
  cairo-based pdf and png terminals: yes
  e) make
  f) make install
BTW: make install fails if make install is not called with root
privileges (which I don't want, since I install into my $HOME directory
anyway) with the message:

make[3]: Nothing to be done for `install-exec-am'.
test -z "/etc/X11/app-defaults/" || ../../gnuplot/install-sh -c -d
"/etc/X11/app-defaults/"
mkdir: /etc/X11: Permission denied
make[3]: *** [install-appdefaultDATA] Error 1
make[2]: *** [install-am] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1

4) ../local/bin/gnuplot

II) Install gnuplot 4.4 on Mac OS X with wxWidgets Terminal (using self
compiled wxWidgets libraries, works much better)

1) as in I

2) compile a static wxWidgets library
  a) Download the wxWidgets 2.8.11-rc2 library from
http://biolpc22.york.ac.uk/pub/2.8.11-rc2/wxMac-2.8.11-rc2.zip , unzip it
  b) export WXDIR=path-to/wxMac-2.8.11-rc2
  c) cd $WXDIR
  d) mkdir osx
  e) cd osx
  f) ../configure --prefix=$WXDIR/osx/local --disable-shared
  g) make
  h) make install
  i) export PATH=$WXDIR/osx/local/bin:$PATH

3) as step 2 in I

4) as step 3 in I

5) ../local/bin/gnuplot

*****************************************************************
* Comments about patch

X) Create patch
  a) Download wxt-as-process-20090210.diff
  b) patch -p1 < path-to/wxt-as-process-20090210.diff
     Problem:
patching file src/Makefile.am
Hunk #1 FAILED at 29.
Hunk #2 succeeded at 63 with fuzz 1 (offset -3 lines).
1 out of 2 hunks FAILED -- saving rejects to file src/Makefile.am.rej
Adding line 36:
GNUPLOT_WXT = `echo gnuplot_wxt | sed '$(transform)'`$(EXEEXT)

Changing line 38:
AM_CPPFLAGS = -I../term -I$(top_srcdir)/term -DBINDIR=\"$(bindir)\"
- -DX11_DRIVER_DIR=\"$(X11_DRIVER_DIR)\"
- -DGNUPLOT_PS_DIR=\"$(GNUPLOT_PS_DIR)\"
- -DGNUPLOT_JS_DIR=\"$(GNUPLOT_JS_DIR)\"
- -DGNUPLOT_LUA_DIR=\"$(GNUPLOT_LUA_DIR)\"  -DCONTACT=\"$(EMAIL)\"
- -DHELPFILE=\"$(HELPFILE)\" -DGNUPLOT_X11=\"$(GNUPLOT_X11)\"
- -DXAPPLRESDIR=\"$(XAPPLRESDIR)\" -DGNUPLOT_WXT=\"$(GNUPLOT_WXT)\"

  c) Added "hack", so that non-app bundle GUIs get focus (see patch).
     At the top add:
#ifdef __WXMAC__
	#include <Carbon/Carbon.h>
	extern "C" { void CPSEnableForegroundOperation( ProcessSerialNumber*
psn ); }
#endif

     in wxt_init() add:
	/* this hack enables to have a GUI on Mac OSX even if the
	 * program was called from the command line (and isn't a bundle) */
#ifdef __WXMAC__
	FPRINTF((stderr,"Mac hack\n"));
	ProcessSerialNumber psn;

	GetCurrentProcess( &psn );
	CPSEnableForegroundOperation( &psn );
	SetFrontProcess( &psn );
#endif



Regards,
Werner

- -- 
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10/134
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sm...@ia...  (GPG: EDCAF4A79)
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLi3OcAAoJEG1QQcXtyvSnNSQH/Rky2b1b5Y9+dfIt99+NERbi
DEYm51qzOB9n8Mv3sviPNm/YkudMRoTD4D772bSUvI+RLwHnqeEEClZzxU3CmJGu
qX6PSNn2GecXH0IoHSiPbQoo8ky+iiDW5FrfNcfPDSDdtCO7VSanYEE7mPVxJy8s
oKEkEh0QlAD9lhYbH2u9t5mZyedqhBd/KFQ41TJ0PK/O4H0aCD1sro+bad5tg+EO
EZAD4XNF+zPdAwgUCEwMw35p3L8TuPdk5RxZs2U9pqOaGZctKd4+E0NEs9gm0AgE
qx4ZXx6vSynwVL0hAOfCwN5W5MjUfQLfNeUAq0CGEDDa0eNxnCpF9vFkGIZyLrA=
=66hL
-----END PGP SIGNATURE-----

Re: [Gnuplot-info] any more gray scale?

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

Hello

This is one of the example.  Someone else will give you better solution.
In the gnuplot, you can specify color like the below. 
plot sin(x) lt rgb "#FF00AA"#explicit RGB triple in hexadecimal

The hexadecimal digits are like RRGGBB. The Red is FF, Green is 00, and Blue is AA.

If you change the digits keeping Red=Green=Blue, you can control brightness ( darkness) of the gray
color.  Note that '#FFFFFF' denotes white and "#000000" denotes black.

Regards

Tatsuro
 
--- Jon  wrote:

> I want to draw all my graphs in gray scale, is there way to specify this?
> What I can find is dark and one scale of gray. Thanks,
> ------------------------------------------------------------------------------
> Download Intel¢î Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: gnuplot manual misprint (no.32)

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

On Friday 26 February 2010 01:02:36 Shigeharu TAKENO wrote:
> shige 02/26 2010
> ----------------
> 
> In docs/gnuplot.doc of current CVS version
> 
>  C RCS $Id: gnuplot.doc,v 1.602 2010/02/24 20:54:40 sfeam Exp $
> 
> I found the following point. 
> 
> ----- From here -----
> --- gnuplot.doc.orig	2010-02-26 17:59:24.000000000 +0900
> +++ gnuplot.doc	2010-02-26 18:00:04.000000000 +0900
> @@ -1706,9 +1706,9 @@
>   It is usually sufficient in gnuplot to request a font by a generic name and
>   size, letting fontconfig substitute a similar font if necessary. The following
>   will probably all work:
> -      set term pdfpng font "sans,12"
> -      set term pdfpng font "Times,12"
> -      set term pdfpng font "Times-New-Roman,12"
> +      set term png font "sans,12"
> +      set term png font "Times,12"
> +      set term png font "Times-New-Roman,12"
>  
>  3 gd (png, gif, jpeg terminals)
>  ?gd
> ----- To here -----

Got it.  Thanks.

	Ethan

gnuplot manual misprint (no.32)

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

shige 02/26 2010
----------------

In docs/gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.602 2010/02/24 20:54:40 sfeam Exp $

I found the following point. 

----- From here -----
--- gnuplot.doc.orig	2010-02-26 17:59:24.000000000 +0900
+++ gnuplot.doc	2010-02-26 18:00:04.000000000 +0900
@@ -1706,9 +1706,9 @@
  It is usually sufficient in gnuplot to request a font by a generic name and
  size, letting fontconfig substitute a similar font if necessary. The following
  will probably all work:
-      set term pdfpng font "sans,12"
-      set term pdfpng font "Times,12"
-      set term pdfpng font "Times-New-Roman,12"
+      set term png font "sans,12"
+      set term png font "Times,12"
+      set term png font "Times-New-Roman,12"
 
 3 gd (png, gif, jpeg terminals)
 ?gd
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: differences between the gnuplot binary and its help

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

shige 02/26 2010
----------------

Ethan Merritt <merritt@u.washington.edu> wrote:
| Could you please start a new bug tracker entry for this on SourceForge,
| and upload the mkbin.c and mkbin.gp files to go with it?

OK, I will do.

| The binary file routines use fseek(), which will not work on
| piped input.  I do not know if the code can be re-written so
| as to not use fseek(). 

To workaround, to use temporary file having the data of piped 
input. But, I think it is better to add the comment for it to the
the document than to use mktemp().

| To me the layout described by the documentation is more natural,
| but that is not what the code implements.

I agree with you.

| Work-around:
|    splot "mkbin.dat" binary matrix using 2:1:3 with lines

I confirm it.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: differences between the gnuplot binary and its help

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

On Wednesday 24 February 2010, Shigeharu TAKENO wrote:
> shige 02/25 2010
> ----------------
> 
> I wrote:
> | I prepared sample scripts, data, and results. See
> | 
> | http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/mkbin.c
> | http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/mkbin.gp
> | http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/mkbin1.gif
> | http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/mkbin2.gif
> 
> I explane them. mkbin.c make the following binary matrix data:
> 
>   3.0 5.0 6.0 7.0    (<N+1>  <y0>   <y1>   <y2>)
>   0.0 1.0 2.0 3.0    ( <x0> <z0,0> <z0,1> <z0,2>)
>   0.1 3.0 1.0 4.0    ( <x1> <z1,0> <z1,1> <z1,2>)
>   0.2 2.0 2.5 3.0    ( <x2> <z2,0> <z2,1> <z2,2>)
> 
> Gnuplot script mkbin.gp makes images mkbin1.gif and mkbin2.gif
> from the data made by mkbin.c.
> 
> Gnuplot.doc says that gnuplot treat it as the following:
> 
>   0.0 5.0 1.0
>   0.0 6.0 2.0
>   0.0 7.0 3.0
> 
>   0.1 5.0 3.0
>   0.1 6.0 1.0
>   0.1 7.0 4.0
> 
>   0.2 5.0 2.0
>   0.2 6.0 2.5
>   0.2 7.0 3.0
> 
> However, images mkbin1.gif and mkbin2.gif show that these are
> made from the data
> 
>   5.0 0.0 1.0
>   6.0 0.0 2.0
>   7.0 0.0 3.0
> 
>   5.0 0.1 3.0
>   6.0 0.1 1.0
>   7.0 0.1 4.0
> 
>   5.0 0.2 2.0
>   6.0 0.2 2.5
>   7.0 0.2 3.0

I confirm these results, running on linux.

Could you please start a new bug tracker entry for this on SourceForge,
and upload the mkbin.c and mkbin.gp files to go with it?
 
> Moreover, I found a problem in these tests. The following script
> 
>   ! ./mkbin > mkbin.dat
>   splot "mkbin.dat" binary matrix with lines
> 
> works. But, 
> 
>   splot "< ./mkbin" binary matrix with lines
> 
> does not work and gnuplot says "line 1: Data file is empty".

The binary file routines use fseek(), which will not work on
piped input.  I do not know if the code can be re-written so
as to not use fseek(). 

And yes, I can see from the input code in datafile.c routine
df_determine_matrix_info()  that it reads x across the top
and y down the left column.  So the code disagrees with the
documentation.

To me the layout described by the documentation is more natural,
but that is not what the code implements.


Work-around:
   splot "mkbin.dat" binary matrix using 2:1:3 with lines

I expected the "transpose" keyword to work also, but apparently
it is broken.

Sigh.  
Any volunteers to re-write the binary file code?
If not, should we re-write the documentation?

Re: gnuplot 4.4, mac os x, wxt terminal

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

On Thursday 25 February 2010 14:03:31 Werner Smekal wrote:
> Hi,
> 
> after some messing around I finally made the wxt(p) driver work. What I
> did was:
> 
> * Download the GTK_2.18.5-X11.pkg package from
> http://r.research.att.com/ and install it
> * Download the wxWidgets 2.8.11-rc2 source and compile a static build
> 
> Compiling gnuplot 4.4/4.5 works fine, pngcairo/pdfcairo work, but the
> wxt terminal hangs. Looking at the code this is because wxt uses a
> second thread which calls wxApp::OnRun which shouldn't be done, and
> obviously doesn't work in Mac OS X.
> 
> I patched gnuplot 4.4 from cvs with the patch adding another terminal
> wxtp which works similar to gnuplot_x11. The patch didn't apply cleanly,
> but this could be sorted out. It compiles and runs, but window doesn't
> get focus - known problem, since gnuplot is not an app, but with a
> little "hack" using CPSEnableForegroundOperation() this can also be
> solved and I got a working (sort of) wxtp terminal outside of an app bundle.
> 
> I just want to known what the status of wxt is now. Is wxtp supposed to
> be applied to cvs? The patch is over a year old.

No one has ever reported full success in getting wxt running under OSX,
so far as I am aware.   The wxtp patch was supposed to get the train moving
in that direction, but if the train ever arrived at the station I must have
been snoozing. 
 
> Anyway, just want to know where this is heading, maybe I can help a
> little (having some experience being the maintainer of the wxWidgets
> driver of PLplot).

If you have an updated patch plus a set of instructions for OSX users,
that would be fantastic!   

I have Macs available for testing, but the build environment is 
too different from machines I know well for me to help much when things
don't work.  In particular I never had any sort of handle on the
issue with giving focus to the plot window.

	Ethan







> 
> Regards,
> Werner
> 
> -- 
> Dr. Werner Smekal
> Institut fuer Angewandte Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10/134
> A-1040 Wien
> Austria
> DVR-Nr: 0005886
> 
> email: sm...@ia...  (GPG: EDCAF4A79)
> web:   http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office)
>        +43-(0)1-58801-13469 (laboratory)
> fax:   +43-(0)1-58801-13499
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Re: differences between the gnuplot binary and its help

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

On Thursday 25 February 2010 13:04:32 Hans-Bernhard Bröker wrote:
> Ethan Merritt wrote:
> > On Tuesday 23 February 2010 02:45:54 Shigeharu TAKENO wrote:
> 
> >> However, we can not use the character "$" as the part of the
> >> variable name.
> > 
> > You are right.   I will make this correction in the documentation.
> > 
> > I wonder why or when this changed?
> 
> I don't recall when, but the "why" is pretty obvious: we use $ as an 
> operator for 'call' arguments and as an abbreviation of column().

True.

I was thinking it might have had something to do with VMS support,
as VMS commonly uses $ as a prefix or separator in variable names.

Re: gnuplot 4.4, mac os x, wxt terminal

[Mojca M. <moj...@gm...>]

On Thu, Feb 25, 2010 at 23:03, Werner Smekal wrote:
>
> Anyway, just want to know where this is heading, maybe I can help a
> little (having some experience being the maintainer of the wxWidgets
> driver of PLplot).

Hello,

I would be enormously grateful if someone would manage to fix the
terminal for Mac.

I'm not in development team, but from what I understood the main
problem was that most developers don't own a mac and those that had a
chance to try it weren't sure what had to be fixed.

Mojca