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

FYI: 64 bit windows 7 sp1

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

Hello

Since I have changed my computer at University to windows Home Premium 64 bit, 
pm3d.dem fails due to temporary file error.

Today I have update my windows 7 to the sp1.

Temporary file error disappeared and all.dem can be executed normally.

Regards

Tatsuro

FYI: 64 bit windows 7 sp1

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

Hello

Since I have changed my computer at University to windows Home Premium 64 bit, 
pm3d.dem fails due to temporary file error.

Today I have update my windows 7 to the sp1.

Temporary file error disappeared and all.dem can be executed normally.

Regards

Tatsuro

Re: building with AquaTerm

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

On Thu, 10 Mar 2011, Mojca Miklavec wrote:

> Just to clarify: the author (Per Persson) wants to remove the library
> libaquaterm.dylib, so gnuplot will have to use -framework AquaTerm (as
> opposed to -laquaterm) from now on. This makes quite some points from
> discussion obsolete since the location of Framework is determined with
> switch -F, not -L any more which makes the location of AquaTerm better
> configurable.
>
> New release is planned before end of March, so it would be great if
> this gets fixed in gnuplot's cvs as soon as possible. (One has to
> replace all occurences of "-laquaterm" with "-framework AquaTerm".)

Or rather, with

  "-Wl,-framework -Wl,AquaTerm"

You're not going to endear yourself to gnuplot developers by
describing this change as a "fix" (= remedy for something broken),
when in fact it's a backward-incompatible change to gnuplot
configuration dictated by a (prospective) change to the setup of a
third-party library.

Allin Cottrell

Prescaling fit parameters

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

Hello,

I am hoping to drum up a little support to get a small patch accepted.

My issue is with the scaling of fit parameters in gnuplot's 'fit' command.

Fit is pretty robust, but if you have a function like:

f(x) = a * exp(-b*x*x) + c

where the values of the parameters differ by many orders of magnitude (eg a,c = 
1e7 and b = 1e-7) the fit command will fail badly.  One solution is to redefine 
the function so the parameters are of similar size, but it's easy to have 
gnuplot do this internally based on the initial values of the parameters.

I've written a tiny patch to do this:
http://sourceforge.net/tracker/?func=detail&aid=3106206&group_id=2055&atid=302055

I've tested this against test cases such as the one above, and also all of the 
fits in fit.dem.

The patch actually makes most of the fits converge in fewer iterations, and for 
fits where the parameters are very different in size, it now converges where it 
didn't at all before.

The patch is very non-invasive.  It adds 13 lines and modifies 7 others, all in 
fit.c

We use gnuplot in undergraduate teaching labs a lot, and this solves one of the 
most common problems we see with students using it for fitting.

Carl

Re: text window in gnuplot

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

Hello

Windows native binary is prepared using internal readline.
GNU readline can be used but I do not used it because of the possibility of
license violation.

BSD editline is too unixy so that it cannot be used at present.

BSD editline is used for cygwin version gnuplot 
because the cygwin supports BSD editline.

Utf-8 supports from keyboard is perhaps possible but is not easy work.
Practical way at this moment, you prepare gnuplot scripts encoded utf-8 
without BOM using a suitable text editor use them by 
load command or batch execution.  
 
A lot of free text editors that can treat the utf-8 encoding can be available on windows.
SciTE and Notepad++ are examples of them.

I have prepared SciTE customization.  With it, gnuplot script can executed very easily.

http://www.tatsuromatsuoka.com/gnuplot/Eng/SciTE/SciTEgnuplot.html 

Regards

Tatsuro
--- Ethan A Merritt wrote:

