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

Re: Identifying system with macro

[Andrea D'A. <and...@gm...>]

On Fri, Feb 18, 2011 at 8:42 PM, Ethan A Merritt
<sf...@us...> wrote:
> I would guess that it dates back to pre-OSX days.
> Gnuplot's mac terminal was added sometime in the early 1990s,
> so maybe the macro brackets code added for compilation on a Mac Classic?

That's my guess too, I've found references to Metrowerks, author of
Codewarrior, and Symantec compiler for mac.
Nowadays that macro is useless and should be changed.

>        Ethan


Regards

-- 
Andrea

Re: Identifying system with macro

[Andrea D'A. <and...@gm...>]

2011/2/18 Hans-Bernhard Bröker <HBB...@t-...>:
>> It's not one of gcc's predefined macro on OS X (not since a few major
>> versions at least).
>
>> The current resulting default fontpath is
>> /usr/X11R6/lib/X11/fonts/Type1 that isn't even present on a standard
>> 10.6 system.
>> I've changed _Macintosh to __APPLE__ in order to have a consistent
>> default fontpath value [1]
>
> Yeah.  But are those platforms themselves as consistent across versions as
> you're making gnuplot treat them?

What platforms are you referring to with "those"?

> I.e. are there really fonts in
> directories like /System/Library/Fonts etc. on a current-day MacOS?

Yes, there are.


Regards

-- 
Andrea

Re: Lua on Ubuntu - again

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

> On Fri, 2011-02-18 at 10:38 -0800, Ethan A Merritt wrote:
> > On Friday, February 18, 2011 10:15:27 am Juhász Péter wrote:
> > > Dear list,
> > > 
> > > today I've tried to compile gnuplot (the cvs version) on a fresh Ubuntu
> > > 10.10 install. Setting up the necessary packages was relatively
> > > straightforward, but when I tried to compile, I've ran into a problem
> > > with the lua terminal.
> > > 
> > > This issue is old (it's because Ubuntu calls the package "lua5.1"
> > > instead of plain "lua" and this confuses the configure script), there is
> > > already a notice about it in the INSTALL file. That notice says that one
> > > has to set up a symlink for the package descriptor file:
> > > 
> > > ln -s /usr/lib/pkgconfig/lua5.1.pc  /usr/lib/pkgconfig/lua.pc
> > > 
> > > This used to be enough. However, the situation seemed to worsen since
> > > that notice was added. If the above symlink is in place, configure finds
> > > the package and enables the terminal. On the other hand, make fails,
> > > because the linker wants "-llua", and there is no library found by that
> > > name.
> > 
> > Could you pursue this a little further, please?
> > 
> > The whole idea of finding and executing /usr/lib/pkgconfig/lua5.1.pc
> > is that it is supposed to add the correct -Lxxxx term to the linker flags.
> > Is the library name wrong in /usr/lib/pkgconfig/lua5.1.pc, or are we
> > failing to copy it correctly into the Makefiles, or what?
> 
> The root of the problem may be found in configure.in.
> 
> Provided that the symlink for the .pc file is in place, the section
> responsible for checking lua (lines 690-703 in configure.in) will find
> the correct library name.
> 
> But then there is a second test for luaL_openlibs (I don't even know
> what that is), and that section has the library name "-llua" hardwired.
> (line 711)

This line:
AC_SEARCH_LIBS(luaL_openlibs, lua, ...

> In practice this means that the variable LUA_LIBS will be set to "-llua"
> even if it was explicitly overridden on the command line.
 
That's not what the AC_SEARCH_LIBS macro is supposed to do,
according to its documentation.
It is documented as searching one or more libraries for the requested
function and only adding the library name if it is both found and required.
You can see in the log file that I quoted that it decided 
configure:9574: result: none required
I.e.  it was able to find the lua routines without adding a new flag -llua
That's because it had already constructed a correct environment by
executing pkgconfig.

The intent is that even if we failed to find or invoke pkgconfig, we can
still test if -llua is sufficient to pull in the library. 

> It seems to me that that section in configure.in should be revised: it
> shouldn't rewrite LUA_LIBS if it already has a sensible value.

That is exactly what AC_SEARCH_LIBS is intended to do.
But I'm a novice at autotools;  I may have messed up the syntax for using
the macro.

[ goes to re-read the docs and configure.in ...]

OK.  That line
    LUA_LIBS='-llua'
is quite possibly wrong.  But if you remove it, then you also have to
also remove the fourth line below it:
    LIBS='$_libs" 

Try that to see if it fixes things on your Ubuntu system.

	Ethan

Re: Lua on Ubuntu - again

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

On Fri, 2011-02-18 at 10:38 -0800, Ethan A Merritt wrote:
> On Friday, February 18, 2011 10:15:27 am Juhász Péter wrote:
> > Dear list,
> > 
> > today I've tried to compile gnuplot (the cvs version) on a fresh Ubuntu
> > 10.10 install. Setting up the necessary packages was relatively
> > straightforward, but when I tried to compile, I've ran into a problem
> > with the lua terminal.
> > 
> > This issue is old (it's because Ubuntu calls the package "lua5.1"
> > instead of plain "lua" and this confuses the configure script), there is
> > already a notice about it in the INSTALL file. That notice says that one
> > has to set up a symlink for the package descriptor file:
> > 
> > ln -s /usr/lib/pkgconfig/lua5.1.pc  /usr/lib/pkgconfig/lua.pc
> > 
> > This used to be enough. However, the situation seemed to worsen since
> > that notice was added. If the above symlink is in place, configure finds
> > the package and enables the terminal. On the other hand, make fails,
> > because the linker wants "-llua", and there is no library found by that
> > name.
> 
> Could you pursue this a little further, please?
> 
> The whole idea of finding and executing /usr/lib/pkgconfig/lua5.1.pc
> is that it is supposed to add the correct -Lxxxx term to the linker flags.
> Is the library name wrong in /usr/lib/pkgconfig/lua5.1.pc, or are we
> failing to copy it correctly into the Makefiles, or what?

The root of the problem may be found in configure.in.

Provided that the symlink for the .pc file is in place, the section
responsible for checking lua (lines 690-703 in configure.in) will find
the correct library name.

But then there is a second test for luaL_openlibs (I don't even know
what that is), and that section has the library name "-llua" hardwired.
(line 711)
In practice this means that the variable LUA_LIBS will be set to "-llua"
even if it was explicitly overridden on the command line.

It seems to me that that section in configure.in should be revised: it
shouldn't rewrite LUA_LIBS if it already has a sensible value.

Péter Juhász

Re: Identifying system with macro

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

On Thursday, February 17, 2011 01:27:49 am Andrea D'Amore wrote:
> Hello,
> in 4.4.2 src/variable.c:247 the _Macintosh macro is checked to see if
> the system is a Mac but who's supposed to set such a macro? It's not
> one of gcc's predefined macro on OS X (not since a few major versions
> at least).

I would guess that it dates back to pre-OSX days.
Gnuplot's mac terminal was added sometime in the early 1990s,
so maybe the macro brackets code added for compilation on a Mac Classic?

	Ethan

Re: Lua on Ubuntu - again

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

On Friday, February 18, 2011 10:15:27 am Juhász Péter wrote:
> Dear list,
> 
> today I've tried to compile gnuplot (the cvs version) on a fresh Ubuntu
> 10.10 install. Setting up the necessary packages was relatively
> straightforward, but when I tried to compile, I've ran into a problem
> with the lua terminal.
> 
> This issue is old (it's because Ubuntu calls the package "lua5.1"
> instead of plain "lua" and this confuses the configure script), there is
> already a notice about it in the INSTALL file. That notice says that one
> has to set up a symlink for the package descriptor file:
> 
> ln -s /usr/lib/pkgconfig/lua5.1.pc  /usr/lib/pkgconfig/lua.pc
> 
> This used to be enough. However, the situation seemed to worsen since
> that notice was added. If the above symlink is in place, configure finds
> the package and enables the terminal. On the other hand, make fails,
> because the linker wants "-llua", and there is no library found by that
> name.

Could you pursue this a little further, please?

The whole idea of finding and executing /usr/lib/pkgconfig/lua5.1.pc
is that it is supposed to add the correct -Lxxxx term to the linker flags.
Is the library name wrong in /usr/lib/pkgconfig/lua5.1.pc, or are we
failing to copy it correctly into the Makefiles, or what?

Here is what the corresponding section of config.log looks like from a
system where this is working correctly

configure:9432: checking pkg-config is at least version 0.9.0
configure:9435: result: yes
configure:9446: checking for LUA
configure:9454: $PKG_CONFIG --exists --print-errors "lua"
configure:9457: $? = 0
configure:9472: $PKG_CONFIG --exists --print-errors "lua"
configure:9475: $? = 0
configure:9513: result: yes
configure:9526: checking for library containing luaL_openlibs
configure:9557: gcc -o conftest -g -O2   -I/usr/include  -L/usr/lib -Wl,-z,relro -Wl,-O1 -L/usr/lib conftest.c -lm  -llua -lm   >&5
configure:9557: $? = 0
configure:9574: result: none required



> An unrelated question:
> Is there a policy for keeping the gnuplot_date string in version.c
> current? Or it just gets bumped whenever there is a release?

I think it gets bumped whenever Petr notices it is out of date :-)

Re: problems with readline (compilation on mac fails)

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

On 18.02.2011 10:13, Mojca Miklavec wrote:
> 2011/2/17 Hans-Bernhard Bröker wrote:
>> On 17.02.2011 12:18, Mojca Miklavec wrote:

>>> But all the following files (in root tree) do have the executable bit set:

>> ... by luck, as of today.  That can change any time, without anybody quite
>> knowing why.

> My guess is that when a file becomes executable somebody must have
> changed the executable bit on the server (executable bits of new files
> that are added to repository match the executable bit of original
> file, but if it is changed later on the client side, that change won't
> proliferate to server).

Well, yes, that's what it's supposed to be like.  But unfortunately the 
story doesn't end there.  Files in our CVS have magically changed their 
'x' bits several times in the past.  And without shell access to the CVS 
servers, like it used to be on SF.net for most of the past 10 years, 
that means somebody has to file a support ticket, and somebody from 
SF.net staff has to do it for us.  And we can't even promise them we 
won't file the same ticket again a week later.

> I'm not talking about whether it works or not in any given client on
> any given OS,

You're missing the point.  The problem is that some clients apparently 
have the capability of breaking this _on the server_, for no particular 
reason anybody is aware of.

Lua on Ubuntu - again

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

Dear list,

today I've tried to compile gnuplot (the cvs version) on a fresh Ubuntu
10.10 install. Setting up the necessary packages was relatively
straightforward, but when I tried to compile, I've ran into a problem
with the lua terminal.

This issue is old (it's because Ubuntu calls the package "lua5.1"
instead of plain "lua" and this confuses the configure script), there is
already a notice about it in the INSTALL file. That notice says that one
has to set up a symlink for the package descriptor file:

ln -s /usr/lib/pkgconfig/lua5.1.pc  /usr/lib/pkgconfig/lua.pc

This used to be enough. However, the situation seemed to worsen since
that notice was added. If the above symlink is in place, configure finds
the package and enables the terminal. On the other hand, make fails,
because the linker wants "-llua", and there is no library found by that
name. Even an explicit "LUA_LIBS=-llua5.1" on configure's command line
won't persuade the linker to find the correct library. (Or more
precisely, the above assignment does insert the correct "-llua5.1" where
needed, but the incorrect "-llua" is still there and that makes the
linker choke.)

