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

Re: Gentlemen, start your engines...

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

On Friday 06 October 2006 04:36 pm, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> >
> > Digital Unix 4.0D (DECC compiler)
> >  - Builds OK, but ...
> >  - triggers floating exception in surface1.dem
> > 	(Bug #1572268)
> >  - triggers floating exception in image.dem when trying to
> >    read deliberately wrong-endian binary data
> > 	(maybe we should remove this demo)
>
> What happens on the DEC with
>
> set samples 101
> plot 1/x

Nothing special.  The issue is not divide-by-zero or underflow.
The wrong-endian exception is from trying to do anything at all
with a  bit pattern that is not a valid floating point number.

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

Re: Gentlemen, start your engines...

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

Timoth?e Lecomte writes:
[...] 
> I'm not disputing the fact that there may be multiple copies, I'm 
> disputing the fact that gdlib-config reports the following, when linked 
> to GNU libiconv:
> 
>     /home/research/csmkchan/lib/libiconv.so 
> -Wl,-rpath,/home/research/csmkchan/lib/

 This looks wrong. Is it really on two lines? If the .so can be linked
 explicitly, and I'm not even sure this can be done, the rpath directive
 is surely not needed.

> whereas I think it should report:
> 
>     -L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/lib
> 
> (for details, gd uses LIBICONV instead of LTLIBICONV in its configure 
> script, see 
> http://www.gnu.org/software/gettext/manual/html_node/gettext_189.html
> that's probably wrong since gd is precisely built as a libtool library).

 I will check this out and fix it if necessary.

> But look carefully at the patch: as it was written before, the contents 
> of 'gdlib-config --libs' was added to TERMLIBS after the checks, so 
> gnuplot was effectively linked against all those libs. _But_ it was 
> added _after_ the checks for gdImageCreate and friends. _This_ is the 
> bug.

 This seems logically correct to me: the libs are added after the
 (successful) check.

>      On IRC, I checked the config.log files of "Michael" who just posted 
> to comp.graphics.apps.gnuplot under the thread "Installing 4.1", and he 
> precisely got caught by this: 'gdlib-config --libs' was asking to link 
> against libiconv, but as this wasn't added for gnuplot checks, he 
> eventually ended up with gd not found and the errors mentioned in the 
> thread.

 I'll see if I can find this. Gnuplot's configure uses the library's
 config script precisely to keep complexity down so that it doesn't
 need to cover indirect library dependencies.

Re: Gentlemen, start your engines...

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

Ethan Merritt wrote:

> AIX 5L Version 5.2 (gcc)
>  - Builds and passes "make check" with no problem (X11 output)
>   
> Digital Unix 4.0D (DECC compiler)
>  - Builds OK, but ...
>  - triggers floating exception in surface1.dem
> 	(Bug #1572268)
>  - triggers floating exception in image.dem when trying to
>    read deliberately wrong-endian binary data
> 	(maybe we should remove this demo)

Well, we could also write a signal handling subroutine.  (There is some signal handling stuff in eval.c.)

What happens on the DEC with

set samples 101
plot 1/x

?

Dan

Re: Gentlemen, start your engines...

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

On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote:
>
> Everybody should check out a working copy of the branch, and test
> that it works as expected, on as many platforms as you can.

AIX 5L Version 5.2 (gcc)
 - Builds and passes "make check" with no problem (X11 output)
 =20
Digital Unix 4.0D (DECC compiler)
 - Builds OK, but ...
 - triggers floating exception in surface1.dem
	(Bug #1572268)
 - triggers floating exception in image.dem when trying to
   read deliberately wrong-endian binary data
	(maybe we should remove this demo)

Irix 6.5 (MIPSpro Compiler)
 - Builds and passes "make check" with no problem (PostScript output)


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Suggestion to improve usability of plot command

[Keir M. <ke...@cs...>]

I have a simple suggestion to improve the usability of the plot command.
Currently, I am not a huge fan of the way point styles are specified; mainly
because I do not find having to memorize different plot styles as numbers
remotely intuitive. Also, it is very difficult to tell from the documentation
exactly how to plot squares or other points instead of crosses (for, i.e.
overplotting two scatter plots to see where points line up).

What am I suggesting? Instead of writing:

gnuplot> plot 'file1' with points 4 3
gnuplot> plot 'file2' with points 1 4

I suggest that we support (*in addition* not instead of) two new methods of
specifying plot styles, one which follows the convention of Matlab and Matplotlib
(Python's plotting package), and another which is so blatently obvious everyone
will understand it.

Note that in the above script, no one could possibly guess what 4 3 or 1 4
means if they are not a frequent gnuplot user. I actually did not figure out
that this was the command I was looking for until after several passes through
the documentation; I erroneously expected the command to be obvious.

1) The really obvious version
-----------------------------

gnuplot> plot 'file1' with points 'red squares'
gnuplot> plot 'file2' with points 'blue crosses'
gnuplot> plot 'file1' with points 'orange octagons'
gnuplot> plot 'file1' with points 'orange stippled-squares'
gnuplot> plot 'file1' with points 'violet filled-circles'

Supporting arbitrary colors would also be straightforward:

gnuplot> plot 'file1' with points '#4fa324 crossed-circles'

I realize this version is more verbose, but I bet occasional gnuplot users
(like myself) will never forget this syntax. Also, by having explicit examples
in the plot help, this will be clear. From my quick examination, there is no
obvious example that says:

To plot square symbols, do the following:
gnuplot> plot 'file1' with points 4 2
Note that I don't know if 2 is the correct style. Or if the first argument is
color or the second.

2) The MATLAB / Matplotlib convention
-------------------------------------

In MATLAB and Matplotlib, plotting works like:
>>> scatter(x, y, 'r>')
where the first character is a color and the second is a symbol. The above
example plots red right triangles.

The colors are:
        'b' : blue
        'g' : green
        'r' : red
        'c' : cyan
        'm' : magenta
        'y' : yellow
        'k' : black
        'w' : white

The symbols are:
        's' : square
        'o' : circle
        '^' : triangle up
        '>' : triangle right
        'v' : triangle down
        '<' : triangle left
        'd' : diamond
        'p' : pentagram
        'h' : hexagon
        '8' : octagon

I suggest gnuplot support, in the interest of lowering the amount of
information users need to memorize, the following:
gnuplot> plot 'file1' with points 'r>'

I believe that a) gnuplot's current point style syntax is unusable, and b)
because most scientific users use several plotting programs instead of just one
(because each one is lacking a different subset of features), it is valuable to
reduce the amount of knowledge required to shift from one program to another.

Thanks for listening,
Keir

p.s. I am not on the list, so please CC any replies to me.

Re: Building wxt terminal for OS X

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

On Friday 06 October 2006 09:51 am, Joe Koski wrote:
> Hi,
>
> I may be jumping the gun, but I have attempted to build the wxt
> terminal for gnuplot-4.2 on my G5 Mac with OS X 10.4.8, Xcode-2.4
> developer tools, and six new open source dependencies (pango, cairo,
> pkg-config, glib, wxwidgets, and gettext). I borrowed freetype and
> fontconfig from Apple's x11 installation, and libxml2 is included
> with Xcode-2.4.

I am not a Mac user, and I am far from expert on the wxt
configuration requirements, but ...

Inspection of the source leads me to conclude that those error
messages are a result of not finding various bits of libwxgtk.
On a linux system with working wxt terminal I have the following
packages installed.
 libwxgtk2.6-2.6.1-1mdk
 libwxgtk2.6-devel-2.6.1-1mdk
 libwxgtkgl2.6-2.6.1-1mdk
 wxGTK2.6-2.6.1-1mdk
I'm not sure the *gl one is necessary.

Does that help any?



> My hope is the the wx terminal will allow better usage of gnuplot
> (and octave and maxima) on Windows and Macs.
>
> The ./configure of gnuplot-4.2 seems to go OK, but at the end of make
> I get
>
> <snip>
> if g++ -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
> -DBINDIR=\"/Tools/usr/local/bin\"
> -DX11_DRIVER_DIR=\"/Tools/usr/local/libexec/gnuplot/4.2\"
> -DGNUPLOT_PS_DIR=\"/Tools/usr/local/share/gnuplot/4.2/PostScript\"
> -DCONTACT=\"gnu...@li...\"
> -DHELPFILE=\"/Tools/usr/local/share/gnuplot/4.2/gnuplot.gih\"
> -I/usr/X11R6/include -I/usr/local/include/cairo
> -I/usr/local/include/freetype2 -I/usr/local/include
> -I/usr/local/include/libpng12 -I/usr/local/include/pango-1.0
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include    -g
> -O2 -I/usr/local/lib/wx/include/mac-ansi-release-2.6
> -I/usr/local/include/wx-2.6 -D__WXMAC__ -D_FILE_OFFSET_BITS=64
> -D_LARGE_FILES -DNO_GCC_PRAGMA -I/usr/X11R6/include
> -I/usr/local/include/cairo
> -I/usr/local/include/freetype2 -I/usr/local/include
> -I/usr/local/include/libpng12 -I/usr/local/include/pango-1.0
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include   -MT
> wxt_gui.o -MD -MP -MF ".deps/wxt_gui.Tpo" -c -o wxt_gui.o `test -f
> 'wxterminal/wxt_gui.cpp' || echo './'`wxterminal/wxt_gui.cpp; \
> then mv -f ".deps/wxt_gui.Tpo" ".deps/wxt_gui.Po"; else rm -f
> ".deps/wxt_gui.Tpo"; exit 1; fi
> In file included from wxterminal/wxt_gui.cpp:96:
> wxterminal/wxt_gui.h:199:3: error: #error "Not implemented"
> wxterminal/wxt_gui.cpp:196:3: error: #error "Not implemented."
> wxterminal/wxt_gui.cpp:1353:3: error: #error "Not implemented."
> wxterminal/wxt_gui.cpp:2875:2: error: #error "Not implemented"
> wxterminal/wxt_gui.cpp:3028:3: error: #error "No implementation"
> wxterminal/wxt_gui.cpp:3039:3: error: #error "No implementation"
> wxterminal/wxt_gui.cpp:2625: error: no 'void
> wxtPanel::wxt_cairo_create_bitmap()' member function declared in
> class 'wxtPanel'
> wxterminal/wxt_gui.cpp: In function 'void wxt_cleanup()':
> wxterminal/wxt_gui.cpp:3002: error: 'thread' was not declared in this
> scope wxterminal/wxt_gui.cpp:3003: error: type '<type error>'
> argument given to 'delete', expected pointer
> make[3]: *** [wxt_gui.o] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> If my attempt is premature, just let me know, and I'll cease and
> desist until advised. Otherwise, what should I do to get further with
> the build? Thanks.
>
> Joe
>
>
>
> ---------------------------------------------------------------------
>---- Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your opinions on IT & business topics through brief surveys --
> and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DE
>VDEV _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

Building wxt terminal for OS X

[Joe K. <jko...@co...>]

Hi,

I may be jumping the gun, but I have attempted to build the wxt terminal for
gnuplot-4.2 on my G5 Mac with OS X 10.4.8, Xcode-2.4 developer tools, and
six new open source dependencies (pango, cairo, pkg-config, glib, wxwidgets,
and gettext). I borrowed freetype and fontconfig from Apple's x11
installation, and libxml2 is included with Xcode-2.4.

My hope is the the wx terminal will allow better usage of gnuplot (and
octave and maxima) on Windows and Macs.

The ./configure of gnuplot-4.2 seems to go OK, but at the end of make I get

<snip>
if g++ -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=\"/Tools/usr/local/bin\"
-DX11_DRIVER_DIR=\"/Tools/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=\"/Tools/usr/local/share/gnuplot/4.2/PostScript\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/Tools/usr/local/share/gnuplot/4.2/gnuplot.gih\"
-I/usr/X11R6/include -I/usr/local/include/cairo
-I/usr/local/include/freetype2 -I/usr/local/include
-I/usr/local/include/libpng12 -I/usr/local/include/pango-1.0
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include    -g -O2
-I/usr/local/lib/wx/include/mac-ansi-release-2.6 -I/usr/local/include/wx-2.6
-D__WXMAC__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA
-I/usr/X11R6/include -I/usr/local/include/cairo
-I/usr/local/include/freetype2 -I/usr/local/include
-I/usr/local/include/libpng12 -I/usr/local/include/pango-1.0
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include   -MT
wxt_gui.o -MD -MP -MF ".deps/wxt_gui.Tpo" -c -o wxt_gui.o `test -f
'wxterminal/wxt_gui.cpp' || echo './'`wxterminal/wxt_gui.cpp; \
then mv -f ".deps/wxt_gui.Tpo" ".deps/wxt_gui.Po"; else rm -f
".deps/wxt_gui.Tpo"; exit 1; fi
In file included from wxterminal/wxt_gui.cpp:96:
wxterminal/wxt_gui.h:199:3: error: #error "Not implemented"
wxterminal/wxt_gui.cpp:196:3: error: #error "Not implemented."
wxterminal/wxt_gui.cpp:1353:3: error: #error "Not implemented."
wxterminal/wxt_gui.cpp:2875:2: error: #error "Not implemented"
wxterminal/wxt_gui.cpp:3028:3: error: #error "No implementation"
wxterminal/wxt_gui.cpp:3039:3: error: #error "No implementation"
wxterminal/wxt_gui.cpp:2625: error: no 'void
wxtPanel::wxt_cairo_create_bitmap()' member function declared in class
'wxtPanel'
wxterminal/wxt_gui.cpp: In function 'void wxt_cleanup()':
wxterminal/wxt_gui.cpp:3002: error: 'thread' was not declared in this scope
wxterminal/wxt_gui.cpp:3003: error: type '<type error>' argument given to
'delete', expected pointer
make[3]: *** [wxt_gui.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

If my attempt is premature, just let me know, and I'll cease and desist
until advised. Otherwise, what should I do to get further with the build?
Thanks.

Joe

Re: [4.2-rc1] set term X

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

On Thursday 05 October 2006 04:31 pm, Lutz Maibaum wrote:
> On Thursday 05 October 2006 16:17, Ethan Merritt wrote:
> > The code clean up was deliberate.  Causing the shorthand form "X"
> > to fail was unintentional.  It's fixable, at the cost of an extra
> > line or 2 of code.
>
> I would appreciate such a fix very much. I use "set term X" all the
> time. In fact, until yesterday I wasn't even aware that this is not
> the full name of the terminal driver.

OK. Thanks for the bug report.

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

Re: [4.2-rc1] set term X

[Lutz M. <ma...@be...>]

On Thursday 05 October 2006 16:17, Ethan Merritt wrote:
> The code clean up was deliberate.  Causing the shorthand form "X"
> to fail was unintentional.  It's fixable, at the cost of an extra
> line or 2 of code.

I would appreciate such a fix very much. I use "set term X" all the time. In 
fact, until yesterday I wasn't even aware that this is not the full name of 
the terminal driver.

  Lutz

Re: [4.2-rc1] set term X

[Lutz M. <ma...@be...>]

On Thursday 05 October 2006 14:36, Hans-Bernhard Broeker wrote:
> On Wed, 4 Oct 2006, Lutz Maibaum wrote:
> > Would it be possible to reintroduce "X" as a valid abbreviation of
> > "x11", or was this decision made on purpose to clean up the code?
>
> See for yourself:
>
> 	grep -8 "2006-06-28" ChangeLog

This seems to be the entry you're referring to:

2006-06-28  Ethan A Merritt  <merritt@u.washington.edu>

        * src/term.c (change_term) term/x11.trm: The x11 terminal driver has
        been carrying around two copies of TERM_TABLE, one named "x11" and
        the other named "X11". But the "X11" copy has suffered from bit rot.
        Delete this redundant copy, and instead replace "X11" with "x11"
        at the time the "set term" request is processed.

I am not sure how this relates to my problem. In version 4.0 there were three 
valid terminal names: "xlib", "x11", and "X11" (which according to "set 
terminal" was already the same as "x11"). "set term X" was a valid 
abbreviation for "set term X11".

In 4.2-rc1, these three terminal names are still valid, but "set term X" 
fails. Are abbreviations case sensitive? If they are, then "X" should be a 
valid abbreviation of "X11", and there wouldn't be any ambiguity. If they are 
not, then it surprises me why it worked in 4.0.

  Lutz

Re: [4.2-rc1] set term X

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

On Wednesday 04 October 2006 11:49 pm, Lutz Maibaum wrote:
> I frequently use 'set term X' as an abbreviation for 'set term X11'. 
> This does not seem to work with the latest version
>
> Up to version 4.0 it seems like the terminal name was case
> sensitive, and "X11" (with the abbreviation "X") was explicitly
> listed to be equivalent to "x11".

No. Up until 4.1 there were actually two terminal driver tables,
one for x11 and one for "X11".  This was pointless, and in fact a
source of error.  You may not have noticed, but the "X11" one
had not been kept up to date with the x11 one.  Anyhow, we got
rid of the redundant table and added a check for "X11" as a
special case. If found, it is converted to "x11".

> Would it be possible to reintroduce "X" as a valid abbreviation of
> "x11", or was this decision made on purpose to clean up the code?

The code clean up was deliberate.  Causing the shorthand form "X"
to fail was unintentional.  It's fixable, at the cost of an extra
line or 2 of code.


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

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Reiner S. <rei...@im...>]

On Thu, Oct 05 2006, Hans-Bernhard Broeker wrote:

> On Wed, 4 Oct 2006, Reiner Steib wrote:
>> I want to install gnuplot to /usr/local which is shared between i686
>> and x86_64 machines. =20
>
> This, rather than the interaction of autoconf's --program-suffix mechan=
ism
> with how we install gnuplot_x11, is the root of your problem.

I disagree.  Forget about my multi-architecture reasons[1] for a moment
and just consider a simple =BB./configure --program-suffix=3D-42=AB.  You=
'll
get the very same problem...

,----
| $ gnuplot-42=20
| Expected X11 driver: /usr/local/libexec/gnuplot/4.2/gnuplot_x11
| Exec failed: No such file or directory
| See 'help x11' for more details
`----

... because there is only "gnuplot_x11-42" in
/usr/local/libexec/gnuplot/4.2/:

,----
| $ ls /usr/local/libexec/gnuplot/4.2/
| gnuplot_x11-42
`----

> My experience is that the only way to get that working properly is
> --exec-prefix, because that's exactly what this option is designed
> to do.
>
> One --prefix fits all, but each platform gets its own --exec-prefix.

I will keep this in mind.  Thanks.

Bye, Reiner.

[1] If you need a reason: The user should get the distribution's
    version of gnuplot, but I want to offer 4.2 for those who need the
    new features.
--=20
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [4.2-rc1] set term X

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

Lutz Maibaum wrote:
> Up to 
> version 4.0 it seems like the terminal name was case sensitive, and 
> "X11" (with the abbreviation "X") was explicitly listed to be equivalent to 
> "x11".
> 
> Would it be possible to reintroduce "X" as a valid abbreviation of "x11", or 
> was this decision made on purpose to clean up the code?

Not sure if there should be an informal policy of precedence.

Is "xlib" important to you?  If not, you can build a version without xlib with the attached patch.  I guess that is a not too egregious way of accomplishing what you want.

Dan

Re: [4.2-rc1] set term X

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

On Wed, 4 Oct 2006, Lutz Maibaum wrote:

> Would it be possible to reintroduce "X" as a valid abbreviation of
> "x11", or was this decision made on purpose to clean up the code?

See for yourself:

	grep -8 "2006-06-28" ChangeLog

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

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

On Thu, 5 Oct 2006, Daniel J Sebald wrote:


> Does the following help to solve any problems:
> 
> ./configure --libexecdir=\${exec_prefix}/lib$(uname -i)exec

No.  It solves only half the problem, because it still writes the main
gnuplot executable to a directory shared by multiple architectures.  The
correct solution, if you want to base it on uname -i output, would be more
like this:

[if you're root:]
	./configure --exec-prefix=/usr/local/$(uname -i)
[otherwise:]
	./configure --prefix=$HOME --exec-prefix=$HOME/$(uname -i)

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

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

Hans-Bernhard Broeker wrote:
> On Wed, 4 Oct 2006, Reiner Steib wrote:
> 
> 
>>I tried to install gnuplot-4.2.rc1 on GNU/Linux (SUSE 9.2) on both
>>i686 and x86_64.
>>
>>I want to install gnuplot to /usr/local which is shared between i686
>>and x86_64 machines.  
> 
> 
> This, rather than the interaction of autoconf's --program-suffix mechanism
> with how we install gnuplot_x11, is the root of your problem.  I've worked 
> in an NFS-mounted home directory shared among *completely* different
> platforms (x86/Linux, Alpha/OSF1 and Mips/ULTRIX).  My experience is that
> the only way to get that working properly is --exec-prefix, because that's
> exactly what this option is designed to do.
> 
> One --prefix fits all, but each platform gets its own --exec-prefix.
> 

Hans is ahead of me on this one.  I was just looking through the list of variables:

http://www.gnu.org/software/autoconf/manual/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables

Does the following help to solve any problems:

./configure --libexecdir=\${exec_prefix}/lib$(uname -i)exec

What that does is define

libexecdir = ${exec_prefix}/libi386exec

in my src/Makefile rather than

libexecdir = ${exec_prefix}/libexec

Dan

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

On Wed, 4 Oct 2006, Reiner Steib wrote:

> I tried to install gnuplot-4.2.rc1 on GNU/Linux (SUSE 9.2) on both
> i686 and x86_64.
> 
> I want to install gnuplot to /usr/local which is shared between i686
> and x86_64 machines.  

This, rather than the interaction of autoconf's --program-suffix mechanism
with how we install gnuplot_x11, is the root of your problem.  I've worked 
in an NFS-mounted home directory shared among *completely* different
platforms (x86/Linux, Alpha/OSF1 and Mips/ULTRIX).  My experience is that
the only way to get that working properly is --exec-prefix, because that's
exactly what this option is designed to do.

One --prefix fits all, but each platform gets its own --exec-prefix.

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

Re: Linked Axes: I need to extract xtics positions.

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

On Wed, 4 Oct 2006, Daniel Farrell wrote:

> I'm trying to experiment with 'linked axes' in gnuplot. Rather than
> delving straight into the code (right away) I first want to test a few
> things by making a 'linked axes' simple script that controls gnuplot. To
> make it work, I need to know the positions at which gnuplot will (or has
> chosen to) place tics marks on the x1 axis. Is is possible to extract
> this data using gnuplot?

Just make a plot :-)

> Alternatively a more general approach: is there a command line function
> were I can pass in a column of data (text file) upon which it will
> return the location of where gnuplot with place tic marks? Would such a
> funciton be simple for anyone here to quickly pull together. It would
> take me quite a while to get use to the gnuplot code base to do so.

Your timing is somewhat awkward.  We just (finally) entered a release 
cycle.  We really don't have time to spend on new features right now.


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

Re: Linked Axes: I need to extract xtics positions.

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

> I need to use gnuplot to nicely space the x2 values in step #2.
>
>> Would it suffice to have GPVAL_X_TICS_FROM, GPVAL_X_TICS_TO, 
>> GPVAL_Y_TICS_FROM, etc.?
>
> It would work if I could get gnuplot to give me GPVAL_X_TICS_FROM, 
> GPVAL_X_TICS_TO and GPVAL_X_TICS_SPACING (assuming that spacing is linear - 
> which is good enough for me!)

I made a preliminary version of such a patch, see gnuplot Patches section on 
sourceforge, Patch nb. 1571696 "GPVAL_X_TICS_....". Feel free to continue if 
you need it.

---
PM

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

Ethan Merritt wrote:
> On Thursday 05 October 2006 12:07 pm, Daniel J Sebald wrote:
> 
>> > I just leave the patched executable in the patched source
>> > directory where it was built, and setenv GNUPLOT_DRIVER_DIR
>> > to point there if I want to test it.
>>
>>but that isn't exactly the most proficient method.  I'd have to keep
>>changing GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot"
>>and "mygnuplot"
> 
> 
> Huh?  We're talking about gnuplot_x11, not gnuplot.  It doesn't
> make any difference which gnuplot executable you are using.

Yes, unless the source file gplt_x11.c in gnuplot's src subdirectory is one of the files that is altered.  It hasn't happened in a major way for a while, but as recent as 7/21 was a small change.


>>From the standpoint of a multiuser environment like a computer
>>center
> 
> 
> Stop right there. The issue is not multi-user; the issue is
> multiple machines seen by *one* user.
> 
> I have two different machines at my desk (x86 and amd64) and
> have gnuplot installed also on 64-bit alpha and both 
> 32- and 64- bit irix machines on the same network. 
> Various windows on my desktop may be logged in to various of
> these machines.  Fun, huh?   

Right, I didn't state that clearly, I too was thinking a networked environment where a user might log in remotely or something.

> 
> And if my login directory is shared via NFS by some or all of
> these architectures, then the appropriate run path has to
> be constructed every time I log in, since if I log in on 
> a 32-bit Irix workstation the 64-bit linux executable isn't
> going to do me much good.
> 
> The last thing I want is to have to remember to type
> gnuplot_amd64 instead of gnuplot_irix5 depending on which
> machine is listening to the window I'm typing into.
> The name should always be "gnuplot", and the path should make
> it 'just work'.

But that isn't custom.  These versions are essentially the same version on a different environment.  I said there definitely needs to be the behavior you are describing.

All I'm saying is that it is conceivable that a person might want to have two slightly different version of gnuplot around with two different names.  This --program-suffix=? syntax seems like something for that.  The worst that can happen is that there ends up being a "gnuplot_x11" and "gnuplot_x11_spiff" that are the same exact program.

On the other hand, --program-suffix=? seems like a clumsy way of dealing with the multi-environment issue you are talking about; GNUPLOT_DRIVER_DIR is the big winner there.  (I wouldn't advocate GNUPLOT_DRIVER_DIR as a cure all for the case of creating custom or development versions.)

But GNUPLOT_DRIVER_DIR is run time; what about during build?  Well, from what I understand, the autoconf configuration method currently in place doesn't yet build good directory structure to make the multi-environment process seamless.  We need something like

/usr/local/lib<environment>/gnuplot/VERSION

which gets <environment> from, say, an environment variable defined on the machine in which gnuplot is compiled?

Am I right on that?

Dan

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

On Thursday 05 October 2006 12:07 pm, Daniel J Sebald wrote:
>  > I just leave the patched executable in the patched source
>  > directory where it was built, and setenv GNUPLOT_DRIVER_DIR
>  > to point there if I want to test it.
>
> but that isn't exactly the most proficient method.  I'd have to keep
> changing GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot"
> and "mygnuplot"

Huh?  We're talking about gnuplot_x11, not gnuplot.  It doesn't
make any difference which gnuplot executable you are using.

> From the standpoint of a multiuser environment like a computer
> center

Stop right there. The issue is not multi-user; the issue is
multiple machines seen by *one* user.

I have two different machines at my desk (x86 and amd64) and
have gnuplot installed also on 64-bit alpha and both 
32- and 64- bit irix machines on the same network. 
Various windows on my desktop may be logged in to various of
these machines.  Fun, huh?   

And if my login directory is shared via NFS by some or all of
these architectures, then the appropriate run path has to
be constructed every time I log in, since if I log in on 
a 32-bit Irix workstation the 64-bit linux executable isn't
going to do me much good.

The last thing I want is to have to remember to type
gnuplot_amd64 instead of gnuplot_irix5 depending on which
machine is listening to the window I'm typing into.
The name should always be "gnuplot", and the path should make
it 'just work'.

> One other comment is that I've tended to not so much think of
> gnuplot_x11 as being a separate program.  If we are at the point of
> considering gnuplot-x11 running on one machine and gnuplot on
> another, it might then be pertinent to start talking version numbers
> and having gnuplot check that its version is compatible with the
> gnuplot_x11 version.

That's a totally separate issue.
Version mis-match is already a problem on a single machine.
Usually you get an error message "gnuplot_x11: protocol error",
which isn't so bad as error messages go.



>
> Dan
>
> Ethan Merritt wrote:
> > I don't think this is the right approach, because it does
> > not truly allow for the general case of a mixed architecture
> > environment.  What if gnuplot_x11 is running on a different
> > machine than gnuplot?  What if gnuplot was built 64-bit, but
> > gnuplot_x11 was built 32-bit?
> >
> > What I have seen work for other program packages is to leave
> > the name of the executable unchanged, but install multiple
> > architecture-specific executables into parallel directories.
> > The correct executable is selected by virtue of the PATH
> > set for your current session. In the case of gnuplot you
> > could also use the GNUPLOT_DRIVER_DIR environmental variable
> > to control this, but you'd have to set it in an
> > architecture-dependent fashion via your login script.
> >
> > In other words, if we are to do this at all, I think the
> > correct approach is to leave the file name of gnuplot_x11
> > unchanged, but teach the install procedure to create a
> > directory name from the architecture type.  Or just add
> > a set of instructions for manual installation of this
> > one component in a mixed-architecture environment.
> >
> >>In my case, I used --program-suffix for a multi-architecture build.
> >>But previously I also used --program-suffix="-patched" to
> >> distinguish my modified version from the upstream version.  IIRC I
> >> also had to symlink gnuplot_x11 accordingly back then.

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

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

Are there two different situations?  One is sort of a custom version of 
gnuplot_x11, the other is more a general and portable version of gnuplot_x11.

Should there be a way to change the name of "gnuplot_x11"?  For custom versions 
perhaps?  There is this approach:

 > I just leave the patched executable in the patched source
 > directory where it was built, and setenv GNUPLOT_DRIVER_DIR
 > to point there if I want to test it.

but that isn't exactly the most proficient method.  I'd have to keep changing 
GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot" and "mygnuplot", and 
I wonder if I can run both at the same time.  From the standpoint of a multiuser 
environment like a computer center, that approach isn't so much "automating" the 
process as it is just shifting the burdon of configuring things to a later 
point.  For the person who is not the one building gnuplot it is difficult to 
remember such things.

If customization means that "gnuplot_x11" name should change, does there need to 
be independent control of name alteration for "gnuplot" and "gnuplot_x11"? 
Probably not.  If the user wants that kind of sophistication as a configure 
option then I'd think the user is smart enough to be moving the executables to 
desired directories.

There definitely needs to be multi-environment support, but I would argue that 
that should be taken care of without the users direction.  Shouldn't have to 
think about that.  I would think there are autoconf commands for that sort of thing.

It is hard to say what to do here.  My gut feeling is that there should be two 
methods of setting this up.

One other comment is that I've tended to not so much think of gnuplot_x11 as 
being a separate program.  If we are at the point of considering gnuplot-x11 
running on one machine and gnuplot on another, it might then be pertinent to 
start talking version numbers and having gnuplot check that its version is 
compatible with the gnuplot_x11 version.

Dan


Ethan Merritt wrote:
> I don't think this is the right approach, because it does
> not truly allow for the general case of a mixed architecture
> environment.  What if gnuplot_x11 is running on a different
> machine than gnuplot?  What if gnuplot was built 64-bit, but
> gnuplot_x11 was built 32-bit?
> 
> What I have seen work for other program packages is to leave
> the name of the executable unchanged, but install multiple
> architecture-specific executables into parallel directories.
> The correct executable is selected by virtue of the PATH
> set for your current session. In the case of gnuplot you
> could also use the GNUPLOT_DRIVER_DIR environmental variable
> to control this, but you'd have to set it in an 
> architecture-dependent fashion via your login script.
> 
> In other words, if we are to do this at all, I think the
> correct approach is to leave the file name of gnuplot_x11
> unchanged, but teach the install procedure to create a
> directory name from the architecture type.  Or just add
> a set of instructions for manual installation of this
> one component in a mixed-architecture environment.
>   
> 
>>In my case, I used --program-suffix for a multi-architecture build.
>>But previously I also used --program-suffix="-patched" to distinguish
>>my modified version from the upstream version.  IIRC I also had to
>>symlink gnuplot_x11 accordingly back then.
> 
> 

> 
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

I don't think this is the right approach, because it does
not truly allow for the general case of a mixed architecture
environment.  What if gnuplot_x11 is running on a different
machine than gnuplot?  What if gnuplot was built 64-bit, but
gnuplot_x11 was built 32-bit?

What I have seen work for other program packages is to leave
the name of the executable unchanged, but install multiple
architecture-specific executables into parallel directories.
The correct executable is selected by virtue of the PATH
set for your current session. In the case of gnuplot you
could also use the GNUPLOT_DRIVER_DIR environmental variable
to control this, but you'd have to set it in an 
architecture-dependent fashion via your login script.

In other words, if we are to do this at all, I think the
correct approach is to leave the file name of gnuplot_x11
unchanged, but teach the install procedure to create a
directory name from the architecture type.  Or just add
a set of instructions for manual installation of this
one component in a mixed-architecture environment.
  
> In my case, I used --program-suffix for a multi-architecture build.
> But previously I also used --program-suffix="-patched" to distinguish
> my modified version from the upstream version.  IIRC I also had to
> symlink gnuplot_x11 accordingly back then.

I just leave the patched executable in the patched source
directory where it was built, and setenv GNUPLOT_DRIVER_DIR
to point there if I want to test it.


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

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Reiner S. <rei...@im...>]

On Wed, Oct 04 2006, Reiner Steib wrote:

> [ For (my) convenience:
>   http://sourceforge.net/tracker/index.php?func=detail&aid=997481&group_id=2055&atid=102055
>   http://sourceforge.net/tracker/index.php?func=detail&aid=1531140&group_id=2055&atid=102055 ]
>
> Thanks, the fix works for me.  Unless there's a more clean solution,
> I'd suggest to install Dan's patch.

WRT [1531140] ...

In my case, I used --program-suffix for a multi-architecture build.
But previously I also used --program-suffix="-patched" to distinguish
my modified version from the upstream version.  IIRC I also had to
symlink gnuplot_x11 accordingly back then.  I.e. I agree with Dan's
comment:

,----[ Date: 2006-10-04 14:32, Sender: sebald ]
| In the bug report, Hans states that adding the suffix to gnuplot-x11
| isn't necessary.  However, I'd argue it is.  The person who uses
| "program-suffix" is someone who might create a special version of
| the program that has a recent patch or something.  If that patch
| effected gplt_x11.c then it would be nice to have the two different
| versions of gnuplot_x11 and gnuplot_x11-suffix.  E.g., someone wants
| the most recent official release and one with a great new feature,
| "gnuplot" and "gnuplotspif".
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Do we need a -no-init-file option?

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

On Thursday 05 October 2006 10:30 am, Reiner Steib wrote:
> On Thu, Oct 05 2006, Petr Mikulik wrote:
> >> We have no such option, but it is an interesting point.
> >>
> >> 2) setenv GNUPLOTRC "" ; gnuplot
> >
> > Isn't sufficient:
> >  	setenv HOME "."
> > ?
>
> For ./tutorial, it would be sufficient, I think.

I've already fixed the problem with the tutorial.
Further discussion should better focus on the general case.


> For the general case it wont be a good work around. 

Right. If you reset HOME for the current session before running
gnuplot, all sorts of things will break.  A better work-around,
though still ugly, would be

  cat "" > .gnuplot ; gnuplot

That will create an empty initialization file in the current
directory, which will be used in preference to the one in $HOME.
Of course has the unpleasant side effect of leaving empty files
strewn around, and could destroy a legitimate pre-existing
.gnuplot file.


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