> On Wednesday, March 09, 2011 11:31:53 pm Bastian M将」rkisch wrote:
> > 
> > >I see that you have done a major rewrite of text buffer in gnuplot for
> > >Windows (I didn't test anything though). Does any of your fixes
> > >include fixing UTF-8 by any chance?
> > 
> > No, I don't see why my changes would affect unicode support. I think 
> > wgnuplot.exe uses the default encoding of your system (aka codepage).
> > 
> > Unicode support for wgnuplot would be feasible, but I won't make it my
> > top priority at the moment.
> 
> I point out once more that so far as I can see from either looking
> at the code or from running the binaries compiled by Tatsuro Matsuoka,
> UTF-8 works fine for output.   What does not work is the keyboard input
> stage.  I suspect, but cannot say for certain, that this is because the
> binaries were prepared by linking to libedit.   Perhaps one of you
> could prepare a test build using gnuplot's internal readline?
> My prediction is that such a binary would handle UTF-8 on input also.
> 
> Now it may still be a practical difficulty on a real Windows system
> how to set your keyboard to produce UTF-8 directly as you type.
> I can't help with that part, but it seems outside the scope of gnuplot.  
> I assume that people who are concerned to configure gnuplot so that it
> accepts UTF-8 keyboard input already know how to produce the UTF-8
> characters stream that they want it to accept.
> 
> 	Ethan
> 

Re: text window in gnuplot

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

Hello

Windows native binary is prepared using internal readline.
GNU readline can be used but I do not used it because of the possibility of
license violation.

BSD editline is too unixy so that it cannot be used at present.

BSD editline is used for cygwin version gnuplot 
because the cygwin supports BSD editline.

Utf-8 supports from keyboard is perhaps possible but is not easy work.
Practical way at this moment, you prepare gnuplot scripts encoded utf-8 
without BOM using a suitable text editor use them by 
load command or batch execution.  
 
A lot of free text editors that can treat the utf-8 encoding can be available on windows.
SciTE and Notepad++ are examples of them.

I have prepared SciTE customization.  With it, gnuplot script can executed very easily.

http://www.tatsuromatsuoka.com/gnuplot/Eng/SciTE/SciTEgnuplot.html 

Regards

Tatsuro
--- Ethan A Merritt wrote:

> On Wednesday, March 09, 2011 11:31:53 pm Bastian M将」rkisch wrote:
> > 
> > >I see that you have done a major rewrite of text buffer in gnuplot for
> > >Windows (I didn't test anything though). Does any of your fixes
> > >include fixing UTF-8 by any chance?
> > 
> > No, I don't see why my changes would affect unicode support. I think 
> > wgnuplot.exe uses the default encoding of your system (aka codepage).
> > 
> > Unicode support for wgnuplot would be feasible, but I won't make it my
> > top priority at the moment.
> 
> I point out once more that so far as I can see from either looking
> at the code or from running the binaries compiled by Tatsuro Matsuoka,
> UTF-8 works fine for output.   What does not work is the keyboard input
> stage.  I suspect, but cannot say for certain, that this is because the
> binaries were prepared by linking to libedit.   Perhaps one of you
> could prepare a test build using gnuplot's internal readline?
> My prediction is that such a binary would handle UTF-8 on input also.
> 
> Now it may still be a practical difficulty on a real Windows system
> how to set your keyboard to produce UTF-8 directly as you type.
> I can't help with that part, but it seems outside the scope of gnuplot.  
> I assume that people who are concerned to configure gnuplot so that it
> accepts UTF-8 keyboard input already know how to produce the UTF-8
> characters stream that they want it to accept.
> 
> 	Ethan
> 

Re: building with AquaTerm

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

Hello,

Just to clarify: the author (Per Persson) wants to remove the library
libaquaterm.dylib, so gnuplot will have to use -framework AquaTerm (as
opposed to -laquaterm) from now on. This makes quite some points from
discussion obsolete since the location of Framework is determined with
switch -F, not -L any more which makes the location of AquaTerm better
configurable.

New release is planned before end of March, so it would be great if
this gets fixed in gnuplot's cvs as soon as possible. (One has to
replace all occurences of "-laquaterm" with "-framework AquaTerm".)

(No need to comment on the rest.)

2011/3/10 Hans-Bernhard Bröker wrote:
> On 10.03.2011 00:41, Mojca Miklavec wrote:
>> 2011/3/10 Hans-Bernhard Bröker wrote:
>>> On 09.03.2011 22:48, Mojca Miklavec wrote:
>>>> 2011/3/9 Hans-Bernhard Bröker wrote:
>
>>>> Here is where all the fun begins. I *have to* install AquaTerm to
>>>> /usr/local/...,
>
>>> Says who?  Why?
>
>> If I want to choose the option "a)" (make sure libraries are only in
>> places where the compiler already looks by default).
>
> But it seems we've already established that /usr/local is not in your
> compiler's default search paths, either, haven't we?

/usr/local/lib is. /opt/local/lib isn't.

>> I forgot to say: I want my gnuplot to live *outside* of MacPorts.
>
> Then you can _not_ use anything from MacPorts.  None of the libraries,
> none of the headers, possibly not even the compiler.

I was not sure what inside/outside meant. Well - yes, I want to use
MacPorts' libraries, but the binary will be at some other location.

>> - when I have aquaterm under both /usr and /opt, it uses the version from /opt
>
> That could mean your include and library search paths are the wrong way
> round.

Actually the test for AquaTerm is performed without any flags first,
but pdflib & other libraries append -L/opt/local/lib to
compiler/linker options, so that AquaTerm will come from
/opt/local/lib at the end as well. Anyway, with -framework there is
some more freedom.

>> - when I have aquaterm only under /opt, it doesn't compile aquaterm
>> support at all (even though it could easily use the version from /opt)
>
> Then you have to dig deeper to find out why it doesn't accept that version.

I know why it doesn't. Because it doesn't know about existance of /opt
during configuration step (unless I provide an explicit CFLAGS
switch). But other libraries add -L/opt/local/lib, so once gnuplot is
aware of aquaterm existence, it will take the one from /opt.

(But again - since the default flag has to change, this means a
different set of algorithm to find the right version of AquaTerm.)

Mojca

Re: building with AquaTerm

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

On 10.03.2011 00:41, Mojca Miklavec wrote:
> 2011/3/10 Hans-Bernhard Bröker wrote:
>> On 09.03.2011 22:48, Mojca Miklavec wrote:
>>> 2011/3/9 Hans-Bernhard Bröker wrote:

>>> Here is where all the fun begins. I *have to* install AquaTerm to
>>> /usr/local/...,

>> Says who?  Why?

> If I want to choose the option "a)" (make sure libraries are only in
> places where the compiler already looks by default).

But it seems we've already established that /usr/local is not in your 
compiler's default search paths, either, haven't we?

> I forgot to say: I want my gnuplot to live *outside* of MacPorts.

Then you can _not_ use anything from MacPorts.  None of the libraries, 
none of the headers, possibly not even the compiler.

> However I find it perfectly fine if that personal copy of gnuplot uses
> libraries like pdflib, cairo etc. from MacPorts.

Now you're contradicting yourself.

Just because a program sits in your $HOME/bin doesn't mean it's outside 
of MacPorts.  MacPorts isn't just a directory --- it's a system of 
libraries, environment settings and configuration items that all work 
together.  Any executable built using the libraries from the MacPorts 
system is, for better or for worse, a MacPorts binary.  Even if it sits 
outside MacPorts' directories.

> So how can I for example:
> - Tell gnuplot's configure script to use the version of aquaterm from
> /usr and not the one from /opt (when I have macports in path)?

By making sure /opt appears before /usr on all your header and library 
searches (this is where an explicit -I/-L flag passed to ./configure 
might behave different from a change to environment variables: 
explicitly given directories are searched before default places), and by 
making sure you don't pull in the MacPorts version through some indirect 
connection, e.g. another library taken from MacPorts, which includes 
references to their aquaterm library.

> I know that configure can't read my mind, but:
> - when I have aquaterm under both /usr and /opt, it uses the version from /opt

That could mean your include and library search paths are the wrong way 
round.

> - when I have aquaterm only under /opt, it doesn't compile aquaterm
> support at all (even though it could easily use the version from /opt)

Then you have to dig deeper to find out why it doesn't accept that version.

4.4.3 release announcement

[Jacques Le B. <Jac...@ob...>]

Bonjour,

I installed release 4.4.3 on a Mac (using MacPort). It runs smoothly. I am particularly happy with new 'value("var")' feature. Thank you!

However, I upgraded by chance. There is no announcement on the gnuplot web page at:

http://www.gnuplot.info/

This web page is used by many people. Maybe you could add a line there.

Thank you.

Jacques

Re: building with AquaTerm

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

2011/3/10 Ethan A Merritt <sf...@us...>:
> Anyhow, we're past this issue now, right?

Not really. I would like to have aquaterm.pc or aquaterm-config or
something similar (anything that is easy enough to implement) that
would discover and include aquaterm automatically.



The rest of text was just trying to answer the "who needs that" and
"why did you install macports" part that I would prefer not to touch.

My main question is whether any of the gnuplot developers would be
willing to fix the configure script to allow building gnuplot with
MacPorts-only version of AquaTerm if aquaterm gets fixed (and what
would be the best way to fix aquaterm).

Mojca

Re: building with AquaTerm

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

On Wednesday, March 09, 2011 03:41:47 pm Mojca Miklavec wrote:

> So how can I for example:
> - Tell gnuplot's configure script to use the version of aquaterm from
> /usr and not the one from /opt (when I have macports in path)?

If the one in MacPorts doesn't work, why not just replace it altogether?
Anyhow, we're past this issue now, right?  You need to set the environmental
variables appropriately before running configure.

> - Use UTF-8 input on Mac asssuming that I entirely remove MacPorts
> from my system? (utf8.dem works fine, but no non-ascii characters are
> accepted on input and I cannot use left alt as "alt-gr"; I just
> realized that now.)

Aha.  If you had explained that to start with it would have saved time.

What you describe is a symptom of linking to the fake readline supplied
as part of OSX.  It is really a wrapper for the BSD libedit library,
which cannot handle UTF-8 input.   To fix this you need to install and
link to a copy of the real gnu libreadline.   Or if you like, you could
use gnuplot's built-in readline.  That is less capable in some other areas,
but it has no trouble handling UTF-8.

This is explained in the current release and installation notes for
gnuplot.

 
> > If you don't want to use your MacPorts, why did you install them
> > in the first place?
> 
> Let's say that I want to build a standalone Gnuplot.app that any user
> could copy from my homepage and it would then work out of the box.

I don't think that is possible, or at least if it is possible than I don't 
know how to do it.  It would have to be statically linked, and even then
I don't think that would solve your aquaterm issues.


> I
> need MacPorts most of the time, but if I leave MacPorts in PATH when I
> compile gnuplot, other users won't be able to use the binary that I
> compile due to dependencies on libraries provided by MacPorts. Please
> don't tell me that I need to buy a new machine without MacPorts just
> for the sake of compiling gnuplot that will be usable on other
> machines?

The shared libraries present when you run a program must be the same
(or at least API compatible with) with libraries used to link the program.
That requirement is true for gnuplot, or aquaterm, or MacPorts, just as
it is for all other programs and shared libraries.

Re: building with AquaTerm

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

2011/3/10 Hans-Bernhard Bröker wrote:
> On 09.03.2011 22:48, Mojca Miklavec wrote:
>>
>> 2011/3/9 Hans-Bernhard Bröker wrote:
>
>> Here is where all the fun begins. I *have to* install AquaTerm to
>> /usr/local/...,
>
> Says who?  Why?

If I want to choose the option "a)" (make sure libraries are only in
places where the compiler already looks by default).

>> What do you refer to with "work _with_ system like MacPorts"?
>
> Respect the choices they made.  Put stuff where they expect it (and, more
> importantly, configured their compiler to look).  Make up your mind whether
> your newly built gnuplot is to become a part
> of yoru MacPorts world, or live outside it.

I forgot to say: I want my gnuplot to live *outside* of MacPorts.
MacPorts already comes with gnuplot, but that one doesn't satisfy my
needs, so I need a "personal" one that I link from $HOME/bin/gnuplot
that is in my PATH.

However I find it perfectly fine if that personal copy of gnuplot uses
libraries like pdflib, cairo etc. from MacPorts. In fact, most of the
time I prefer if it uses them since it is way too painful to install
some of these libraries (and they keep crashing if I try).

>> But then why do all the other libraries work? Or better: why do all
>> the other libraries get included even when I don't want them to be
>> included at all
>
> Because configure can't read your mind, so it has no way of knowing what you
> want if you don't tell it.

So how can I for example:
- Tell gnuplot's configure script to use the version of aquaterm from
/usr and not the one from /opt (when I have macports in path)?
- Use UTF-8 input on Mac asssuming that I entirely remove MacPorts
from my system? (utf8.dem works fine, but no non-ascii characters are
accepted on input and I cannot use left alt as "alt-gr"; I just
realized that now.)

I know that configure can't read my mind, but:
- when I have aquaterm under both /usr and /opt, it uses the version from /opt
- when I have aquaterm only under /opt, it doesn't compile aquaterm
support at all (even though it could easily use the version from /opt)

I don't explicitely set anything to compile other libraries. They all
work out of the box. I honestly don't understand what is wrong with my
attempt to compile AquaTerm out-of-the-box as well.

>> Whenever I want to "get rid" of libraries that gnuplot or any other
>> program would take from MacPorts, I have to explicitely exclude
>> macports from PATH.
>
> Which es exactly the kind of "working against" MacPorts that I referred to
> earlier.

What exactly is "working against" here? If I remove MacPorts from
PATH? (If I do that *everything* works as expected.)

> If you don't want to use your MacPorts, why did you install them
> in the first place?

Let's say that I want to build a standalone Gnuplot.app that any user
could copy from my homepage and it would then work out of the box. I
need MacPorts most of the time, but if I leave MacPorts in PATH when I
compile gnuplot, other users won't be able to use the binary that I
compile due to dependencies on libraries provided by MacPorts. Please
don't tell me that I need to buy a new machine without MacPorts just
for the sake of compiling gnuplot that will be usable on other
machines?

Mojca

Re: building with AquaTerm

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

On 09.03.2011 22:48, Mojca Miklavec wrote:
> 2011/3/9 Hans-Bernhard Bröker wrote:

> Here is where all the fun begins. I *have to* install AquaTerm to
> /usr/local/...,

Says who?  Why?

> What do you refer to with "work _with_ system like MacPorts"?

Respect the choices they made.  Put stuff where they expect it (and, 
more importantly, configured their compiler to look).  Make up your mind 
whether your newly built gnuplot is to become a part
of yoru MacPorts world, or live outside it.

> But then why do all the other libraries work? Or better: why do all
> the other libraries get included even when I don't want them to be
> included at all

Because configure can't read your mind, so it has no way of knowing what 
you want if you don't tell it.

> Whenever I want to "get rid" of libraries that gnuplot or any other
> program would take from MacPorts, I have to explicitely exclude
> macports from PATH.

Which es exactly the kind of "working against" MacPorts that I referred 
to earlier.  If you don't want to use your MacPorts, why did you install 
them in the first place?

Re: gnuplot cvs on Mingw

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

Hello

Seeing what Hans and Bastian wrote, I feel that problem may come from old w32api libraries shipped
with your MinGW.

Regards

Tatsuro 

--- Bastian M将」rkisch wrote:

> Am 09.03.2011 00:00, schrieb Hans-Bernhard Brセュ謝ker:
> > On 08.03.2011 23:14, Petr Mikulik wrote:
> >> Can somebody compile current gnuplot cvs on Mingw?
> >
> > Works just fine here, using the version of makefile.mgw I recently added
> > as "config/mingw/Makefile", on MinGW 6.1 under MSYS.
> >
> >> For me, it complains
> >> against missing:
> >>
> >> 	AC_SRC_ALPHA
> >
> > If that's not in wingdi.h, your MinGW is too old.
> >
> >> 	TransparentBlt
> >> 	AlphaBlend
> >
> 
> Those functions are part of the GDK since Windows 2000... Time to 
> upgrade, really ;)
> 
> 
> > Those are supposed to be filled by msimg32.lib, recently added to the
> > link lists.  Are you up to date on that? makefile.mgw has to be at least
> > at revision 1.62.
> >
> >> 	gettimeofday
> >
> > That's supposed to come from MinGW itself (sys/time.h).
> >
> >> I use gcc version 3.4.4 (mingw special).
> >
> > Well, maybe it's time to upgrade, then.
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: building with AquaTerm

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