As a workaround, one may set up a symlink for the library as well:

ln -s /usr/lib/liblua5.1.so  /usr/lib/liblua.so

With this, the compilation goes smoothly. But fixing the configure/make
files would be a better solution.

An unrelated question:
Is there a policy for keeping the gnuplot_date string in version.c
current? Or it just gets bumped whenever there is a release?

Péter Juhász

Re: problems with readline (compilation on mac fails)

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

2011/2/17 Hans-Bernhard Bröker wrote:
> On 17.02.2011 12:18, Mojca Miklavec wrote:
>
>> (I spent a great deal of time, if not months, before I figured out
>> that I had to run the ./prepare script.)
>
> Impressive.  That information is right there in line 9 of README.1ST. :-O

Since Fri Jul 9 23:27:49 2010 if I see correctly. (I was fighting with
compilation back in 2005 or 2006, most of the time on a windows
machine and only occasionally using linux.)

Mojca

PS: I would like suggest to put the same information to INSTALL.

Re: problems with readline (compilation on mac fails)

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

2011/2/17 Hans-Bernhard Bröker wrote:
> On 17.02.2011 12:18, Mojca Miklavec wrote:
>
>> But all the following files (in root tree) do have the executable bit set:
>
> ... by luck, as of today.  That can change any time, without anybody quite
> knowing why.

