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

Re: compile and install errors

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

On Wednesday 14 January 2009 09:15:36 Petr Mikulik wrote:
> 
> It is defined in variable.h in gnuplot-cvs, but not in gnuplot 4.2-cvs.
> Comparing variable.h in 4.2.4 and 4.2-cvs, these files are the same.
> Comparing util.c, they are different.
> 
> I have locale -- tested on OpenSUSE 10.3 and 11.1

Oops. Probably my fault, although I'm not sure what would have caused it.
Somehow the util.c from version 4.3 was incorrectly replicated into
the 4.2 CVS branch.  

I have now restored the correct 4.2 util.c into the repository,
and the normal ./prepare; ./configure; make should now work again.

	Ethan

Re: How to disable some terminals?

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

On Wednesday 14 January 2009 09:17:45 Mojca Miklavec wrote:
> On Wed, Jan 14, 2009 at 5:24 PM, Ethan A Merritt wrote:
> >
> >> The MacOS libreadline is apparently not powerful enough, so it
> >> wouldn't help. (But it would be nice to detect that deficiency and
> >> switch to built-in readline during configuration step instead of
> >> throwing an error.)
> >
> > If you can figure out how to detect and configure around the OSX
> > defective readline library, that would be great.  So far, I have not
> > seen a way to do this.  It claims to be readline, but it isn't.
> 
> How do you detect the standard libreadline?

      AC_CHECK_LIB(readline, remove_history,
        [TERMLIBS="-lreadline $gp_tcap $TERMLIBS"],, [${gp_tcap}])

We test for the presence of remove_history() because this was introduced
in whatever version of libreadline that is the minimal requirement.

> >> The built-in readline would be fine, but suboptimal (I've seen the
> >> switch that forces usage of built-in readline.)
> >
> > I have been told that the OSX "libreadline" library is actually a disguised
> > version of the BSD libedit.  Since as of recently gnuplot can use libedit
> > instead of libreadline, the best solution would be (if it works) would be
> > to force the --with-readline=bsd on OSX configurations.  Unfortunately,
> > I do not know if OSX also provides an un-wrapped libedit that doesn't
> > pretend to be libreadline.  Could you please try
> >  ./configure --with-readline=bsd
> > and see how it works?
> 
> It doesn't.
> 
> Making all in wxterminal
> make[3]: Nothing to be done for `all'.
> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
> -DBINDIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/bin\"
> -DX11_DRIVER_DIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/libexec/gnuplot/4.3\"
> -DGNUPLOT_PS_DIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/share/gnuplot/4.3/PostScript\"
> -DCONTACT=\"gnu...@li...\"
> -DHELPFILE=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/share/gnuplot/4.3/gnuplot.gih\"
> -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
> -I/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/include
> -I/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/include
>  -g -O2 -ObjC -MT command.o -MD -MP -MF ".deps/command.Tpo" -c -o
> command.o command.c; \
> then mv -f ".deps/command.Tpo" ".deps/command.Po"; else rm -f
> ".deps/command.Tpo"; exit 1; fi
> In file included from command.c:76:
> gp_hist.h:73:32: error: editline/readline.h: No such file or directory

Actually, that looks like maybe it *did* work.
It apparently found the library correctly, but then failed to find the 
corresponding header files.  Is there an OSX developer's kit or something
that contains the header files for system libraries?




> command.c: In function 'rlgets':
> command.c:2427: error: invalid type argument of '->'
> make[3]: *** [command.o] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> There are the following files (not sure about the first two, but the
> last four are from Mac OS X Developer tools that need to be installed
> in order to be able to compile anything).
> 
> /usr/lib/libedit.2.dylib
> /usr/lib/libedit.dylib
> /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libedit.2.dylib
> /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libedit.dylib
> /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libedit.2.dylib
> /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libedit.dylib
> 
> But I only have
>     /sw/include/editline/readline.h
> and /sw doesn't cound into standard libraries (that's fink).
> 
> There's also
>     /Developer/SDKs/MacOSX10.4u.sdk/usr/include/readline/readline.h
> but that path is not included when building gnuplot.
> 
> Mojca
> 



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

Re: How to disable some terminals?

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

On Wed, Jan 14, 2009 at 5:24 PM, Ethan A Merritt wrote:
>
>> The MacOS libreadline is apparently not powerful enough, so it
>> wouldn't help. (But it would be nice to detect that deficiency and
>> switch to built-in readline during configuration step instead of
>> throwing an error.)
>
> If you can figure out how to detect and configure around the OSX
> defective readline library, that would be great.  So far, I have not
> seen a way to do this.  It claims to be readline, but it isn't.

How do you detect the standard libreadline?

>> The built-in readline would be fine, but suboptimal (I've seen the
>> switch that forces usage of built-in readline.)
>
> I have been told that the OSX "libreadline" library is actually a disguised
> version of the BSD libedit.  Since as of recently gnuplot can use libedit
> instead of libreadline, the best solution would be (if it works) would be
> to force the --with-readline=bsd on OSX configurations.  Unfortunately,
> I do not know if OSX also provides an un-wrapped libedit that doesn't
> pretend to be libreadline.  Could you please try
>  ./configure --with-readline=bsd
> and see how it works?

It doesn't.

Making all in wxterminal
make[3]: Nothing to be done for `all'.
if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/bin\"
-DX11_DRIVER_DIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/libexec/gnuplot/4.3\"
-DGNUPLOT_PS_DIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/share/gnuplot/4.3/PostScript\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/share/gnuplot/4.3/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
-I/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/include
-I/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/include
 -g -O2 -ObjC -MT command.o -MD -MP -MF ".deps/command.Tpo" -c -o
command.o command.c; \
then mv -f ".deps/command.Tpo" ".deps/command.Po"; else rm -f
".deps/command.Tpo"; exit 1; fi
In file included from command.c:76:
gp_hist.h:73:32: error: editline/readline.h: No such file or directory
command.c: In function 'rlgets':
command.c:2427: error: invalid type argument of '->'
make[3]: *** [command.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

There are the following files (not sure about the first two, but the
last four are from Mac OS X Developer tools that need to be installed
in order to be able to compile anything).

/usr/lib/libedit.2.dylib
/usr/lib/libedit.dylib
/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libedit.2.dylib
/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libedit.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libedit.2.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libedit.dylib

But I only have
    /sw/include/editline/readline.h
and /sw doesn't cound into standard libraries (that's fink).

There's also
    /Developer/SDKs/MacOSX10.4u.sdk/usr/include/readline/readline.h
but that path is not included when building gnuplot.

Mojca

Re: compile and install errors

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