2011/3/9 Hans-Bernhard Bröker wrote:
> On 09.03.2011 19:59, Mojca Miklavec wrote:
>
>> If I use
>>     CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>> --disable-wxwidgets
>
> A side note: for quite some time this hasn't been the recommended way of
> setting flags.  That had better be
>
>  ./configure CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib
> --disable-wxwidgets
>
> i.e. with the flags initializations as arguments to ./configure, rather than
> environment variables.

Thanks for the hint. I will remember it (I was trying to use that on
several other programs and many don't favour it).

>> then it works, but it would be much better if it wasn't required to
>> manually set flags.
>
> It's up to _you_ to choose.  You can
>
> a) make sure libraries are only in places where the compiler already looks
> by default.  This is what places like /usr/local are for, and how systems
> like MacPorts supposedly work.

I would like to avoid that. *everything else* works without having to
install it separately but aquaterm.

Here are the instructions:
    http://slashusr.wordpress.com/2010/01/17/gnuplot-with-aquaterm-on-osx-snow-leopard/
But please note that it get *way* more ugly than that

Here is where all the fun begins. I *have to* install AquaTerm to
/usr/local/..., but then gnuplot will nevertheless use the version
from /opt/local/... Worse. Gnuplot will link against
/opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
and when running gnuplot, it will open /Applications/AquaTerm.app
(instead of /Applications/MacPorts/AquaTerm.app) which links against
/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm. So it will
use to possibly completely different and incompatible libraries.