My guess is that when a file becomes executable somebody must have
changed the executable bit on the server (executable bits of new files
that are added to repository match the executable bit of original
file, but if it is changed later on the client side, that change won't
proliferate to server).

I'm not talking about whether it works or not in any given client on
any given OS, but what I observe when I check out CVS is 100%
consistent with what's in original CVS repository (the following files
are from January, not the latest ones, but there is not much
difference):

-rw-rw-r--    1 user group  23K 11 sep 23:35 README,v
-rw-rw-r--    1 user group  15K 11 sep 23:35 README.1ST,v
-rw-rw-r--    1 user group  34K  6 okt 02:52 TODO,v
-rw-rw-r--    1 user group 5,5K 11 sep 23:35 VERSION,v
drwxrwsr-x    3 user group 102B 17 jan 03:31 beos
drwxrwsr-x   37 user group 1,2K 17 jan 04:55 config
-rwxrwxr-x    1 user group 332K 14 nov 01:06 configure.in,v
-r-xrwxr-x    1 user group  26K 11 sep 23:35 configure.vms,v
drwxrwsr-x  171 user group 5,7K 17 jan 04:55 demo
-r-xrwxr-x    1 user group  19K 11 sep 23:35 depcomp,v
drwxrwsr-x   38 user group 1,3K 17 jan 04:55 docs
-rwxrwxr-x    1 user group  33K 11 sep 23:35 install-sh,v
drwxrwsr-x   20 user group 680B 17 jan 04:54 lisp
drwxrwsr-x   12 user group 408B 17 jan 04:21 m4
drwxrwsr-x    8 user group 272B 17 jan 04:38 man
-rw-rw-r--    1 user group  35K 11 sep 23:35 missing,v
-rwxrwxr-x    1 user group  16K 11 sep 23:35 mkinstalldirs,v
drwxrwsr-x    3 user group 102B 17 jan 03:22 os2
drwxrwsr-x    7 user group 238B 17 jan 03:57 pm3d
-r-xrwxr-x    1 user group 5,4K 11 sep 23:35 prepare,v
drwxrwsr-x    6 user group 204B 17 jan 04:49 share
drwxrwsr-x  139 user group 4,6K 17 jan 04:56 src
-rw-rw-r--    1 user group 5,5K 11 sep 23:35 stamp-h.in,v
drwxrwsr-x   86 user group 2,9K 17 jan 04:55 term
drwxrwsr-x   19 user group 646B 17 jan 04:53 tutorial
drwxrwsr-x    3 user group 102B 17 jan 03:51 win