> > I've uncommented this line, compiled further, and then I'm getting messages 
> > that set_numeric_locale and reset_numeric_locale are not known. Has not 
> > ./configure overlooked some of my missing libraries?
> > 
> > > 1. in compiling gnuplot 4.2 cvs
> > > util.c: In function ‘gprintf’:
> > > util.c:757: error: invalid type argument of ‘unary *’
> > > make[3]: *** [util.o] Error 1
> > > 
> > > The line is:
> > >     /* dot is the default decimalsign we will be replacing */
> > >     dot = *get_decimal_locale();
> > > 
> > > The strange thing is that
> > > 	grep -R get_decimal_locale *
> > > does not find this routine in gnuplot source and /usr/include.
> 
> It is defined in variable.h
> 
> It looks to me that your configuration script has not correctly detected
> whether your system supports LOCALE.  From the error messages, I guess
> that your system lacks locale support, but configure didn't notice that.
> Or perhaps you have more than one libc, but one of them has locale
> support and the other doesn't?

It is defined in variable.h in gnuplot-cvs, but not in gnuplot 4.2-cvs.
Comparing variable.h in 4.2.4 and 4.2-cvs, these files are the same.
Comparing util.c, they are different.

I have locale -- tested on OpenSUSE 10.3 and 11.1.

---
PM

Re: compile and install errors

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

On Wednesday 14 January 2009, Petr Mikulik wrote:
> I've uncommented this line, compiled further, and then I'm getting messages 
> that set_numeric_locale and reset_numeric_locale are not known. Has not 
> ./configure overlooked some of my missing libraries?
> 
> > I see there are two errors:
> > 
> > 1. in compiling gnuplot 4.2 cvs
> > gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term 
> > -DBINDIR=\"/usr/local/bin\" 
> > -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.2\" 
> > -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.2/PostScript\" 
> > -DCONTACT=\"http://sourceforge.net/projects/gnuplot\" 
> > -DHELPFILE=\"/usr/local/share/gnuplot/4.2/gnuplot.gih\" -I/usr/include 
> > -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 
> > -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    
> > -g -O2 -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
> > util.c: In function ‘gprintf’:
> > util.c:757: error: invalid type argument of ‘unary *’
> > make[3]: *** [util.o] Error 1
> > 
> > The line is:
> >     /* dot is the default decimalsign we will be replacing */
> >     dot = *get_decimal_locale();
> > 
> > The strange thing is that
> > 	grep -R get_decimal_locale *
> > does not find this routine in gnuplot source and /usr/include.

It is defined in variable.h

It looks to me that your configuration script has not correctly detected
whether your system supports LOCALE.  From the error messages, I guess
that your system lacks locale support, but configure didn't notice that.
Or perhaps you have more than one libc, but one of them has locale
support and the other doesn't?


-- 
Ethan A Merritt

Re: How to disable some terminals?

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

On Wednesday 14 January 2009, Mojca Miklavec wrote:
> On Wed, Jan 14, 2009 at 11:48 AM, Timothée Lecomte
> <tim...@lp...> wrote:
> > Mojca Miklavec a écrit :
> >>
> >
> >> I also got some problems with libreadline. I thought that configure
> >> has been fixed to recognise the lack of proper libreadline, but well
> >> ... I have compiled it now and it probably works, though I cannot
> >> figure out how to build it statically into gnuplot.
> >>
> >> Thanks,
> >>    Mojca
> >>
> >
> > Do you want MacOS libreadline to be built statically in gnuplot, or do you
> > want gnuplot's built-in readline to be used instead of what configure has
> > found ?
> 
> The MacOS libreadline is apparently not powerful enough, so it
> wouldn't help. (But it would be nice to detect that deficiency and
> switch to built-in readline during configuration step instead of
> throwing an error.)

If you can figure out how to detect and configure around the OSX
defective readline library, that would be great.  So far, I have not
seen a way to do this.  It claims to be readline, but it isn't.

> The built-in readline would be fine, but suboptimal (I've seen the
> switch that forces usage of built-in readline.)

I have been told that the OSX "libreadline" library is actually a disguised
version of the BSD libedit.  Since as of recently gnuplot can use libedit
instead of libreadline, the best solution would be (if it works) would be
to force the --with-readline=bsd on OSX configurations.  Unfortunately,
I do not know if OSX also provides an un-wrapped libedit that doesn't
pretend to be libreadline.  Could you please try 
  ./configure --with-readline=bsd
and see how it works?


> I would like to compile readline myself and use that one, built in statically.
> 
> I did:
> 
> export PATH="$prefix/bin:$PATH"
> export LDFLAGS="-L$prefix/lib"
> export CPPFLAGS="-I$prefix/include"
> 
> cd libs
> wget -c -N http://ftp.gnu.org/gnu/readline/readline-5.2.tar.gz
> tar xzf readline-5.2.tar.gz
> cd readline-5.2
> ./configure --prefix="$prefix" --disable-shared
> make && make install || exit 1
> ...
> ./configure --prefix="$prefix"  \
>            --with-png="$prefix" --with-gd="$prefix" --without-x
> --without-cairo --disable-wxwidgets
> make
> 
> but otool still reports (among other dependencies) the dependency on
> libreadline:
> 
> > otool -L src/gnuplot
> src/gnuplot:
>         /Users/mojca/gnuplot/git/gnuplot-static/support_libs/lib/libreadline.5.2.dylib
> (compatibility version 5.0.0, current version 5.2.0)
> 
> The png and gd libraries do not work properly, but that's yet another
> issue that I need to inspect.
> 
> Thanks,
>    Mojca



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

Re: How to disable some terminals?

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

On Wed, Jan 14, 2009 at 11:48 AM, Timothée Lecomte
<tim...@lp...> wrote:
> Mojca Miklavec a écrit :
>>
>> ...
>> But still weird. The X11 terminal doesn't get built, but I still get
>> dependencies on
>>        /usr/X11R6/lib/libXpm.4.dylib (compatibility version 4.11.0,
>> current version 4.11.0)
>>        /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0,
>> current version 6.2.0)
>>        /usr/X11R6/lib/libfontconfig.1.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>>        /usr/X11R6/lib/libfreetype.6.dylib (compatibility version
>> 6.3.0, current version 6.3.0)
>>
>
> In config.log you may see where these come from. Attach it and we will help.
>
>> I also got some problems with libreadline. I thought that configure
>> has been fixed to recognise the lack of proper libreadline, but well
>> ... I have compiled it now and it probably works, though I cannot
>> figure out how to build it statically into gnuplot.
>>
>> Thanks,
>>    Mojca
>>
>
> Do you want MacOS libreadline to be built statically in gnuplot, or do you
> want gnuplot's built-in readline to be used instead of what configure has
> found ?