And unless both the version under /opt and the "system-wide" versions
are *exactly* the same, nothing will work at all. (It simply hangs
forever.)

> b) change your compiler's configuration so the places you keep libraries get
> added to the list of places the compiler looks in (C_INCLUDE_PATH,
> D_LIBRARY_PATH or whatever), or

Thanks. This seems to make most sense, but I would still prefer if it
would work out of the box. I have found:
       C_INCLUDE_PATH
       CPLUS_INCLUDE_PATH
       OBJC_INCLUDE_PATH
       LIBRARY_PATH
But I need to check how this inferferes with other switches like
MACOSX_DEPLOYMENT_TARGET which has its own idea about default paths to
search for. I didn't test it yet.

> c) go the hard way: explicitly add those directories to the CFLAGS etc.
> every time you ./configure or otherwise build a program.

That is tedious. I find it nasty enough that I have to keep disabling
xwidgets to aviod problems. And it is even less obvious for users with
very little experience in compiling. (Those who have to compile
gnuplot on mac for one reason or the other.)

> You really have to make up your mind: either you work _with_ systems like
> MacPorts, Find or whatever, or against them.

I'm not sure that I understood this sentence (what exactly it means in
this particular context).
What do you refer to with "work _with_ system like MacPorts"?

>> It's a problem of missing -I and -L switches to search for header and
>> library files.
>
> Or it's a problem of having put libraries in a place where the compiler
> never knew to look.