>> configure.in
>
> And guess what: that's wrong.  configure.in is not supposed to be
> executable.

But than you need to tell that the server, not the client:
    -rwxrwxr-x    1 user group 332K 14 nov 01:06 configure.in,v
The executable bit is present in original repository as well. I guess
that if one changes it on the server, it will also ceise to be
executable on clients. (At least on fresh checkouts ...)

Maybe CVS is not capable of tracking when the executable bit has
changed, but in this particual case I don't think that it really
matters.

Mojca

Re: problems with readline (compilation on mac fails)

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

On Thu, 17 Feb 2011, Ethan A Merritt wrote:

> > Hans-Bernhard Br�ker wrote:
> > On 17.02.2011 22:48, Ethan A Merritt wrote:
> > > On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Br�ker wrote:
> >
> > >> That's not really supposed to happen.  There's code in the Makefiles
> > >> that automatically builds everything, including configure itself,
> > >> whenever any of the files it's made from change.
> >
> > > Actually, I do not see any such depency or target in the Makefiles.
> >
> > They're there (see the top-level Makefile, look for am__configure_deps
> > and its uses), but they're disabled.  You actually disabled those
> > yourself, Ethan, when you put the AM_MAINTAINER_MODE macro into
> > configure.in.
> >
> > Now people need to run configure with --enable-maintainer-mode to get
> > back those rules, but since neither ./prepare nor any of the README
> > files mentions this fact, just about everybody, including yourself,
> > missed that.  IMHO that rather convincingly proves that
> > AM_MAINTAINER_MODE is a bad idea, and I suggest we take back that change.
>
> I myself do not care much one way or the other, but if we remove
> AM_MAINTAINER_MODE then I predict we will get complaints in the other
> direction.   Right now anyone who has a working configure file can continue
> to use it even if they don't have autotools installed.

One data-point, FWIW. In my project, gretl.sourceforge.net, we
decided to put the configure script into CVS even though (as
Hans-Bernhard says) as a generated file it doesn't belong there,
strictly speaking. The rationale for this is that given by Ethan:
it lowers the bar for people who want to build the latest and
greatest from CVS but who are not equipped with autotools. Plus,
it's not a very big deal since configure.in changes only rarely.
(I don't speak of configure.am since IMO that level of attempted
automation is evil.)

Allin Cottrell

Re: problems with readline (compilation on mac fails)

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

> Hans-Bernhard Br�ker wrote:
> On 17.02.2011 22:48, Ethan A Merritt wrote:
> > On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Br�ker wrote:
> 
> >> That's not really supposed to happen.  There's code in the Makefiles
> >> that automatically builds everything, including configure itself,
> >> whenever any of the files it's made from change.
> 
> > Actually, I do not see any such depency or target in the Makefiles.
> 
> They're there (see the top-level Makefile, look for am__configure_deps 
> and its uses), but they're disabled.  You actually disabled those 
> yourself, Ethan, when you put the AM_MAINTAINER_MODE macro into 
> configure.in.
> 
> Now people need to run configure with --enable-maintainer-mode to get 
> back those rules, but since neither ./prepare nor any of the README 
> files mentions this fact, just about everybody, including yourself, 
> missed that.  IMHO that rather convincingly proves that 
> AM_MAINTAINER_MODE is a bad idea, and I suggest we take back that change.