The MacOS libreadline is apparently not powerful enough, so it
wouldn't help. (But it would be nice to detect that deficiency and
switch to built-in readline during configuration step instead of
throwing an error.)

The built-in readline would be fine, but suboptimal (I've seen the
switch that forces usage of built-in readline.)

I would like to compile readline myself and use that one, built in statically.

I did:

export PATH="$prefix/bin:$PATH"
export LDFLAGS="-L$prefix/lib"
export CPPFLAGS="-I$prefix/include"

cd libs
wget -c -N http://ftp.gnu.org/gnu/readline/readline-5.2.tar.gz
tar xzf readline-5.2.tar.gz
cd readline-5.2
./configure --prefix="$prefix" --disable-shared
make && make install || exit 1
...
./configure --prefix="$prefix"  \
           --with-png="$prefix" --with-gd="$prefix" --without-x
--without-cairo --disable-wxwidgets
make

but otool still reports (among other dependencies) the dependency on
libreadline:

> otool -L src/gnuplot
src/gnuplot:
        /Users/mojca/gnuplot/git/gnuplot-static/support_libs/lib/libreadline.5.2.dylib
(compatibility version 5.0.0, current version 5.2.0)

The png and gd libraries do not work properly, but that's yet another
issue that I need to inspect.

Thanks,
   Mojca

Re: compile and install errors

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

I've uncommented this line, compiled further, and then I'm getting messages 
that set_numeric_locale and reset_numeric_locale are not known. Has not 
./configure overlooked some of my missing libraries?

> I see there are two errors:
> 
> 1. in compiling gnuplot 4.2 cvs
> gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term 
> -DBINDIR=\"/usr/local/bin\" 
> -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.2\" 
> -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.2/PostScript\" 
> -DCONTACT=\"http://sourceforge.net/projects/gnuplot\" 
> -DHELPFILE=\"/usr/local/share/gnuplot/4.2/gnuplot.gih\" -I/usr/include 
> -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    
> -g -O2 -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
> util.c: In function ‘gprintf’:
> util.c:757: error: invalid type argument of ‘unary *’
> make[3]: *** [util.o] Error 1
> 
> The line is:
>     /* dot is the default decimalsign we will be replacing */
>     dot = *get_decimal_locale();
> 
> The strange thing is that
> 	grep -R get_decimal_locale *
> does not find this routine in gnuplot source and /usr/include.

Re: How to disable some terminals?

[Timothée L. <tim...@lp...>]

Mojca Miklavec a écrit :
> ...
> But still weird. The X11 terminal doesn't get built, but I still get
> dependencies on
>         /usr/X11R6/lib/libXpm.4.dylib (compatibility version 4.11.0,
> current version 4.11.0)
>         /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0,
> current version 6.2.0)
>         /usr/X11R6/lib/libfontconfig.1.dylib (compatibility version
> 1.0.0, current version 1.0.0)
>         /usr/X11R6/lib/libfreetype.6.dylib (compatibility version
> 6.3.0, current version 6.3.0)
>   

In config.log you may see where these come from. Attach it and we will help.

> I also got some problems with libreadline. I thought that configure
> has been fixed to recognise the lack of proper libreadline, but well
> ... I have compiled it now and it probably works, though I cannot
> figure out how to build it statically into gnuplot.
>
> Thanks,
>     Mojca
>   
Do you want MacOS libreadline to be built statically in gnuplot, or do 
you want gnuplot's built-in readline to be used instead of what 
configure has found ?

Best regards,

Timothée

Re: How to disable some terminals?

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

On Wed, Jan 14, 2009 at 10:08 AM, Timothée Lecomte wrote:
> Mojca Miklavec a écrit :
>>
>> how can I build gnuplot *without* wxt
>> terminal, cairo-based pdf and png terminals and X? --without-wxt
>> doesn't make any difference.
>
> According to "./configure --help", it is:
> "--without-cairo" to avoid cairo-based pdf and mng terminals
> "--disable-wxwidgets" to avoid wxt terminal
> "--without-x" to avoid X11 terminal

Thanks a lot and sorry for not reading the documentation more carefully.

But still weird. The X11 terminal doesn't get built, but I still get
dependencies on
        /usr/X11R6/lib/libXpm.4.dylib (compatibility version 4.11.0,
current version 4.11.0)
        /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0,
current version 6.2.0)
        /usr/X11R6/lib/libfontconfig.1.dylib (compatibility version
1.0.0, current version 1.0.0)
        /usr/X11R6/lib/libfreetype.6.dylib (compatibility version
6.3.0, current version 6.3.0)

I also got some problems with libreadline. I thought that configure
has been fixed to recognise the lack of proper libreadline, but well
... I have compiled it now and it probably works, though I cannot
figure out how to build it statically into gnuplot.

Thanks,
    Mojca

Re: How to disable some terminals?

[Timothée L. <tim...@lp...>]

Mojca Miklavec a écrit :
> ...
>
> how can I build gnuplot *without* wxt
> terminal, cairo-based pdf and png terminals and X? --without-wxt
> doesn't make any difference.
>
> Thanks a lot,
>     Mojca
>
>   
Hi,

According to "./configure --help", it is:
"--without-cairo" to avoid cairo-based pdf and mng terminals
"--disable-wxwidgets" to avoid wxt terminal
"--without-x" to avoid X11 terminal

Best regards,

Timothée

Re: compile and install errors

[Timothée L. <tim...@lp...>]

Petr Mikulik a écrit :
> I see there are two errors:
>
> 1. in compiling gnuplot 4.2 cvs
> ...
> util.c: In function ‘gprintf’:
> util.c:757: error: invalid type argument of ‘unary *’
> ...
>   

Don't know.

> 2. making current cvs fails:
> Making all in term
> make[2]: Entering directory `gnuplot-cvs/term'
> make[2]: *** No rule to make target `js/*.js', needed by `all-am'.  Stop.
>   

For this one, you have to run "cvs update -d" instead of "cvs update", 
because the latter does not checkout new directories, like the new term/js.

Best regards,

Timothée

compile and install errors

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

I see there are two errors:

1. in compiling gnuplot 4.2 cvs
gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term 
-DBINDIR=\"/usr/local/bin\" 
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.2\" 
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.2/PostScript\" 
-DCONTACT=\"http://sourceforge.net/projects/gnuplot\" 
-DHELPFILE=\"/usr/local/share/gnuplot/4.2/gnuplot.gih\" -I/usr/include 
-I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    
-g -O2 -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
util.c: In function ‘gprintf’:
util.c:757: error: invalid type argument of ‘unary *’
make[3]: *** [util.o] Error 1

The line is:
    /* dot is the default decimalsign we will be replacing */
    dot = *get_decimal_locale();