But then why do all the other libraries work? Or better: why do all
the other libraries get included even when I don't want them to be
included at all (wxterminal being the most obvious one which forces me
to use --disable-wxwidgets every time when I want to build gnuplot)?

Whenever I want to "get rid" of libraries that gnuplot or any other
program would take from MacPorts, I have to explicitely exclude
macports from PATH. AquaTerm is the only exception to the rule.

Mojca

Re: building with AquaTerm

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

Mojca Miklavec wrote:
> On Wed, Mar 9, 2011 at 19:24, Ethan A Merritt
> <sf...@us...> wrote:
> > On Wednesday, March 09, 2011 07:12:54 am Mojca Miklavec wrote:
> >> 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.
> >
> > This is not very helpful as a bug report.
> > What do you mean "doesn't suffice"?
> 
> I wrote down most details, but I my explanation wasn't too clear.
> 
> If I use
>     CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
> --disable-wxwidgets
> then it works, but it would be much better if it wasn't required to
> manually set flags. (I didn't even come to the idea to do that until
> now.)

Your original post continued:
 "My next question would be how to set which aquaterm to use
  (in case there are multiple versions installed)"
One answer to that question is exactly what you have shown --
set the paths so that they are appropriate for the version of
aquaterm that you want to use.

> There is
>     /opt/local/lib/libaquaterm.dylib
> but the folder /opt/local/ is not searched by default (without
> -L/opt/local/lib), so -laquaterm fails. The same is true for headers.
> There is
>      /opt/local/include/aquaterm/aquaterm.h
> but it is not found without -I/opt/local/include/ either.