I myself do not care much one way or the other, but if we remove 
AM_MAINTAINER_MODE then I predict we will get complaints in the other
direction.   Right now anyone who has a working configure file can continue
to use it even if they don't have autotools installed.  If we make
"maintainer mode" the default, then these people will be forced to install
autotools before they can build from current source.  Fine, they can do that.
But meanwhile we'll get a stream of complaints/queries/bug-reports that say
"I've had no trouble building gnuplot from source in the past, but now all
of a sudden it gives me error messages about missing autoconf packages".

	Ethan

Re: problems with readline (compilation on mac fails)

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

On 17.02.2011 22:48, Ethan A Merritt wrote:
> On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Bröker wrote:

>> That's not really supposed to happen.  There's code in the Makefiles
>> that automatically builds everything, _including_ configure itself,
>> whenever any of the files it's made from change.

> Actually, I do not see any such depency or target in the Makefiles.

They're there (see the top-level Makefile, look for am__configure_deps 
and its uses), but they're disabled.  You actually disabled those 
yourself, Ethan, when you put the AM_MAINTAINER_MODE macro into 
configure.in.

Now people need to run configure with --enable-maintainer-mode to get 
back those rules, but since neither ./prepare nor any of the README 
files mentions this fact, just about everybody, including yourself, 
missed that.  IMHO that rather convincingly proves that 
AM_MAINTAINER_MODE is a bad idea, and I suggest we take back that change.

> On the other hand, I have no strong objection to putting a copy of
> the configure script into CVS.   Doing so would be no worse than
> keeping a copy of gnuplot.texi in .../docs, which we already do.

... and which routinely gets way out of synch, because 'make' doesn't 
even build it, so people don't even know they forgot to update it.

Which brings us to the key reason why generated files really should 
never be in CVS: their timestamps get jumbled at checkout/update time, 
and thus they will get out of synch without the Makefiles getting a 
chance to notice.

As-is, the gnuplot.texi in CVS is basically useless --- it's out of 
synch most of the time (by 8 revisions, or two months, right now), and 
even if you decide you want to build it explicitly by

	cd docs ; make gnuplot.texi

there are significant odds that 'make' will claim there's nothing to do 
even though the file is actually out of date.

Re: problems with readline (compilation on mac fails)

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

On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Bröker wrote:
> On 16.02.2011 11:07, Mojca Miklavec wrote:
> 
> > It seems that ./configure script was old indeed
> 
> That's not really supposed to happen.  There's code in the Makefiles 
> that automatically builds everything, _including_ configure itself, 
> whenever any of the files it's made from change.  

Actually, I do not see any such depency or target in the Makefiles.
If I do "touch configure.in; make all", it does not re-run autotools.

But please, let's not blow this up into a big deal.
Yes, you should make sure that your configure script is current.
And yes, it is possible to forget this.  I've done so myself :-)

Mojca's case was rather extreme, a configure script left over somehow
from version 4.2 being mis-matched with current CVS version 4.5.
Perhaps we could at least have the script itself test for a match to
the current MAJOR.MINOR versioning?  So you'd see something like:

   ./configure
   Error:  Sorry, the version of this configure script (4.2) does not match 
              the version of the source code (4.5)

On the other hand, I have no strong objection to putting a copy of
the configure script into CVS.   Doing so would be no worse than
keeping a copy of gnuplot.texi in .../docs, which we already do. 
In truth it would be less trouble than gnuplot.texi because changes to
configure.in are less frequent than changes to gnuplot.doc, and any
developer making changes to configure.in must surely have autotools
available whereas at least some of us do not normally have a copy
of Emacs around to regenerate gnuplot.texi every time the doc file 
is changed.

	Ethan