The strange thing is that
	grep -R get_decimal_locale *
does not find this routine in gnuplot source and /usr/include.

***

2. making current cvs fails:
Making all in term
make[2]: Entering directory `gnuplot-cvs/term'
make[2]: *** No rule to make target `js/*.js', needed by `all-am'.  Stop.

How to disable some terminals?

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

Hello,

I'm trying to use Mike Sutton's script to compile all the needed
gnuplot libraries statically, but I have some problems with
interfering libraries.

So a really simple question: how can I build gnuplot *without* wxt
terminal, cairo-based pdf and png terminals and X? --without-wxt
doesn't make any difference.

Thanks a lot,
    Mojca

Re: Patch for makefile.mgw using gdlib-config

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

Hello Petr Mikulik

Sorry

>    ftp://ftp.microsoft.com/softlib/mslfiles/hcwsetup.exe

The above does not work sometimes.
(I tried several times it was successful a few times.)

I googled again and found the below

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=34D35502-4DE9-4676-952C-34CC7F64F098

This seemsto be official distribution at present.

Regards

Tatsuro

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

> Hello Petr Mikulik
> 
> Your patch worked fine.  Thanks!!
> 
> But I have also addressed you the following: 
> 
> ******************
> # To compile the .hlp file you need hcw either out of Microsoft SDK or MS Help
> # Workshop. The latter can be obtained at www.helpmaster.com/help/devaids.htm.
> # Put the path to hcw here unless it is already in PATH:
> #HCWPATH = /c/Program\ Files/Help\ Workshop/
> 
> 
> I found that microsoft help work shop has been no longer available from 
> 
>    www.helpmaster.com/help/devaids.htm.
> 
> that was indicated in makefile.mgw
> 
> I also have found that it is now available from
> 
>    ftp://ftp.microsoft.com/softlib/mslfiles/hcwsetup.exe
> *********************
> 
> Regards
> 
> Tatsuro 
> 
> --- Petr Mikulik <mi...@ph...> wrote:
> 
> > > The current gd (gd-2.0.36RC1) has gdlib-config, which enable us to get 
> > > information for configuration of the gd libraries and tools.  Therefore it 
> > > is better to use it for makefile,mgw. Perhaps similar modification can be 
> > > made for makefile.cyg.
> > 
> > Compiling of gd by means of ./configure did not work for me. Thus I'm 
> > proposing the enclosed patch for makefile.mgw. Does it work for you?
> > 
> > ---
> > PM
> > > --- makefile.mgw	2008-11-23 08:55:15.000000000 +0100
> > +++ makefile-new.mgw	2009-01-11 22:33:57.000000000 +0100
> > @@ -47,10 +47,14 @@
> >  # If libgd has been compiled with TrueType font support, then you can use
> >  # scaled TrueType fonts. If not, then uncomment FREETYPE.
> >  # Requires GD, PNG and Z libraries, optionally libfreetype.
> > +# In some cases, libfreetype can depend on additional libraries such as
> > +# fontconfig or iconv; then, uncomment GDAUTOCONFIGLIBS so that all of the
> > +# depending libs for linking will be taken from gdlib-config.
> >  #
> >  NEWGD=1
> >  JPEG=1
> >  FREETYPE=1
> > +#GDAUTOCONFIGLIBS=1
> >  
> >  # PDF device driver
> >  # Requires PNG and Z libraries based on particular PDF library used, and
> > @@ -201,18 +205,27 @@
> >  
> >  ifdef PNG
> >    CFLAGS += -DHAVE_LIBPNG
> > -  TERMLIBS += -lpng -lz
> > +  ifndef GDAUTOCONFIGLIBS
> > +    TERMLIBS += -lpng -lz
> > +  endif
> >  endif
> >  
> >  ifdef NEWGD
> >    CFLAGS += -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG
> >  ifdef JPEG
> >    CFLAGS += -DHAVE_GD_JPEG
> > -  TERMLIBS += -ljpeg
> > +  ifndef GDAUTOCONFIGLIBS
> > +    TERMLIBS += -ljpeg
> > +  endif
> >  endif
> >  ifdef FREETYPE
> >    CFLAGS += -DHAVE_GD_TTF
> > -  TERMLIBS += -lfreetype
> > +  ifndef GDAUTOCONFIGLIBS
> > +    TERMLIBS += -lfreetype
> > +  endif
> > +endif
> > +ifdef GDAUTOCONFIGLIBS
> > +  TERMLIBS += $(shell gdlib-config --libs)
> >  endif
> >  endif
> >  
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Patch for makefile.mgw using gdlib-config

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

Hello Petr Mikulik

Your patch worked fine.  Thanks!!

But I have also addressed you the following: 

******************
# To compile the .hlp file you need hcw either out of Microsoft SDK or MS Help
# Workshop. The latter can be obtained at www.helpmaster.com/help/devaids.htm.
# Put the path to hcw here unless it is already in PATH:
#HCWPATH = /c/Program\ Files/Help\ Workshop/


I found that microsoft help work shop has been no longer available from 

   www.helpmaster.com/help/devaids.htm.

that was indicated in makefile.mgw

I also have found that it is now available from

   ftp://ftp.microsoft.com/softlib/mslfiles/hcwsetup.exe
*********************

Regards

Tatsuro 

--- Petr Mikulik <mi...@ph...> wrote:

> > The current gd (gd-2.0.36RC1) has gdlib-config, which enable us to get 
> > information for configuration of the gd libraries and tools.  Therefore it 
> > is better to use it for makefile,mgw. Perhaps similar modification can be 
> > made for makefile.cyg.
> 
> Compiling of gd by means of ./configure did not work for me. Thus I'm 
> proposing the enclosed patch for makefile.mgw. Does it work for you?
> 
> ---
> PM
> > --- makefile.mgw	2008-11-23 08:55:15.000000000 +0100
> +++ makefile-new.mgw	2009-01-11 22:33:57.000000000 +0100
> @@ -47,10 +47,14 @@
>  # If libgd has been compiled with TrueType font support, then you can use
>  # scaled TrueType fonts. If not, then uncomment FREETYPE.
>  # Requires GD, PNG and Z libraries, optionally libfreetype.
> +# In some cases, libfreetype can depend on additional libraries such as
> +# fontconfig or iconv; then, uncomment GDAUTOCONFIGLIBS so that all of the
> +# depending libs for linking will be taken from gdlib-config.
>  #
>  NEWGD=1
>  JPEG=1
>  FREETYPE=1
> +#GDAUTOCONFIGLIBS=1
>  
>  # PDF device driver
>  # Requires PNG and Z libraries based on particular PDF library used, and
> @@ -201,18 +205,27 @@
>  
>  ifdef PNG
>    CFLAGS += -DHAVE_LIBPNG
> -  TERMLIBS += -lpng -lz
> +  ifndef GDAUTOCONFIGLIBS
> +    TERMLIBS += -lpng -lz
> +  endif
>  endif
>  
>  ifdef NEWGD
>    CFLAGS += -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG
>  ifdef JPEG
>    CFLAGS += -DHAVE_GD_JPEG
> -  TERMLIBS += -ljpeg
> +  ifndef GDAUTOCONFIGLIBS
> +    TERMLIBS += -ljpeg
> +  endif
>  endif
>  ifdef FREETYPE
>    CFLAGS += -DHAVE_GD_TTF
> -  TERMLIBS += -lfreetype
> +  ifndef GDAUTOCONFIGLIBS
> +    TERMLIBS += -lfreetype
> +  endif
> +endif
> +ifdef GDAUTOCONFIGLIBS
> +  TERMLIBS += $(shell gdlib-config --libs)
>  endif
>  endif
>  
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Patch for makefile.mgw using gdlib-config

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

> The current gd (gd-2.0.36RC1) has gdlib-config, which enable us to get 
> information for configuration of the gd libraries and tools.  Therefore it 
> is better to use it for makefile,mgw. Perhaps similar modification can be 
> made for makefile.cyg.

Compiling of gd by means of ./configure did not work for me. Thus I'm 
proposing the enclosed patch for makefile.mgw. Does it work for you?

---
PM

Re: build script for Gnuplot under MinGW/Msys, Solaris, Linux

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

On Sun, Jan 4, 2009 at 3:34 PM, m sutton wrote:
> Hi all,
>
> I have recently created a script to build Gnuuplot on Windows under the MinGW/Msys environment with PNG, Freetype and GD.  I have also used this for Solaris and Linux environments.  This is based on a CVS snapshot from about 9 months ago.
>
>
> Here are the versions of the libraries I used (freetype-2.3.5, gd-2.0.33, libpng-1.2.18, zlib-1.2.3).  The build script assumes that these libraries are in .tar.gz files located in the top of the Gnuplot tree.  The script will build static libraries just for Gnuplot to use.  I often work on older Linux boxes that I can't change and don't have the newer versions of these libraries.
>
> The one thing I had to to was modify the gd.h file to never build a DLL.  So I created a copy of gd.h named gd.h.win32 to prevent the DLL.
>
> I put the script in the top level of the Gnuplot tree and run it from there.  I simply called it build.sh.
>
> Hope it helps someone,
>
> Mike Sutton

Hello,

I might contact you off-line, but the binary I compiled with a
slightly modified script that you posted still resulted in plethora of
dependencies on Mac OS X. In particular it would be nice to remove all
those dependencies that begin with /sw/:
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.3)
        /sw/lib/libpng12.0.dylib (compatibility version 30.0.0,
current version 30.0.0)
        /usr/X11R6/lib/libXpm.4.dylib (compatibility version 4.11.0,
current version 4.11.0)
        /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0,
current version 6.2.0)
        /usr/X11R6/lib/libfontconfig.1.dylib (compatibility version
1.0.0, current version 1.0.0)
        /usr/X11R6/lib/libfreetype.6.dylib (compatibility version
6.3.0, current version 6.3.0)

Libraries that were not addressed (and could be removed later):
        /sw/lib/libreadline.5.dylib (compatibility version 5.0.0,
current version 5.0.0)
        /sw/lib/libhistory.5.dylib (compatibility version 5.0.0,
current version 5.0.0)
        /sw/lib/ncurses/libncurses.5.dylib (compatibility version
5.0.0, current version 5.0.0)
        /sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current
version 7.0.0)
        /sw/lib/libpdf.6.dylib (compatibility version 7.0.0, current
version 7.2.0)
        /sw/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
(compatibility version 1.0.0, current version 1.0.0)

These dependencies are OK:
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 567.40.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.4.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.11)

In any case: thanks a lot for showing me where to start. I need to
figure out how to solve the remaining dependencies, but it's a good
start.

> case "$os" in
>    MINGW32*) make -C src -f ../config/makefile.mgw2 || exit 1
>
>    *)        make || exit 1
> esac

This portion of code fails here (I need to figure out why), so I have
removed the "case" temporary and only put "make" on that place.

Thanks again,
    Mojca

New terminal driver: set term canvas

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

I have added Bruce Lueckenhoff's great new terminal driver for the
HTML 5 canvas to CVS.  This is nice work (thanks, Bruce!).  

Check out the full demo set as rendered by "set term canvas":

   http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/

You need a browser that supports HTML 5, which as I understand it
means firefox, opera, safari, or IE (I think IE needs a plugin?).

The new terminal supports all of the new gnuplot graphics options
including alpha-channel transparency, and as shown on the front
page of the demo set offers promise for support of client-side mousing.

The only real weak points are the lack of universal browser support
for HTML 5 and the poor-to-nonexistent support for text output in
the canvas spec.  The driver is currently using a public domain
javascript implementation of a basic ascii font from the Hershey
font set.  The Hershey collection also contains greek fonts, etc,
so if no better option comes along we could port more characters
to the javascript implementation for scientific plotting.


People working on SVG please take note:
---------------------------------------
There is now a new directory,  .../term/js, in the source tree.
It is installed in /usr/local/share/gnuplot/4.3/ in parallel to
the .../term/PostScript directory, and selected by the analogous
environmental variable GNUPLOT_JS_DIR. 

The "interactive SVG" patches that are floating around can 
share this directory to hold their javascript files.
 

-- 
Ethan A Merritt

Re: build script for Gnuplot under MinGW/Msys, Solaris, Linux

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

On Sun, Jan 4, 2009 at 3:34 PM, m sutton <mw...@us...> wrote:
> Hi all,
>
> I have recently created a script to build Gnuuplot on Windows under the MinGW/Msys environment with PNG, Freetype and GD.  I have also used this for Solaris and Linux environments.  This is based on a CVS snapshot from about 9 months ago.
>
> Here are the versions of the libraries I used (freetype-2.3.5, gd-2.0.33, libpng-1.2.18, zlib-1.2.3).  The build script assumes that these libraries are in .tar.gz files located in the top of the Gnuplot tree.  The script will build static libraries just for Gnuplot to use.  I often work on older Linux boxes that I can't change and don't have the newer versions of these libraries.

Thanks a lot! I'm about to start testing (and will report the
findings), but I have been wating for such a patch/script for ages.

Mojca

Re: [transferred from Email] Providing/exporting a table of plot style properties

[Ralf J. <jue...@cs...>]

On Sun, 4 Jan 2009, Hans-Bernhard Bröker wrote:

>> Ralf's proposed table would also hold properties like
>> PLOT_STYLE_HAS_FILL that are currently single bits set in the
>> line style definitions in gp_types.h
>
> I agree that that part would make sense.
>
>> As you move into that kind of question, I start to think that
>> the whole idea of a fixed set of properties for a given plot
>> type breaks down.
>
> Indeed.  The original design has been thoroughly swamped under by new 
> features.  We're doing so much stuff outside (or in conflict with) the 
> concept of plot styles that it's hard to see what it was originally meant to 
> be: a complete description of how a given dataset would be displayed.
> And not a lot of that is described too well in the documentation, either...

Hm, aren't you mixing different things here?
A feature like 'using xticslabel(1)' is not specific to plot-styles,
it works for all of them. These newer features may have affected
the parts of the data reading machinery that currently includes
plot style properties hard-coded (plot2d.c:get_data()), but that
does not make them plot style properties.

Here are the properties that I consider worth knowing; as a direct
user of gnuplot, I sometimes want to job my memory and look them up;
as an author of some other application that generates gnuplot script,
I want to query them:

* plot style keyword
* number of basic data colums in 2d (excluding lc variable, ps variable)
* if applicable, number of basic data colums in 3d
* does expect non-numeric data
* does accept line style specifiers
* does accept point style specifiers
* does accept fill style specifiers

The two questions now are: Is a help command delivering such a
summary a desirable feature? Is it a good idea to fix this in code
as a table?


Ralf

Re: build script for Gnuplot under MinGW/Msys, Solaris, Linux

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

Hello

To my knowledge, dll problem occurs only on gd for msys+mingw build  I have used gd-2.0.36RC1 statilc
libraries with -DNONDLL option for cppflags and --disable-shared at ./configure.

As the external libraries, I added the #define NONDLL 1 at the very top of gd.h.

Further components required can be taken from GnuWin32 and GTK+ tool kit for windows.

download GTK+ for windows
http://www.gtk.org/download-windows.html

GnuWin32 
http://gnuwin32.sourceforge.net/

I modifed makefile.mgw,

# Do you want some special optimization?
# -mpentium means optimise for Pentium processor
# -mpentiumpro means optimize for Pentium II and Pro procesors
CFLAGS =
  |
  V
# Do you want some special optimization?
# -mpentium means optimise for Pentium processor
# -mpentiumpro means optimize for Pentium II and Pro procesors
CFLAGS=-I/mingw/include -I/GnuWin32/include -I/WinDevTools/include
LDFLAGS=-L/mingw/lib -L/GnuWin32/lib -L/GnuWin32/bin -L/WinDevTools/lib -L/WinDevTools/bin

In /WinDevTools, there are GTK+ toolkit and other tools. 
Msys fstab are set for /mingw, /Gnuwin32, and /WinDevTools.

This is also one of the examples.

Regards

Tatsuro
  


--- m sutton <mw...@us...> wrote:

> Hi all,
> 
> I have recently created a script to build Gnuuplot on Windows under the MinGW/Msys environment
> with PNG, Freetype and GD.  I have also used this for Solaris and Linux environments.  This is
> based on a CVS snapshot from about 9 months ago.
> 
> 
> Here are the versions of the libraries I used (freetype-2.3.5, gd-2.0.33, libpng-1.2.18,
> zlib-1.2.3).  The build script assumes that these libraries are in .tar.gz files located in the
> top of the Gnuplot tree.  The script will build static libraries just for Gnuplot to use.  I
> often work on older Linux boxes that I can't change and don't have the newer versions of these
> libraries.
> 
> The one thing I had to to was modify the gd.h file to never build a DLL.  So I created a copy of
> gd.h named gd.h.win32 to prevent the DLL.
> 
> I put the script in the top level of the Gnuplot tree and run it from there.  I simply called it
> build.sh.
> 
> Hope it helps someone,
> 
> Mike Sutton
> 
> BTW some email readers might mess up the line wrap.
> 
> 
> -----------------------
> #!/bin/sh
> # This is a Bourne shell script
> #
> # This script builds the required support libraries for using Gnuplot
> # with GDLIB with TrueType font support.
> #
> # MODIFICATIONS:
> # 05-Mar-2008    Initially generated... MWS
> #----------------------------------------------------------------------
> 
> USAGE="`basename $0`: [-sZPFG]
> 
> where
> -s - skip the unpacking step
> -Z - skip building zlib
> -P - skip building libpng
> -F - skip building freetype
> -G - skip building gd
> "
> 
> # initialize variables
> unpack=true
> build_zlib=true
> build_png=true
> build_freetype=true
> build_gd=true
> 
> # parse command line options
> 
> while getopts hsZPFG opt
> do
>    case $opt in
>    s)           unpack=false;;
>    Z)           build_zlib=false;;
>    P)           build_png=false;;
>    F)           build_freetype=false;;
>    G)           build_gd=false;;
>    h| ?)    echo "$USAGE"
>         exit 1;;
> 
>    esac
> done
> shift `expr $OPTIND - 1`
> 
> freetype="freetype-2.3.5"
> gd="gd-2.0.33"
> png="libpng-1.2.18"
> zlib="zlib-1.2.3"
> 
> unpack_list="$zlib $png $gd $freetype "
> 
> curdir=`pwd`
> 
> # location for support libraries
> gnutmp="support_libs"
> buildtmp="ztmp"
> 
> ZCAT=gzcat
> 
> os=`uname -s`
> case "$os" in
>     Linux) ZCAT=zcat;;
>     MINGW32*) ZCAT="gunzip -c";;
> esac
> 
> 
> test -d "$gnutmp" || mkdir "$gnutmp"
> test -d "$buildtmp" || mkdir "$buildtmp"
> 
> cd "$buildtmp"
> $unpack && for name in $unpack_list ; do
>     if [ ! -d "$name" ] ; then
>     echo "unpacking $name"
>     $ZCAT ../${name}.tar.gz | tar -xf - || exit 1
>     fi
> done
> 
> 
> prefix="$curdir/$gnutmp"
> 
> PATH="$prefix/bin:$PATH"
> export PATH
> 
> LDFLAGS="-L$prefix/lib"
> export LDFLAGS
> 
> CPPFLAGS="-I$prefix/include"
> export CPPFLAGS
> 
> # build zlib
> if $build_zlib ; then
>     cd "$zlib"
>     echo "Building $zlib"
>     ./configure --prefix="$prefix"
>     make && make install || exit 1
>     cd ..
> fi
> 
> # build linpng
> if $build_png ; then
>     cd "$png"
>     echo "Building $png"
>     ./configure --prefix="$prefix" --disable-shared
>     make && make install || exit 1
>     cd ..
> fi
> 
> # build freetype
> if $build_freetype ; then
>     cd "$freetype"
>     echo "Building $freetype"
>     ./configure --prefix="$prefix" --disable-shared
>     make && make install || exit 1
>     cd ..
> fi
> 
> # build gd
> if $build_gd ; then
>     case "$os" in
>     MINGW32*) cp ../gd.h.win32 $gd/gd.h
>     esac
> 
>     cd "$gd"
>     echo "Building $gd"
>     ./configure --prefix="$prefix" --disable-shared \
>     --with-png="$prefix" --with-freetype="$prefix"
> 
>     make && make install || exit 1
>     cd ..
> fi
> 
> # build gnuplot
> cd ..
> echo "Building Gnuplot"
> ./configure --prefix="$prefix"  \
>             --with-png="$prefix" --with-gd="$prefix"
> 
> case "$os" in
>     MINGW32*) make -C src -f ../config/makefile.mgw2 || exit 1
> 
>     *)        make || exit 1
> esac
> 
> 
> 
> 
> # building gnuplot with Sun cc instead of gcc
> # env PATH="$prefix/bin:$PATH" CC=cc CXX=CC ./configure --prefix="$prefix" --with-png="$prefix"
> --with-gd="$prefix"
> 
> 
> 
> 
> 
> 
> -- 
> Be Yourself @ mail.com!
> Choose From 200+ Email Addresses
> Get a Free Account at www.mail.com
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: [transferred from Email] Providing/exporting a table of plot style properties

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

On Sunday 04 January 2009, you wrote:
> 
> On Sat, 3 Jan 2009, Ethan A Merritt wrote:
> 
> >> Of course it is possible to increase the number of slots in
> >>
> >> typedef struct coordinate {
> >>     enum coord_type type;       /* see above */
> >>     coordval x, y, z;
> >>     coordval ylow, yhigh;       /* ignored in 3d */
> >>     coordval xlow, xhigh;       /* also ignored in 3d */
> >> } coordinate;
> >>
> >> from 7 to some larger number.
> >
> > For instance, I would welcome a patch that added a field
> >     coordval color;
> > as already commented in the code.
> > The current handling of color information is a terrible hodgpodge,
> > with different plot style storing it in various different slots,
> > and the actual plot code then having to figure out where to pull
> > it from.
> 
> I am interested in working out a patch but don't have a good
> unterstanding of the code and so not a good idea yet of the
> magnitude of the task. Would most necessary changes take
> place in datafile.c and graphics.c or are other places affected
> as well?