I would think that if you are relying on MacPorts for your software
installations, and if MacPorts keeps its libraries and header files in  
/opt/local,   then /opt/local should already be in your default paths.
In particular /opt/local/lib had better be in your library path because
otherwise even if you configure and build the program successfully
it will fail to run because it can't find the support libraries.

Is this really a problem specific to gnuplot and/or aquaterm, 
or is it just a normal system configuration issue?
I would have thought setting up the correct paths for /opt/local
would be part of installing MacPorts.
[goes to look via Google...]
.. and indeed it is.
The instructions are in section 2.6 of the MacPorts Guide
    http://guide.macports.org/

		Ethan

Re: building with AquaTerm

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

On Wed, Mar 9, 2011 at 19:24, Ethan A Merritt
<sf...@us...> wrote:
> On Wednesday, March 09, 2011 07:12:54 am Mojca Miklavec wrote:
>> 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.
>
> This is not very helpful as a bug report.
> What do you mean "doesn't suffice"?

I wrote down most details, but I my explanation wasn't too clear.

If I use
    CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
--disable-wxwidgets
then it works, but it would be much better if it wasn't required to
manually set flags. (I didn't even come to the idea to do that until
now.)

There is
    /opt/local/lib/libaquaterm.dylib
but the folder /opt/local/ is not searched by default (without
-L/opt/local/lib), so -laquaterm fails. The same is true for headers.
There is
     /opt/local/include/aquaterm/aquaterm.h
but it is not found without -I/opt/local/include/ either.

> The output from the configure script should indicate what piece
> has not been found.

That is the output:

   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