> So unless you lack 
> auto tools, configure shouldn't acquire bit rot like that.
> 
> > Out of curiosity: is there any reason why "configure" script is not
> > included in CVS?
> 
> Because no generated files are supposed to be.  Source control is for 
> holding source files, not generates.
> 
> > but would be easier for the end users.)
> 
> End users are not supposed to be running off CVS directly in the first 
> place.  Those who decide they want to anyway pay a price: they will need 
> some extra tools, and the skills to use them.
> 
> > On the other hand, there are two files,
> >      config/djconfig.sh
> >      missing
> > which are constantly displayed as being present in repository, but
> > they keep changing when I run ./prepare (maybe also on other
> > occasions, for example when running configure or make, I'm not sure).
> >
> > However I checked again and it seems that only executable bit is changed.
> 
> And that's because CVS is lousy at managing the permission bits of 
> working files.  The chmod is the only way we know to make sure you get 
> exactly the permissions you need.
> 
> > In short: I would like to suggest to add "configure" script to
> > repository and/or at least add executable bit to the two files
> > mentioned above.
> 
> If only that were possible in a reliable fashion.
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: problems with readline (compilation on mac fails)

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

On 17.02.2011 12:18, Mojca Miklavec wrote:
> 2011/2/17 Hans-Bernhard Bröker<HBB...@t-...>:

>> So unless you lack auto tools, configure shouldn't acquire bit rot
>> like that.

> I don't know what exactly was wrong. But the fact that I excluded
> MacPorts from PATH might explain the situation (I don't know if bare
> Mac OS X comes with the right version of autotools;

It almost certainly doesn't come with any autotools at all.

> macports probably does).


> I understand that it makes little sense to save a new version of
> gnuplot binary, several MB, each time when a single line changes. But
> ... isn't "configure" something that resembles source much better than
> it resembles binary?

It's not an issue of binary vs. source.  It's a question of a file that 
is made from some source code, as opposed to a file that's source code 
itself.

> Many people expect ./configure script to be part of the source.

People have all kinds of strange expectations.  That doesn't make them 
correct.

> (I spent a great deal of time, if not months, before I figured out
> that I had to run the ./prepare script.)

Impressive.  That information is right there in line 9 of README.1ST. :-O

> But who is supposed to be end user on Mac OS X? End users are not
> supposed to compile source in the first place, however gnuplot doesn't
> even ship binaries for mac. Ever.

You're wrong about that.  We did ship binaries of quite a few versions. 
  But without anyone on the team equipped with the tools and skills to 
build gnuplot binaries, we can't generate, much less ship any.

> And you probably do want some beta testers (even if they are not
> experts in autotools)?

You're jumping to conclusions.  You don't need to be an expert in 
autotools just to run them.

> But just as example: what am I supposed to do if my system comes with
> all the tools I need to build gnuplot, except for the tools to create
> a configure file. Am I disqualified for beta testing just because of
> that?

Only if you disqualify yourself by refusing to install those tools.

> CVS is lousy, but it is still capable of managing permission bit.

Not really.  Not with developers using CVS clients of wildly different 
version, on wildly different platforms, without direct shell access to 
files on the CVS server.  Trust me, we've been there.  In the long run 
it just doesn't work.

The problem is CVS doesn't actually _manage_ the permissions at all: the 
state of those bits is not part of the state recorded per revision. 
What you get is some of the permission bits of the archive duplicated 
into those of the working file.  Setting aside the obvious problems with 
having to flag archive files executable even though they aren't, that's 
not managing --- that's a stopgap at best.


> But all the following files (in root tree) do have the executable bit set:

... by luck, as of today.  That can change any time, without anybody 
quite knowing why.

> configure.in

And guess what: that's wrong.  configure.in is not supposed to be 
executable.

Re: problems with readline (compilation on mac fails)

[Andrea D'A. <and...@ma...>]

2011/2/17 Hans-Bernhard Bröker <HBB...@t-...>:
> I rather much doubt that.  Setting the variable GNUTERM in the environment
> should always work to override the default terminal.  See "help
> environment".

Are you talking about run-time? I'm talking about build time and
consequent default value for terminal.


-- 
Andrea

Re: problems with readline (compilation on mac fails)

[Andrea D'A. <and...@ma...>]

2011/2/17 Mojca Miklavec <moj...@gm...>:
> But just as example: what am I supposed to do if my system comes with
> all the tools I need to build gnuplot, except for the tools to create
> a configure file. Am I disqualified for beta testing just because of
> that?

You would then install the missing tool.

-- 
Andrea

Re: problems with readline (compilation on mac fails)

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

2011/2/17 Hans-Bernhard Bröker <HBB...@t-...>:
> On 16.02.2011 11:07, Mojca Miklavec wrote:
>
>> It seems that ./configure script was old indeed
>
> That's not really supposed to happen.  There's code in the Makefiles that
> automatically builds everything, _including_ configure itself, whenever any
> of the files it's made from change.  So unless you lack auto tools,
> configure shouldn't acquire bit rot like that.

I don't know what exactly was wrong. But the fact that I excluded
MacPorts from PATH might explain the situation (I don't know if bare
Mac OS X comes with the right version of autotools; macports probably
does). I faintly remember that I had problem building from CVS (that
lacks configure scripts) when I tried to compile without MacPorts in
PATH, but I may be wrong.

I can try to reproduce the behaviour if needed, but I'm not sure if
I'm able to figure out what goes wrong. I know that I have generated
configure script a long time ago. I don't know if I ever called
./prepare again (there was no need to up to this moment).

>> Out of curiosity: is there any reason why "configure" script is not
>> included in CVS?
>
> Because no generated files are supposed to be.  Source control is for
> holding source files, not generates.

I understand that it makes little sense to save a new version of
gnuplot binary, several MB, each time when a single line changes. But
... isn't "configure" something that resembles source much better than
it resembles binary?

Many people expect ./configure script to be part of the source. (I
spent a great deal of time, if not months, before I figured out that I
had to run the ./prepare script.)

I understand that Makefiles have nothing to do in repository since
they highly depend on local configuration, but it seems that
./configure script is pretty much universal, rarely changes, it would
come in handy (I cannot build gnuplot on bare Mac OS X without
configure script), tracking changes doesn't cost much ...

In this particular case of configure script I consider advantages
would far outweight the drawbacks (like developer forgetting to run
./prepare when commiting some important changes, but that would be
soon discovered and easy to fix).

>> but would be easier for the end users.)
>
> End users are not supposed to be running off CVS directly in the first
> place.

But who is supposed to be end user on Mac OS X? End users are not
supposed to compile source in the first place, however gnuplot doesn't
even ship binaries for mac. Ever. (On mac, end users are often not
even supposed to use the Terminal, even when speaking about TeX
users.)

And you probably do want some beta testers (even if they are not
experts in autotools)?

> Those who decide they want to anyway pay a price: they will need
> some extra tools, and the skills to use them.

Sure.

But just as example: what am I supposed to do if my system comes with
all the tools I need to build gnuplot, except for the tools to create
a configure file. Am I disqualified for beta testing just because of
that?

>> On the other hand, there are two files,
>>     config/djconfig.sh
>>     missing
>> which are constantly displayed as being present in repository, but
>> they keep changing when I run ./prepare (maybe also on other
>> occasions, for example when running configure or make, I'm not sure).
>>
>> However I checked again and it seems that only executable bit is changed.
>
> And that's because CVS is lousy at managing the permission bits of working
> files.  The chmod is the only way we know to make sure you get exactly the
> permissions you need.

CVS is lousy, but it is still capable of managing permission bit. (The
./prepare script consistently has that bit set, I see no reason why
the other two files couldn't have the executable bit set right.)

http://stackoverflow.com/questions/710592/how-do-i-add-execute-permission-to-a-file-in-cvs-after-its-already-been-checked

>> In short: I would like to suggest to add "configure" script to
>> repository and/or at least add executable bit to the two files
>> mentioned above.
>
> If only that were possible in a reliable fashion.

But all the following files (in root tree) do have the executable bit set:

configure.in
configure.vms
depcomp
install-sh
mkinstalldirs
prepare

so I don't see why it would be such a problem to also set it on the
two other files.

prepare script says

exelist="configure configure.vms depcomp install-sh missing
mkinstalldirs config/djconfig.sh lisp/configure"
chmod 755 $exelist >/dev/null 2>&1

I'm not saying that those two lines should go away, only that it would
be nice to set the bit to the remaining two files.

Mojca

Re: AquaTerm (was: problems with readline (compilation on mac fails))

[Andrea D'A. <and...@ma...>]

On Thu, Feb 17, 2011 at 10:58 AM, Mojca Miklavec
<moj...@gm...> wrote:
>> Btw I've tried to use macports to build gnuplot with a default x11
>> terminal and I wasn't able to do that, no matter what the env is,
>> configure manage to set aqua as default terminal. I ended using "set
>> terminal x11" into ~/.gnuplot .

> If I uninstall system-wide AquaTerm and only keep the one shipped with
> MacPorts, gnuplot won't even compile with AquaTerm support, so I
> always get x11

And this is just ironic.


-- 
Andrea

AquaTerm (was: problems with readline (compilation on mac fails))

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

On Thu, Feb 17, 2011 at 10:02, Andrea D'Amore wrote:
> On Mon, Feb 14, 2011 at 10:31 AM, Mojca Miklavec wrote:
>> Dear list,
>> if I remove MacPorts from PATH (I had to do it since I have serious
>> problems with AquaTerm), building fails with:
>
> Out of curiosity why did you remove mp from PATH?

A few times I have tried to build a standalone gnuplot (independent of
macports), but this time I was doing experiments with AquaTerm.
AquaTerm doesn't provide 64-bit binaries and was just experimenting
with that. If I build gnuplot with MacPorts then AquaTerm works
(however the latest version of gnuplot complains that aquaterm doesn't
support transparency and it complains when I build it).

But when I use macports, I cannot test if my own build of AquaTerm
works (apparently it doesn't, but that's an independent issue).

> You can still use
> x11 terminal even with MacPorts' build of gnuplot.

I'm not interested in x11 (except that I'm lucky to have a working
backup terminal when aquaterm fails), but in particular I'm not
interested in MacPorts' gnuplot since it doesn't satisfy my needs.

> Btw I've tried to use macports to build gnuplot with a default x11
> terminal and I wasn't able to do that, no matter what the env is,
> configure manage to set aqua as default terminal. I ended using "set
> terminal x11" into ~/.gnuplot .

If I uninstall system-wide AquaTerm and only keep the one shipped with
MacPorts, gnuplot won't even compile with AquaTerm support, so I
always get x11 (for some reason I like AquaTerm more despite many of
its drawbacks).

Mojca

Identifying system with macro

[Andrea D'A. <and...@gm...>]

Hello,
in 4.4.2 src/variable.c:247 the _Macintosh macro is checked to see if
the system is a Mac but who's supposed to set such a macro? It's not
one of gcc's predefined macro on OS X (not since a few major versions
at least).

The current resulting default fontpath is
/usr/X11R6/lib/X11/fonts/Type1 that isn't even present on a standard
10.6 system.
I've changed _Macintosh to __APPLE__ in order to have a consistent
default fontpath value [1]

Btw why do a few paths in variable.c have a trailing exclamation mark
while others don't?


Regards

-- 
Andrea


[1] http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-src-variable_c.diff

Re: problems with readline (compilation on mac fails)

[Andrea D'A. <and...@ma...>]

On Mon, Feb 14, 2011 at 10:31 AM, Mojca Miklavec
<moj...@gm...> wrote:
> Dear list,
> if I remove MacPorts from PATH (I had to do it since I have serious
> problems with AquaTerm), building fails with:

Out of curiosity why did you remove mp from PATH? You can still use
x11 terminal even with MacPorts' build of gnuplot.

Btw I've tried to use macports to build gnuplot with a default x11
terminal and I wasn't able to do that, no matter what the env is,
configure manage to set aqua as default terminal. I ended using "set
terminal x11" into ~/.gnuplot .


--
Andrea

Re: problems with readline (compilation on mac fails)

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

On 16.02.2011 11:07, Mojca Miklavec wrote:

> It seems that ./configure script was old indeed

That's not really supposed to happen.  There's code in the Makefiles 
that automatically builds everything, _including_ configure itself, 
whenever any of the files it's made from change.  So unless you lack 
auto tools, configure shouldn't acquire bit rot like that.

> Out of curiosity: is there any reason why "configure" script is not
> included in CVS?

Because no generated files are supposed to be.  Source control is for 
holding source files, not generates.

> but would be easier for the end users.)

End users are not supposed to be running off CVS directly in the first 
place.  Those who decide they want to anyway pay a price: they will need 
some extra tools, and the skills to use them.

> On the other hand, there are two files,
>      config/djconfig.sh
>      missing
> which are constantly displayed as being present in repository, but
> they keep changing when I run ./prepare (maybe also on other
> occasions, for example when running configure or make, I'm not sure).
>
> However I checked again and it seems that only executable bit is changed.

And that's because CVS is lousy at managing the permission bits of 
working files.  The chmod is the only way we know to make sure you get 
exactly the permissions you need.

> In short: I would like to suggest to add "configure" script to
> repository and/or at least add executable bit to the two files
> mentioned above.

If only that were possible in a reliable fashion.

Re: funny filenames on Windows?

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

On Wed, 16 Feb 2011, Benjamin Lindner wrote:

> > I'm wondering, is it likely that gnuplot would have a problem on
> > MS Windows if the name of a plot file given as a command line
> > argument contained an apostrophe?
> >
> > I ask because of a problem report from a user of my program,
> > gretl, which calls gnuplot: in this case the command line (passed
> > to the Windows API function CreateProcess) would look something
> > like:
> >
> > "c:\path\to\wgnuplot.exe" "c:\users\silly's\subdir\plot.gp"
> >
> > The command is not working; I'm not certain the apostrophe is the
> > problem but it seems a likely candidate. (I'm pretty sure the plot
> > file itself is well-formed.)
>
> How exactly is it "not working"?

Exit status 1; I'd like more information but I don't have it at
present.

> I tested your example using a simple tes't.gp file containing
>    set term windows
>    plot sin(x)
>
> and called c:\path\to\wgnuplot "c:\path\to\tes't.gp"
> and it works as expected.

OK, thanks for testing. Then it seems it's not the plot filename
that's the problem. I'll pursue other possibilities.

Allin Cottrell

Re: Issues with windows terminal (size&position)

[Benjamin L. <bj...@gm...>]

>
> Comments?
>

I updated the patch to adress the issue of specifying only the size or
position and keeping the respective other property untouched.

benjamin