INPUT SIDE
==========

The key routines on the input side are

1) plot2d.c: store2d_point()

store2d_point(
    struct curve_points *current_plot,
    int i,                      /* point number */
    double x, double y,
    double xlow, double xhigh,
    double ylow, double yhigh,
    double width)               /* BOXES widths: -1 -> autocalc, 0 ->  use xlow/xhigh */

It stores 7 data values for each data point.  Confusingly, other than x and y
these are often not used for what the name implies.  Thus "ylow" or "yhigh"
is often the variable color, and "width" is an ugly overloading of either
z or some magic flag depending on what the plot style is.  

My first thought is to increase the number of parameters and make them match
up more consistently with the actual field contents:
store2d_point( ...,
 x,y,xlow,xhigh,ylow,yhigh	/* as before, but this time we really mean it */
 z				/* the 7th existing slot, now named properly */
 color				/* the new slot */
 variable_prop1			/* somewhat problematic */
 variable_prop2			/* e.g. pointsize variable */
)

The first 7 parameters, if relevant to the current plot style, would be
stored directly in the corresponding slot in the coord structure.
Color would be either stored directly or calculated from other values and
stored in the new 8th slot.  

If we are willing to add a 9th or even a 10th slot, then additional variable
properties like point size or point type could be stored in a dedicated slot;
otherwise they could continue as they are now to be aliased on top of
xlow, xhigh, ylow and yhigh (which are used by only a few plot types).