Compare the options with:

   configure:8736: gcc -o conftest -g -O2  -I/opt/local/include
-L/opt/local/lib conftest.c -lgd   >&5

If the test for aquaterm would have been performed with the same
options (-I/opt/local/include -L/opt/local/lib), it wouldn't fail
either, but now that these options are missing, it doesn't find
AquaTerm.


> It could be a problem with PATH, or with the
> location of a header file, or with something else entirely like a
> required support library that the configure script doesn't allow for.

It's a problem of missing -I and -L switches to search for header and
library files.

>> 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
>
> That means pdflib comes with a path configuration file.
> The configure script executes that file in order to find the
> correct -I and -L directories and also a list of required libraries.
> So one fix would be for the MacPorts version of aquaterm to also have
> a path configuration file.
>
> There is a separate, but very similar, mechanism called pkgconfig.
> pkgconfig is (at least on linux) how the configuration for cairo
> and freetype is found.
> So if aquaterm had a *.pc file for pkgconfig, that would also work.

So all that's needed is to ask the maintainer of MacPorts package to
add a file aquaterm.pc? That is probably easier and shorter than
writing aquaterm-config script. Are you ready to fix gnuplot
configuration if that gets done? (That is: if aquaterm.pc exists,
respect its flags; if it doesn't, just try the old test to see if
-laquaterm works at all.)

The fix that should be applied right away (without waiting for
MacPorts developer) is not to print out "yes" in
    aqua terminal (MacOS X): yes
unconditionally on any given mac, but to report what configure script
has found (most probably that is ac_cv_lib_aquaterm_aqtInit). And
maybe print out the warning at the end of configure script when both
x11 and aquaterm are missing (or for the more general case: if unknown
terminal will be set as the default one).

Mojca

Re: building with AquaTerm

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

On Wednesday, March 09, 2011 07:12:54 am Mojca Miklavec wrote:
> 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.

This is not very helpful as a bug report.
What do you mean "doesn't suffice"?
The output from the configure script should indicate what piece
has not been found.  It could be a problem with PATH, or with the
location of a header file, or with something else entirely like a 
required support library that the configure script doesn't allow for.

> 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

That means pdflib comes with a path configuration file.
The configure script executes that file in order to find the
correct -I and -L directories and also a list of required libraries.
So one fix would be for the MacPorts version of aquaterm to also have 
a path configuration file.   

There is a separate, but very similar, mechanism called pkgconfig.
pkgconfig is (at least on linux) how the configuration for cairo
and freetype is found.
So if aquaterm had a *.pc file for pkgconfig, that would also work.

building with AquaTerm

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

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: gnuplot cvs on Mingw

[Bastian M. <bma...@we...>]

Am 09.03.2011 00:00, schrieb Hans-Bernhard Bröker:
> On 08.03.2011 23:14, Petr Mikulik wrote:
>> Can somebody compile current gnuplot cvs on Mingw?
>
> Works just fine here, using the version of makefile.mgw I recently added
> as "config/mingw/Makefile", on MinGW 6.1 under MSYS.
>
>> For me, it complains
>> against missing:
>>
>> 	AC_SRC_ALPHA
>
> If that's not in wingdi.h, your MinGW is too old.
>
>> 	TransparentBlt
>> 	AlphaBlend
>

Those functions are part of the GDK since Windows 2000... Time to 
upgrade, really ;)


> Those are supposed to be filled by msimg32.lib, recently added to the
> link lists.  Are you up to date on that? makefile.mgw has to be at least
> at revision 1.62.
>
>> 	gettimeofday
>
> That's supposed to come from MinGW itself (sys/time.h).
>
>> I use gcc version 3.4.4 (mingw special).
>
> Well, maybe it's time to upgrade, then.

Re: gnuplot cvs on Mingw

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

Hello

Please upgrade the complier.


http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/
might be a good tool for automated install.

Regards

Tatsuro

--- Petr Mikulik  wrote:

> Can somebody compile current gnuplot cvs on Mingw? For me, it complains 
> against missing:
> 
> 	AC_SRC_ALPHA
> 	TransparentBlt
> 	AlphaBlend
> 	gettimeofday
> 
> I use gcc version 3.4.4 (mingw special).
> Gnuplot versions until 4.4.3 compile without problems.
> 
> Maybe these functions are available in Mingw 4.x, but the server is down.
> 
> Petr
> 
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: gnuplot cvs on Mingw

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

