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

Re: building with AquaTerm

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

On Jul 22, 2011, at 3:37 AM, Mojca Miklavec wrote:
> On Fri, Jul 22, 2011 at 03:59, Lutz Maibaum wrote:
>>> This would help in the case of macports. It doesn't help with aquaterm
>>> 1.1.0 which doesn't install libaquaterm.dylib at all.
>> 
>> It doesn't install a dynamic library at all, not even within the framework directory structure?
> 
> Of course it installs it into the framework.

Couldn't you then just add the proper location within the framework hierarchy to the LDFLAGS (as a temporary workaround)?

>> I do not know how one could modify the configure process to check for the presence of the aquaterm framework. For libraries there is a standard way to do so (the AC_CHECK_LIB macro, used in m4/apple.m4), but it's not clear to me if there is something similar for frameworks.
> 
> It would probably be easier to use cmake, but just to answer you. I
> have no idea how autotools work. The configure script currently has

[ SNIP ]

> All you need to do is to replace every instance of -laquaterm with
> -framework AquaTerm and check if that flag works ok.

As far as I know this part of the configure script is auto-generated from m4/apple.m4, which reads:

AC_DEFUN([GP_APPLE],
[AC_MSG_CHECKING(for Apple MacOS X)
AC_EGREP_CPP(yes,
[#if defined(__APPLE__) && defined(__MACH__)
  yes
#endif
], 
   [ AC_MSG_RESULT(yes)
     AC_CHECK_LIB(aquaterm, aqtInit, 
     [ LIBS="-laquaterm $LIBS -framework Foundation"
       CFLAGS="$CFLAGS -ObjC"
       AC_DEFINE(HAVE_LIBAQUATERM,1,
                 [Define to 1 if you're using the aquaterm library on Mac OS X])
     ],[], -lobjc)
     is_apple=yes
   ],
   AC_MSG_RESULT(no)
   is_apple=no)
])

The test for the aquaterm dynamic library is performed by AC_CHECK_LIB, and I don't think there is a similar predefined macro to test for frameworks. You posted one possible solution; another one is suggested in this thread:

http://lists.apple.com/archives/Unix-porting/2009/Jan/msg00025.html

  -- Lutz

Re: building with AquaTerm

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

This is a copy-paste from some random example that I found online:

if test "x$enable_opengl" != "xno" ; then
  if test "x$host_os_darwin" = "xyes" ; then
    AC_MSG_CHECKING([for OpenGL framework])
    wz_ac_check_opengl_save_LIBS=$LIBS
    LIBS="-framework OpenGL $LIBS"
      AC_LINK_IFELSE([main() { }],
      [GL_h=mac ; GLU_h=mac ; GL_lib=yes ; GLU_lib=yes ;
GLLIB="-framework OpenGL" ; GLULIB="" ; AC_MSG_RESULT([yes])],
      [LIBS=$wz_ac_check_opengl_save_LIBS ; AC_MSG_RESULT([no])])
  fi

If that is of any help.

Mojca

http://www.gnu-darwin.org/www001/src/ports/games/warzone2100/work/warzone2100-2.0.9/configure.ac

Re: building with AquaTerm

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

On Fri, Jul 22, 2011 at 03:59, Lutz Maibaum wrote:
>
> Could you try this one-line change in configure.in, run the prepare script, and then try to configure?
>
> 1357c1357
> < if test "$is_apple" = yes; then
> ---
>> if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then
>
> This should take care of the incorrect configure summary.

This does take care of configure summary (but I didn't even try since
it doesn't help me to include aquaterm), but it doesn't even try to
use "-framework AquaTerm", so it will fail to include AquaTerm after
all anyway.

>> This would help in the case of macports. It doesn't help with aquaterm
>> 1.1.0 which doesn't install libaquaterm.dylib at all.
>
> It doesn't install a dynamic library at all, not even within the framework directory structure?

Of course it installs it into the framework.

> I do not know how one could modify the configure process to check for the presence of the aquaterm framework. For libraries there is a standard way to do so (the AC_CHECK_LIB macro, used in m4/apple.m4), but it's not clear to me if there is something similar for frameworks.

It would probably be easier to use cmake, but just to answer you. I
have no idea how autotools work. The configure script currently has

$as_echo "yes" >&6; }
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for aqtInit in
-laquaterm" >&5
$as_echo_n "checking for aqtInit in -laquaterm... " >&6; }
if ${ac_cv_lib_aquaterm_aqtInit+:} false; then :
  $as_echo_n "(cached) " >&6
else
  ac_check_lib_save_LIBS=$LIBS
LIBS="-laquaterm -lobjc $LIBS"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char aqtInit ();
int
main ()
{
return aqtInit ();
  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_link "$LINENO"; then :
  ac_cv_lib_aquaterm_aqtInit=yes
else
  ac_cv_lib_aquaterm_aqtInit=no
fi
rm -f core conftest.err conftest.$ac_objext \
    conftest$ac_exeext conftest.$ac_ext
LIBS=$ac_check_lib_save_LIBS
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ac_cv_lib_aquaterm_aqtInit" >&5
$as_echo "$ac_cv_lib_aquaterm_aqtInit" >&6; }
if test "x$ac_cv_lib_aquaterm_aqtInit" = xyes; then :
   LIBS="-laquaterm $LIBS -framework Foundation"
       CFLAGS="$CFLAGS -ObjC"

$as_echo "#define HAVE_LIBAQUATERM 1" >>confdefs.h

fi

All you need to do is to replace every instance of -laquaterm with
-framework AquaTerm and check if that flag works ok. I have no idea
how to do that in auto tools.

(Off-topic: is anyone providing Qt support/fixing Qt bugs? I reported
twice the reasons why I cannot use it, but I didn't get any response.)

Mojca

Re: building with AquaTerm

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

On Jul 7, 2011, at 2:19 AM, Mojca Miklavec wrote:
> On Thu, Jul 7, 2011 at 00:44, Lutz Maibaum wrote:
>> On Jul 6, 2011, at 2:20 PM, Mojca Miklavec wrote:
>>> I would like to revive this thread. Gnuplot needs a fix to account for
>>> the change in AquaTerm, that is, it needs to replace -laquaterm with
>>> -framework Aquaterm (possibly with those intermediate flags suggested
>>> by Allin C.).
>> 
>> I just tried building gnuplot 4.4.3 manually on a Mac that has aquaterm 1.0.1_5 installed through MacPorts. As you describe, the configure script fails to compile the little program that tests for a working aquaterm library:
> 
> There are two separate problems. One is that gnuplot doesn't find
> aquaterm in macport, but the second separate one is that gnuplot
> doesn't find aquaterm 1.1.0 (installed directly, not via macports) at
> all.
> 
> I was mostly talking about supporting 1.1.0. The issue with finding
> aquaterm in macports is a different (even though related) issue. Also,
> it is not very nice that configure script unconditionally reports that
> it is going to build aquaterm and then doesn't do it.

Could you try this one-line change in configure.in, run the prepare script, and then try to configure?

1357c1357
< if test "$is_apple" = yes; then
---
> if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then

This should take care of the incorrect configure summary.

>> I do not know why the configure script would pick up the MacPorts include directory, but not the library directory. I am actually not sure if it should, since those are non-standard (at least on the OSX platform), and therefore should be given explicitly to the configure command. Could you try
>> 
>>  CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>> 
>> and see if this helps? Configured this way, gnuplot then builds fine on my machine, and seems to work with the aquaterm terminal.
> 
> This would help in the case of macports. It doesn't help with aquaterm
> 1.1.0 which doesn't install libaquaterm.dylib at all.

It doesn't install a dynamic library at all, not even within the framework directory structure?

I do not know how one could modify the configure process to check for the presence of the aquaterm framework. For libraries there is a standard way to do so (the AC_CHECK_LIB macro, used in m4/apple.m4), but it's not clear to me if there is something similar for frameworks.

Hope this helps,

  Lutz

Re: cannot access the cvs repository

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

Hello

Thank you for your information.  I will wait until we will be able to access the cvs repository.

Regards

Tatsuro

--- On Tue, 2011/7/19, Ethan Merritt wrote:

> On Monday, July 18, 2011 02:42:26 pm Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have noticed that one cannot access the cvs repository.
> > What happens on the sourceforge.net ?
> 
> I filed a support request with SourceForge on Saturday.
> They acknowledged the problem with cvs access, but they have not
> yet said when it will be fixed.
> 
> SourceForge site status is here:
>     https://sourceforge.net/apps/wordpress/sourceforge/
> 
>         Ethan
>  
> > Regards
> > 
> > Tatsuro 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> University of Washington, Seattle 98195-7742
> 

Re: cannot access the cvs repository

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

On Monday, July 18, 2011 02:42:26 pm Tatsuro MATSUOKA wrote:
> Hello
> 
> I have noticed that one cannot access the cvs repository.
> What happens on the sourceforge.net ?

I filed a support request with SourceForge on Saturday.
They acknowledged the problem with cvs access, but they have not
yet said when it will be fixed.

SourceForge site status is here:
    https://sourceforge.net/apps/wordpress/sourceforge/

		Ethan
 
> Regards
> 
> Tatsuro 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: cannot access the cvs repository

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

Hello

Unofficial mirror of gnuplot's CVS repository (unmodified source) can be accessible.

https://github.com/gnuplot/gnuplot

Latest ChangeLog item
2011-07-14  Ethan A Merritt  <merritt@u.washington.edu>

Regards

Tatsuro
--- On Tue, 2011/7/19, Tatsuro MATSUOKA  wrote:

> Hello
> 
> I have noticed that one cannot access the cvs repository.
> What happens on the sourceforge.net ?
> 
> Regards
> 
> Tatsuro 
> 
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to 
> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

cannot access the cvs repository

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

Hello

I have noticed that one cannot access the cvs repository.
What happens on the sourceforge.net ?

Regards

Tatsuro 

Re: Is the latest ChangeLog Date '2011-06-17 ' correct on the cvs source.

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

Hello

--- On Thu, 2011/7/14, Juhász Péter wrote:

> On Thu, 2011-07-14 at 02:32 +0900, Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > The latest ChangeLog Date is '2011-06-17 ' for the cvs source.
> > 
> > 2011-06-17  Peter Juhasz  <ju...@us...>
> > <snip>
> > 
> > Just one before change is 
> > 2011-07-11  Ethan A Merritt  <merritt@u.washington.edu>
> > <snip>
> > 
> > ?????
> > 
> > Regards
> > 
> > Tatsuro 
> 
> Sorry, my mistake.
> I fixed it now.

Thanks! I have prepared new binaries of the cygwin, mingw and djgpp.
http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Regards

Tatsuro
Regards

Re: Is the latest ChangeLog Date '2011-06-17 ' correct on the cvs source.

[Juhász P. <pet...@gm...>]

On Thu, 2011-07-14 at 02:32 +0900, Tatsuro MATSUOKA wrote:
> Hello
> 
> The latest ChangeLog Date is '2011-06-17 ' for the cvs source.
> 
> 2011-06-17  Peter Juhasz  <ju...@us...>
> <snip>
> 
> Just one before change is 
> 2011-07-11  Ethan A Merritt  <merritt@u.washington.edu>
> <snip>
> 
> ?????
> 
> Regards
> 
> Tatsuro 

Sorry, my mistake.
I fixed it now.

Péter Juhász

Is the latest ChangeLog Date '2011-06-17 ' correct on the cvs source.

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

Hello

The latest ChangeLog Date is '2011-06-17 ' for the cvs source.

2011-06-17  Peter Juhasz  <ju...@us...>
<snip>

Just one before change is 
2011-07-11  Ethan A Merritt  <merritt@u.washington.edu>
<snip>

?????

Regards

Tatsuro 

one figure is out (plotstyles.gnu)

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

shige 07/12 2011
----------------

Making figure*.png files for windows help file, only one file
"figure_newhist.png" may be made out of "windows/" since the
followings:

----- From here -----
--- docs/plotstyles.gnu.ORG	2011-07-12 13:30:50.000000000 +0900
+++ docs/plotstyles.gnu	2011-07-12 13:33:04.000000000 +0900
@@ -189,7 +189,7 @@
 set title "Rowstacked" offset 0,-1
 plot demo . 'histopt.dat' using 1 fs solid 0.5, '' using 2 fs empty
 #
-set output 'figure_newhist' . ext
+set output out . 'figure_newhist' . ext
 set style histogram cluster
 set style data histogram
 unset title
----- To here -----

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

Re: building with AquaTerm

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

On Thu, Jul 7, 2011 at 00:44, Lutz Maibaum wrote:
> On Jul 6, 2011, at 2:20 PM, Mojca Miklavec wrote:
>> I would like to revive this thread. Gnuplot needs a fix to account for
>> the change in AquaTerm, that is, it needs to replace -laquaterm with
>> -framework Aquaterm (possibly with those intermediate flags suggested
>> by Allin C.).
>
> I just tried building gnuplot 4.4.3 manually on a Mac that has aquaterm 1.0.1_5 installed through MacPorts. As you describe, the configure script fails to compile the little program that tests for a working aquaterm library:

There are two separate problems. One is that gnuplot doesn't find
aquaterm in macport, but the second separate one is that gnuplot
doesn't find aquaterm 1.1.0 (installed directly, not via macports) at
all.

I was mostly talking about supporting 1.1.0. The issue with finding
aquaterm in macports is a different (even though related) issue. Also,
it is not very nice that configure script unconditionally reports that
it is going to build aquaterm and then doesn't do it.

> I do not know why the configure script would pick up the MacPorts include directory, but not the library directory. I am actually not sure if it should, since those are non-standard (at least on the OSX platform), and therefore should be given explicitly to the configure command. Could you try
>
>  CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>
> and see if this helps? Configured this way, gnuplot then builds fine on my machine, and seems to work with the aquaterm terminal.

This would help in the case of macports. It doesn't help with aquaterm
1.1.0 which doesn't install libaquaterm.dylib at all.

(This should be fixed before the next release.)

Mojca

Re: building with AquaTerm

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

On Jul 6, 2011, at 2:20 PM, Mojca Miklavec wrote:
> I would like to revive this thread. Gnuplot needs a fix to account for
> the change in AquaTerm, that is, it needs to replace -laquaterm with
> -framework Aquaterm (possibly with those intermediate flags suggested
> by Allin C.).

I just tried building gnuplot 4.4.3 manually on a Mac that has aquaterm 1.0.1_5 installed through MacPorts. As you describe, the configure script fails to compile the little program that tests for a working aquaterm library:

configure:6004: checking for aqtInit in -laquaterm
configure:6029: gcc -o conftest -g -O2   -I/opt/local/include  conftest.c -laquaterm -lobjc  >&5
ld: library not found for -laquaterm
collect2: ld returned 1 exit status

Note that the configure script knew that it should look for header files in /opt/local/include. However, it did not add /opt/local/lib to the library path, which I believe would be sufficient to build gnuplot using the MacPorts aquaterm.

I am not sure why the configure script added /opt/local/include to the header path. It could be because prior to testing for aquaterm, it found my MacPorts installation of X:

configure:5097: checking for X
configure:5286: result: libraries /opt/local/lib, headers /opt/local/include

I do not know why the configure script would pick up the MacPorts include directory, but not the library directory. I am actually not sure if it should, since those are non-standard (at least on the OSX platform), and therefore should be given explicitly to the configure command. Could you try

  CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure

and see if this helps? Configured this way, gnuplot then builds fine on my machine, and seems to work with the aquaterm terminal.

Finally, it seems that the line

    aqua terminal (MacOS X): yes

in the configure summary is printed whenever the variable is_apple is set to yes. From the configure script:

    if test "x$ac_cv_lib_aquaterm_aqtInit" = x""yes; then :
        LIBS="-laquaterm $LIBS -framework Foundation"
        CFLAGS="$CFLAGS -ObjC"
        $as_echo "#define HAVE_LIBAQUATERM 1" >>confdefs.h
    fi
    is_apple=yes

Perhaps the last line should be inside the if clause?

Disclaimer: I know very little about autoconf, and even less about the intricacies of the Apple build system, so take all of this with a grain of salt.

Hope this helps,

  Lutz

> On Wed, Mar 9, 2011 at 16:12, Mojca Miklavec
> <moj...@gm...> wrote:
>> Dear list,
>> 
>> I'm helping Per Persson test a new version of AquaTerm. I'm using Snow
>> Leopard with 64-bit architecture. The old AquaTerm only ships 32-bit
>> intel and ppc architectures, however a new version will come with
>> support for x86_64 (the latest version in CVS/git supports it
>> already).
>> 
>> However there is still quite a list of issues, many of them with the
>> common denominator being: as long as one has MacPorts (with gnuplot or
>> aquaterm package) installed, the only way to get a working version of
>> self-compiled gnuplot with aquaterm terminal is to:
>> - have both manually installed AquaTerm and the one installed with MacPorts
>> - both versions need to match exactly
>> 
>> What happens?
>> --------------------
>> If I don't install AquaTerm manually, the version provided by MacPorts
>> doesn't suffice to compile gnuplot with aquaterm terminal which is
>> probably a flaw in gnuplot configuration. Priority number one would be
>> to fix that one.
>> 
>> However if I do install a different version of AquaTerm, gnuplot links to
>>    /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> which belongs to MacPorts, but it opens /Applications/AquaTerm.app
>> which links to
>>    /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> and then nothing happens at all. Nothing gets drawn.
>> 
>> I have a number of other requests, I will try to do my best to fix
>> AquaTerm (I still lack knowledge), but one thing should be high on
>> priority list: ability to build gnuplot with aquaterm terminal without
>> having to manually install AquaTerm.app.
>> 
>> What has to be done?
>> --------------------
>> AquaTerm installs four things: application, framework, symbolic links:
>> - /Applications/AquaTerm.app
>> - /Library/Frameworks/AquaTerm.framework
>> - symlinks
>>  /usr/local/include/aquaterm/AQTAdapter.h
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>>  /usr/local/include/aquaterm/aquaterm.h
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>>  /usr/local/lib/libaquaterm.dylib
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /usr/local/lib/libaquaterm.1.1.0.dylib
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> 
>> Under MacPorts that is:
>> - /Applications/MacPorts/AquaTerm.app
>> - /opt/local/Library/Frameworks/AquaTerm.framework
>> - symlinks
>>  /opt/local/include/aquaterm/AQTAdapter.h
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>>  /opt/local/include/aquaterm/aquaterm.h
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>>  /opt/local/lib/libaquaterm.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /opt/local/lib/libaquaterm.1.0.1.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.1.0.1.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> 
>> When I run ./configure without having my own version of AquaTerm
>> (installed manually), I get
>>    aqua terminal (MacOS X): yes
>> but that is a lie. config.log says:
>> 
>>    configure:6792: checking for aqtInit in -laquaterm
>>    configure:6817: gcc -o conftest -g -O2   conftest.c -laquaterm -lobjc  >&5
>>    ld: library not found for -laquaterm
>>    ...
>>    configure:14123: result:   aqua terminal (MacOS X): yes
>>    ...
>>    ac_cv_lib_aquaterm_aqtInit=no
>> 
>> I think that the catch is having "-I/opt/local/include" present when
>> trying to compile some test file. The question is: how should the
>> configuration script know about that? After all one could have fink or
>> homebrew or whatever other package manager installed and include path
>> could be anyone.
>> 
>> All the other libraries (pango, cairo, pdflib, gd, freetype, ...) are
>> easily found from MacPorts. Here is what config.log has to say about
>> pdf or gd for example:
>> 
>>    configure:9085: found /opt/local/bin/pdflib-config
>>    configure:9097: result: /opt/local/bin/pdflib-config
>>    configure:9120: checking for PDF_get_majorversion in -lpdf
>>    configure:9145: gcc -o conftest -g -O2  -I/opt/local/include
>> -I/opt/local/include  -L/opt/local/lib -L/opt/local/lib
>> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib conftest.c -lpdf
>>> &5
>>    configure:9145: $? = 0
>> 
>>    configure:8659: checking for gdlib-config
>>    configure:8677: found /opt/local/bin/gdlib-config
>>    configure:8689: result: /opt/local/bin/gdlib-config
>>    configure:8711: checking for gdImageCreateTrueColor in -lgd
>>    configure:8736: gcc -o conftest -g -O2  -I/opt/local/include
>> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
>> conftest.c -lgd   >&5
>>    configure:8736: $? = 0
>>    configure:8745: result: yes
>>    configure:8753: checking gd.h usability
>>    configure:8753: gcc -c -g -O2  -I/opt/local/include conftest.c >&5
>>    configure:8753: $? = 0
>>    configure:8753: result: yes
>>    configure:8753: checking gd.h presence
>>    configure:8753: gcc -E  -I/opt/local/include conftest.c
>>    configure:8753: $? = 0
>>    configure:8753: result: yes
>>    configure:8753: checking for gd.h
>>    configure:8753: result: yes
>> 
>> What do you suggest to do about AquaTerm (provided that we have
>> freedom to change AquaTerm in the way that is needed to make gnuplot
>> configuration work properly)? Can gnuplot configuration be fixed
>> properly, so that gnuplot will find AquaTerm that is shipped with
>> MacPorts? My next question would be how to set which aquaterm to use
>> (in case there are multiple versions installed), but that's for later.
>> 
>> Mojca
>> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: building with AquaTerm

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

Dear list,

I would like to revive this thread. Gnuplot needs a fix to account for
the change in AquaTerm, that is, it needs to replace -laquaterm with
-framework Aquaterm (possibly with those intermediate flags suggested
by Allin C.).

Mojca


On Wed, Mar 9, 2011 at 16:12, Mojca Miklavec
<moj...@gm...> wrote:
> Dear list,
>
> I'm helping Per Persson test a new version of AquaTerm. I'm using Snow
> Leopard with 64-bit architecture. The old AquaTerm only ships 32-bit
> intel and ppc architectures, however a new version will come with
> support for x86_64 (the latest version in CVS/git supports it
> already).
>
> However there is still quite a list of issues, many of them with the
> common denominator being: as long as one has MacPorts (with gnuplot or
> aquaterm package) installed, the only way to get a working version of
> self-compiled gnuplot with aquaterm terminal is to:
> - have both manually installed AquaTerm and the one installed with MacPorts
> - both versions need to match exactly
>
> What happens?
> --------------------
> If I don't install AquaTerm manually, the version provided by MacPorts
> doesn't suffice to compile gnuplot with aquaterm terminal which is
> probably a flaw in gnuplot configuration. Priority number one would be
> to fix that one.
>
> However if I do install a different version of AquaTerm, gnuplot links to
>    /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
> which belongs to MacPorts, but it opens /Applications/AquaTerm.app
> which links to
>    /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
> and then nothing happens at all. Nothing gets drawn.
>
> I have a number of other requests, I will try to do my best to fix
> AquaTerm (I still lack knowledge), but one thing should be high on
> priority list: ability to build gnuplot with aquaterm terminal without
> having to manually install AquaTerm.app.
>
> What has to be done?
> --------------------
> AquaTerm installs four things: application, framework, symbolic links:
> - /Applications/AquaTerm.app
> - /Library/Frameworks/AquaTerm.framework
> - symlinks
>  /usr/local/include/aquaterm/AQTAdapter.h
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>  /usr/local/include/aquaterm/aquaterm.h
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>  /usr/local/lib/libaquaterm.dylib
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /usr/local/lib/libaquaterm.1.1.0.dylib
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>
> Under MacPorts that is:
> - /Applications/MacPorts/AquaTerm.app
> - /opt/local/Library/Frameworks/AquaTerm.framework
> - symlinks
>  /opt/local/include/aquaterm/AQTAdapter.h
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>  /opt/local/include/aquaterm/aquaterm.h
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>  /opt/local/lib/libaquaterm.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /opt/local/lib/libaquaterm.1.0.1.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.1.0.1.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>
> When I run ./configure without having my own version of AquaTerm
> (installed manually), I get
>    aqua terminal (MacOS X): yes
> but that is a lie. config.log says:
>
>    configure:6792: checking for aqtInit in -laquaterm
>    configure:6817: gcc -o conftest -g -O2   conftest.c -laquaterm -lobjc  >&5
>    ld: library not found for -laquaterm
>    ...
>    configure:14123: result:   aqua terminal (MacOS X): yes
>    ...
>    ac_cv_lib_aquaterm_aqtInit=no
>
> I think that the catch is having "-I/opt/local/include" present when
> trying to compile some test file. The question is: how should the
> configuration script know about that? After all one could have fink or
> homebrew or whatever other package manager installed and include path
> could be anyone.
>
> All the other libraries (pango, cairo, pdflib, gd, freetype, ...) are
> easily found from MacPorts. Here is what config.log has to say about
> pdf or gd for example:
>
>    configure:9085: found /opt/local/bin/pdflib-config
>    configure:9097: result: /opt/local/bin/pdflib-config
>    configure:9120: checking for PDF_get_majorversion in -lpdf
>    configure:9145: gcc -o conftest -g -O2  -I/opt/local/include
> -I/opt/local/include  -L/opt/local/lib -L/opt/local/lib
> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib conftest.c -lpdf
>>&5
>    configure:9145: $? = 0
>
>    configure:8659: checking for gdlib-config
>    configure:8677: found /opt/local/bin/gdlib-config
>    configure:8689: result: /opt/local/bin/gdlib-config
>    configure:8711: checking for gdImageCreateTrueColor in -lgd
>    configure:8736: gcc -o conftest -g -O2  -I/opt/local/include
> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
> conftest.c -lgd   >&5
>    configure:8736: $? = 0
>    configure:8745: result: yes
>    configure:8753: checking gd.h usability
>    configure:8753: gcc -c -g -O2  -I/opt/local/include conftest.c >&5
>    configure:8753: $? = 0
>    configure:8753: result: yes
>    configure:8753: checking gd.h presence
>    configure:8753: gcc -E  -I/opt/local/include conftest.c
>    configure:8753: $? = 0
>    configure:8753: result: yes
>    configure:8753: checking for gd.h
>    configure:8753: result: yes
>
> What do you suggest to do about AquaTerm (provided that we have
> freedom to change AquaTerm in the way that is needed to make gnuplot
> configuration work properly)? Can gnuplot configuration be fixed
> properly, so that gnuplot will find AquaTerm that is shipped with
> MacPorts? My next question would be how to set which aquaterm to use
> (in case there are multiple versions installed), but that's for later.
>
> Mojca
>

Re: Problem with autoscale, data and function

[Jan S. <jan...@gm...>]

> Using two separate plot commands (first plot, then replot) will generate two separate figures in the output file. On my system (gnuplot 4.4.3 on OS X) the above command generates a pdf file with two pages: the first contains a plot with only the data points, the second has both the data and the function. What happens if you plot the data and the line using just a single plot command?
> 
As i pointed out in my first post gnuplot then don't draw f(x) to the
boundary. See http://www.plotshare.com/index.ws/plot/239541263 for an
example.

Jan

Re: Problem with autoscale, data and function

[Jan S. <jan...@gm...>]

> The line is drawn to cover the range of the data.
> The plot boundary is drawn (by default) at the next tick mark.
> If you want these two things to be the same, then say
>    set autoscale fix
> or more specifically
>    set autoscale xfixmax

With autoscale fix my last datapoint is drawn on the boundary, that's
not my intention. I would like to have it like in the second example and
i didn't expected that using autoscale (or xrange [0:*] like in my case)
prevents that f(x) is drawn to the boundary. 

> The command sequence above will produce 2 pages of output.
> The first page will have the data; the second page will have both
> the data and the function.  I've checked here that it works as
> expected.  Do you really want a separate "replot" command?

Actually the replot thing is just a workaround for the upper
problem/feature. As i want to include the graph in a latex-document
using the packages egplot or gnuplottex the problem is that only the
first page of the pdf is shown.

Jan

Re: Problem with autoscale, data and function

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

On Tuesday, June 21, 2011 05:15:40 pm Jan Simon wrote:
> > The plot range is by default extended to the next axis tick mark,
> > in your case at x=70.
> > 
> > If you don't want it to do that, you can say
> > 	set autoscale fix
> 
> My concern is the red line (f(x)), not the green dots (data), they are
> fine.

The line is drawn to cover the range of the data.
The plot boundary is drawn (by default) at the next tick mark.
If you want these two things to be the same, then say
   set autoscale fix
or more specifically
   set autoscale xfixmax

> > That doesn't ring any bells.  
> > Can't you just output pdf to begin with?   (set term pdf)
> 
> Using set term pdf, plot data and replot f(x) gives me an output only
> with data, f(x) is missing.

The command sequence above will produce 2 pages of output.
The first page will have the data; the second page will have both
the data and the function.  I've checked here that it works as
expected.  Do you really want a separate "replot" command?

	Ethan

Re: Problem with autoscale, data and function

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

On Jun 21, 2011, at 5:15 PM, Jan Simon wrote:
> Using set term pdf, plot data and replot f(x) gives me an output only
> with data, f(x) is missing.


Using two separate plot commands (first plot, then replot) will generate two separate figures in the output file. On my system (gnuplot 4.4.3 on OS X) the above command generates a pdf file with two pages: the first contains a plot with only the data points, the second has both the data and the function. What happens if you plot the data and the line using just a single plot command?

  Lutz

Re: Problem with autoscale, data and function

[Jan S. <jan...@gm...>]

> The plot range is by default extended to the next axis tick mark,
> in your case at x=70.
> 
> If you don't want it to do that, you can say
> 	set autoscale fix

My concern is the red line (f(x)), not the green dots (data), they are
fine.

> That doesn't ring any bells.  
> Can't you just output pdf to begin with?   (set term pdf)

Using set term pdf, plot data and replot f(x) gives me an output only
with data, f(x) is missing.

Jan

Re: Problem with autoscale, data and function

[Ethan A M. <sf...@us...>]

On Tuesday, June 21, 2011 03:57:04 pm Jan Simon wrote:
> Hi,
> 
> today i've got stuck with a problem in gnuplot 4.4.2. On freenode i was
> suggested to post it here as it seem to be a bug. Here is my problem,
> some data and a function: 
> 
> http://www.plotshare.com/index.ws/plot/239541263
> 
> In the first example using autoscale the function ends on the sheet
> without reaching the boarder, when using x/yrange, it shows the right
> behaviour.

The plot range is by default extended to the next axis tick mark,
in your case at x=70.

If you don't want it to do that, you can say
	set autoscale fix

> As i want to use autoscale (with set xrange [0:*]) and as output eps, i
> tried to find a workaround. Using replot f(x) works but i ran in another
> problem, as epstopdf don't convert the resulting eps right, the pdf is
> missing the function (this might be a epstopdf problem).

That doesn't ring any bells.  
Can't you just output pdf to begin with?   (set term pdf)

	Ethan

Problem with autoscale, data and function

[Jan S. <jan...@gm...>]

Hi,

today i've got stuck with a problem in gnuplot 4.4.2. On freenode i was
suggested to post it here as it seem to be a bug. Here is my problem,
some data and a function: 

http://www.plotshare.com/index.ws/plot/239541263

In the first example using autoscale the function ends on the sheet
without reaching the boarder, when using x/yrange, it shows the right
behaviour.
As i want to use autoscale (with set xrange [0:*]) and as output eps, i
tried to find a workaround. Using replot f(x) works but i ran in another
problem, as epstopdf don't convert the resulting eps right, the pdf is
missing the function (this might be a epstopdf problem).

Thank you,

Jan 

I have updated cvs binaries for cygwin, mingw, and djgpp.

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

Hello

I have updated cvs binaries for cygwin, mingw, and djgpp.

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Regards
Tatsuro

Re: Integration in gnuplot IS possible!

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

On 06/16/2011 03:59 PM, Ethan A Merritt wrote:
> On Thursday, June 16, 2011 01:06:23 pm Daniel J Sebald wrote:
>> The bivariat.dem formula still has the problem of
>> recursion/stack depth, in this case:
>>
>>     recursion depth limit exceeded
>
> The depth limit was set rather arbitrary at 250 on the logic that
> "nobody would need more than that, right?"
>
> It would be easy enough to make it user-defined.
> If you increase it to something much larger and the program
> runs out of stack space, then at least you know it's your own
> fault.

I suppose that is a solution.  Or could remove the limit and see how 
gnuplot behaves when memory is used up.  That solution doesn't address 
the inefficient method of integration, but seeing as the feature 
probably isn't used often the solution might work well enough.

Dan

confirmation directory structure for current cvs winodows makefile

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

Hello

I have tried to build mingw binary using config/mingw/Makefile instead of config/makefile.mgw.

Using this makefile, gnuplot executables are installed into 'bin' directory.

On Dec 03, 2009, Petr pointed out.
http://old.nabble.com/Re%3A-directry-name-problem--bin-is-not-correctry-recognized-on-windows-in-some-cases-p26619776.html

Use 'bin' directory  for storing gnuplot executables make related files should be saved in unixy way.

Is the change of Makefile  intentional?

Regards

Tatsuro