9 slots would be enough, I think, for every plot style except maybe
xyerrorlines.



2) the macros in axis.h
    STORE_WITH_LOG_AND_UPDATE_RANGE()
    COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE()

These routines are called for each data line read, from a switch statement that
tries to figure out what kind of plot this is and therefore what data goes in which
of the seven slots.  That switch statement could benefit from a total re-work
based on your proposed table, but that change can be done separately from any
work to clean up what data is stored in which slot.

Every call site for these routines/macros would have to be modified in
accordance with whatever change you make.  That's a lot of places, so best to
do it only once.  That is,  let's think hard about what changes to make and
then modify all the callers in one go.

OUTPUT SIDE
===========

The routines that actual plot the data using the previously stored data 
are mostly in graphics.c 
  static void plot_lines __PROTO((struct curve_points * plot));
  static void plot_points __PROTO((struct curve_points * plot));
  static void plot_dots __PROTO((struct curve_points * plot));
  static void plot_bars __PROTO((struct curve_points * plot));
  static void plot_boxes __PROTO((struct curve_points * plot, int xaxis_y));
  ...etc..
and in graph3d.c
  static void plot3d_impulses __PROTO((struct surface_points * plot));
  static void plot3d_lines __PROTO((struct surface_points * plot));
  static void plot3d_points __PROTO((struct surface_points * plot, /* FIXME PM3D: */ int p_type));
  static void plot3d_vectors __PROTO((struct surface_points * plot));
  ...etc...