On 08.03.2011 23:14, Petr Mikulik wrote:
> Can somebody compile current gnuplot cvs on Mingw?

Works just fine here, using the version of makefile.mgw I recently added 
as "config/mingw/Makefile", on MinGW 6.1 under MSYS.

> For me, it complains
> against missing:
>
> 	AC_SRC_ALPHA

If that's not in wingdi.h, your MinGW is too old.

> 	TransparentBlt
> 	AlphaBlend

Those are supposed to be filled by msimg32.lib, recently added to the 
link lists.  Are you up to date on that? makefile.mgw has to be at least 
at revision 1.62.

> 	gettimeofday

That's supposed to come from MinGW itself (sys/time.h).

> I use gcc version 3.4.4 (mingw special).

Well, maybe it's time to upgrade, then.

gnuplot cvs on Mingw

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

Can somebody compile current gnuplot cvs on Mingw? For me, it complains 
against missing:

	AC_SRC_ALPHA
	TransparentBlt
	AlphaBlend
	gettimeofday

I use gcc version 3.4.4 (mingw special).
Gnuplot versions until 4.4.3 compile without problems.

Maybe these functions are available in Mingw 4.x, but the server is down.

Petr

Re: makefile.nt is strage

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

Hello

I have seen the change in makefile.nt.
Thanks.

Tatsuro

--- Hans-Bernhard Br将モker  wrote:

> On 05.03.2011 12:44, Tatsuro MATSUOKA wrote:
> > Hello
> >
> > I have found that strange description in the makefile.nt
> 
> This is a remainder of a past move to recycle the established name 
> pgnuplot.exe for a program that is not pgnuplot, but rather a 
> full-featured console version of gnuplot.  I had managed to convince its 
> proponents that this was a bad idea, but apparently part of the change 
> made it into the source anyway.  It went unnoticed because I never used 
> the Microsoft compiler myself.  I'll undo that silly change right away.
> 

makefile.nt is strage

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

Hello

I have found that strange description in the makefile.nt

*************************
wgnuplot_pipes.exe: win\pgnuplot.c
	cl $(CBASEFLAGS) /I$(TOP) win\pgnuplot.c /Fe$@ /link version.obj user32.lib

pgnuplot.exe: $(ALL_CONSOLE_OBJS) win\wgnuplot.def wgnuplot.res texticon.ico grpicon.ico
	$(LD) $(LDFLAGS) /out:$@ @<<
$(ALL_CONSOLE_OBJS)
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib comctl32.lib
gd.lib wxmsw28.lib wxtiff.lib
jpeg.lib png.lib
glib-2.0.lib gobject-2.0.lib gmodule-2.0.lib
cairo.lib pango-1.0.lib pangocairo-1.0.lib
wgnuplot.res
***************************
---------------------------
wgnuplot_pipes.exe: win\pgnuplot.c
	cl $(CBASEFLAGS) /I$(TOP) win\pgnuplot.c /Fe$@ /link version.obj user32.lib
---------------------------

perhaps should be

---------------------------
pgnuplot.exe: win\pgnuplot.c
	cl $(CBASEFLAGS) /I$(TOP) win\pgnuplot.c /Fe$@ /link version.obj user32.lib
---------------------------

---------------------------
pgnuplot.exe: $(ALL_CONSOLE_OBJS) win\wgnuplot.def wgnuplot.res texticon.ico grpicon.ico
	$(LD) $(LDFLAGS) /out:$@ @<<
$(ALL_CONSOLE_OBJS)
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib comctl32.lib
gd.lib wxmsw28.lib wxtiff.lib
jpeg.lib png.lib
glib-2.0.lib gobject-2.0.lib gmodule-2.0.lib
cairo.lib pango-1.0.lib pangocairo-1.0.lib
wgnuplot.res
---------------------------
perhaps should be

---------------------------
gnuplot.exe: $(ALL_CONSOLE_OBJS) win\wgnuplot.def wgnuplot.res texticon.ico grpicon.ico
	$(LD)  /out:$@ @<<
$(ALL_CONSOLE_OBJS)
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib comctl32.lib
gd.lib wxmsw28.lib wxtiff.lib
jpeg.lib png.lib
glib-2.0.lib gobject-2.0.lib gmodule-2.0.lib
cairo.lib pango-1.0.lib pangocairo-1.0.lib
wgnuplot.res
---------------------------

There is not correct expression for wgnuplot_pipes ???

I do not have enough knowledge of msvc building.
Does anyone correct them ?

Regards

Tatsuro