There are a few routines in other source files that refer to the data values
directly, but many of these may not be affected by changes in color handling.

Let's look at the simplest case:

static void
plot_dots(struct curve_points *plot)
{
    int i;
    int x, y;
    struct termentry *t = term;

    for (i = 0; i < plot->p_count; i++) {
        if (plot->points[i].type == INRANGE) {
            x = map_x(plot->points[i].x);
            y = map_y(plot->points[i].y);
            /* rgb variable  -  color read from data column */
            check_for_variable_color(plot, &plot->points[i]);
            /* point type -1 is a dot */
            (*t->point) (x, y, -1);
        }
    }
}

You can see that it pulls the x coordinate from point[i].x 
and the y coordinate from point[i].y.  No problem there.
Plots with error bars would pull their ranges from
point[i].ylow point[i].high, etc, also no problem.

But figuring out where to pull the color from is not so clean.
I tried to abstract the retrieval of color info by creating the helper
routine check_for_variable_color(), but it is not used everywhere.
It basically pulls and possibly applies the value stored in "yhigh".

NB: This is *not* what it says in the comment in gp_types.h
    which claims that color info is in ylow (aliased as CRD_COLOR)

The plot styles which really do have a yhigh value obviously cannot
use this abstraction.  Some of them instead use the CRD_COLOR alias,
others I don't even remember.

My thought is that all of these, the check_for_variable_color guys
and the CRD_COLOR guys and any remaining stragglers, should all be
changed to use the new field point[i].color, and the abstraction
routine should be extended as necessary to handle all plot styles.



-- 
Ethan A Merritt

Re: [transferred from Email] Providing/exporting a table of plot style properties

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

Ethan A Merritt wrote:

> [summary] The question is whether the code in get_data()
> plot2d.c lines 327ff   can be replaced by a table-lookup,
> or deleted altogether.   This code sets limits min_cols and max_cols
> for the number of columns specified in the "using" part of a plot
> command. 

That's not all that code does.  And a table would fail to represent 
those other things.

In short, I don't this hurts anywhere near bad enough to change it.

> Ralf's proposed table would also hold properties like
> PLOT_STYLE_HAS_FILL that are currently single bits set in the
> line style definitions in gp_types.h

I agree that that part would make sense.

> As you move into that kind of question, I start to think that
> the whole idea of a fixed set of properties for a given plot
> type breaks down.

Indeed.  The original design has been thoroughly swamped under by new 
features.  We're doing so much stuff outside (or in conflict with) the 
concept of plot styles that it's hard to see what it was originally 
meant to be: a complete description of how a given dataset would be 
displayed.

And not a lot of that is described too well in the documentation, either...

> It was this kind of argument that made me inclined to delete
> all the code tracking min_cols and max_cols.   Other than issuing
> an error message if the command fails to provide at least min_cols
> of using specs, they aren't much use for anything.

Well, given that that's exactly what they're being computed for, why 
should they do more?

> It may not even generate an error message if you exceed max_cols, as
> you have already pointed out with regard to filledcurves.

Now that would be bug.

>> What 
>> aboutthe has_grid_topology property in struct surface_points?
>> Is that not plot-style specific property?

No.  It's a feature of the data, not the plot style.  Which is why it's 
in the data structure holding the dataset: struct surface_points.

build script for Gnuplot under MinGW/Msys, Solaris, Linux

[m s. <mw...@us...>]

Hi all,

I have recently created a script to build Gnuuplot on Windows under the MinGW/Msys environment with PNG, Freetype and GD.  I have also used this for Solaris and Linux environments.  This is based on a CVS snapshot from about 9 months ago.


Here are the versions of the libraries I used (freetype-2.3.5, gd-2.0.33, libpng-1.2.18, zlib-1.2.3).  The build script assumes that these libraries are in .tar.gz files located in the top of the Gnuplot tree.  The script will build static libraries just for Gnuplot to use.  I often work on older Linux boxes that I can't change and don't have the newer versions of these libraries.

The one thing I had to to was modify the gd.h file to never build a DLL.  So I created a copy of gd.h named gd.h.win32 to prevent the DLL.

I put the script in the top level of the Gnuplot tree and run it from there.  I simply called it build.sh.

Hope it helps someone,

Mike Sutton

BTW some email readers might mess up the line wrap.


-----------------------
#!/bin/sh
# This is a Bourne shell script
#
# This script builds the required support libraries for using Gnuplot
# with GDLIB with TrueType font support.
#
# MODIFICATIONS:
# 05-Mar-2008    Initially generated... MWS
#----------------------------------------------------------------------

USAGE="`basename $0`: [-sZPFG]

where
-s - skip the unpacking step
-Z - skip building zlib
-P - skip building libpng
-F - skip building freetype
-G - skip building gd
"

# initialize variables
unpack=true
build_zlib=true
build_png=true
build_freetype=true
build_gd=true

# parse command line options

while getopts hsZPFG opt
do
   case $opt in
   s)           unpack=false;;
   Z)           build_zlib=false;;
   P)           build_png=false;;
   F)           build_freetype=false;;
   G)           build_gd=false;;
   h| ?)    echo "$USAGE"
        exit 1;;

   esac
done
shift `expr $OPTIND - 1`

freetype="freetype-2.3.5"
gd="gd-2.0.33"
png="libpng-1.2.18"
zlib="zlib-1.2.3"

unpack_list="$zlib $png $gd $freetype "

curdir=`pwd`

# location for support libraries
gnutmp="support_libs"
buildtmp="ztmp"

ZCAT=gzcat

os=`uname -s`
case "$os" in
    Linux) ZCAT=zcat;;
    MINGW32*) ZCAT="gunzip -c";;
esac


test -d "$gnutmp" || mkdir "$gnutmp"
test -d "$buildtmp" || mkdir "$buildtmp"

cd "$buildtmp"
$unpack && for name in $unpack_list ; do
    if [ ! -d "$name" ] ; then
    echo "unpacking $name"
    $ZCAT ../${name}.tar.gz | tar -xf - || exit 1
    fi
done


prefix="$curdir/$gnutmp"

PATH="$prefix/bin:$PATH"
export PATH

LDFLAGS="-L$prefix/lib"
export LDFLAGS

CPPFLAGS="-I$prefix/include"
export CPPFLAGS

# build zlib
if $build_zlib ; then
    cd "$zlib"
    echo "Building $zlib"
    ./configure --prefix="$prefix"
    make && make install || exit 1
    cd ..
fi

# build linpng
if $build_png ; then
    cd "$png"
    echo "Building $png"
    ./configure --prefix="$prefix" --disable-shared
    make && make install || exit 1
    cd ..
fi

# build freetype
if $build_freetype ; then
    cd "$freetype"
    echo "Building $freetype"
    ./configure --prefix="$prefix" --disable-shared
    make && make install || exit 1
    cd ..
fi

# build gd
if $build_gd ; then
    case "$os" in
    MINGW32*) cp ../gd.h.win32 $gd/gd.h
    esac

    cd "$gd"
    echo "Building $gd"
    ./configure --prefix="$prefix" --disable-shared \
    --with-png="$prefix" --with-freetype="$prefix"

    make && make install || exit 1
    cd ..
fi

# build gnuplot
cd ..
echo "Building Gnuplot"
./configure --prefix="$prefix"  \
            --with-png="$prefix" --with-gd="$prefix"

case "$os" in
    MINGW32*) make -C src -f ../config/makefile.mgw2 || exit 1

    *)        make || exit 1
esac




# building gnuplot with Sun cc instead of gcc
# env PATH="$prefix/bin:$PATH" CC=cc CXX=CC ./configure --prefix="$prefix" --with-png="$prefix" --with-gd="$prefix"






-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com