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

Re: Relative executable path. Was Re: gnuplot Mac pkg

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

On Fri, 11 Mar 2016, Allin Cottrell wrote:

> I think that if I were going to insert a more helpful default path for 
> gnuplot.gih at build time (not a bad idea) it would be better to make it the 
> canonical path for a Mac-type installation, namely under
>
> /Applications/Gnuplot.app/Contents/Resources/share

Actually, that's such an obvious improvement that I've now rebuilt 
my pkg and dmg with PREFIX set to

/Applications/Gnuplot.app/Contents/Resources

I think this means that if you install in the standard location you 
should be able to run gnuplot from the shell just my making a 
suitable symlink to the gnuplot binary at

/Applications/Gnuplot.app/Contents/Resources/bin/gnuplot

If you install elsewhere it'll still be necessary to use my wrapper 
script to get the envionment right.

Allin Cottrell

Re: Relative executable path. Was Re: gnuplot Mac pkg

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

On Fri, 11 Mar 2016, Nicolas Brouard (INED) wrote:

>
>> Le 10 mars 2016 à 23:21, Allin Cottrell <cot...@wf...> a écrit :
>> There's now an updated build at
>>
>> http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg <http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg>
>
> I looked at your dmg above and everything seems working but the 
> hard link to gnuplot.gih could be replaced with its “standard" 
> location -DHELPFILE=\"/usr/local/share/gnuplot/5.0/gnuplot.gih\" 
> instead of yours at build time:
>
> gnuplot> help set ter
>
> /home/cottrell/stats/q2/Gretl.app/Contents/Resources/share/gnuplot/5.0/gnuplot.gih: No such file or directory
>
> Then anyone could avoid the use of your script “gnuplot.sh" with 
> the environments GNUHELP,GNUPLOT_PS_DIR. And at installation time 
> the .dmg could move this important file to 
> /usr/locall/share/gnuplot/5.0/. I agree that it is not completely 
> the spirit of OS/X and Apps.

I think that if I were going to insert a more helpful default path 
for gnuplot.gih at build time (not a bad idea) it would be better to 
make it the canonical path for a Mac-type installation, namely under

/Applications/Gnuplot.app/Contents/Resources/share

>
> But it seems that the following command to get the correct relative path to binary doesn’t go into error but does a simple ‘touch’ without any warinng!
> $ install_name_tool -change /usr/local/share/gnuplot/5.0/gnuplot.gih @executable_path/../share/gnuplot.gih bin/gnuplot
>
> @executable_path works only (yet?) for objects.

Yes. I don't expect that's going to change.

Allin Cottrell

Relative executable path. Was Re: gnuplot Mac pkg

[Nicolas B. (INED) <br...@in...>]

> Le 10 mars 2016 à 23:21, Allin Cottrell <cot...@wf...> a écrit :
> There's now an updated build at
> 
> http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg <http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg>

I looked at your dmg above and everything seems working but the hard link to gnuplot.gih could be replaced with its “standard" location -DHELPFILE=\"/usr/local/share/gnuplot/5.0/gnuplot.gih\" instead of yours at build time:
gnuplot> help set ter
/home/cottrell/stats/q2/Gretl.app/Contents/Resources/share/gnuplot/5.0/gnuplot.gih: No such file or directory
Then anyone could avoid the use of your script “gnuplot.sh" with the environments GNUHELP,GNUPLOT_PS_DIR. And at installation time the .dmg could move this important file to /usr/locall/share/gnuplot/5.0/. I agree that it is not completely the spirit of OS/X and Apps.

But it seems that the following command to get the correct relative path to binary doesn’t go into error but does a simple ‘touch’ without any warinng!
$ install_name_tool -change /usr/local/share/gnuplot/5.0/gnuplot.gih @executable_path/../share/gnuplot.gih bin/gnuplot

@executable_path works only (yet?) for objects.

On Linux we could use readlink("/proc/self/exe", buf, bufsize) or argv[0] to get the binary location, but on OS/X I don’t know.

After the error No such file or directory, does gnuplot search for any other location? On OS/X we could try the path given by -DHELPFILE=\”$BINDIR/../share/gnuplot/5.0/gnuplot.gih\” before displaying the error but BINDIR should not be hardcoded but equivalent to @executable_path, that is dependent on where the binary is installed and executed. I even don’t know if it exists on Linux. 

But the success of OS/X resides in the fact any App is using its own dated libraries (under the lib, share etc subdirectories) giving to the application a longer life expectancy. The time where disk space was a problem is over today. Thus we can have many different versions of a library on our hard disk. What  the user is expecting is a working App. Moving the App to the bin if it is too old.


--
Nicolas

> 
> Allin Cottrell
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Now available: Gnuplot in Action, 2nd Edition

[Philipp K. J. <ja...@ie...>]

Now available: 

	Gnuplot in Action, Second Edition

	https://www.manning.com/books/gnuplot-in-action-second-edition

After the usual and inevitable delays associated
with such a project, the 2nd edition of my book
"Gnuplot in Action" is now complete. It has been
sent to the printer; copies will be on the shelves 
within a couple of weeks.

An eBook version (with extra content and full color
graphics) is also available. Print book customers
receive the eBook for free as part of their purchase.

Although based on the 1st edition (which was published
in 2009), this is essentially a new book. It has been 
completely revised and fully updated to cover Gnuplot 5.

Highlights from the new edition:

- Full coverage of plots and standard features
  Including details on plot types, arrows and labels,
  keys and tic marks

- Color, color, color
  Color specifications, alpha shading and transparency,
  data-dependent coloring, false-color plots

- Terminal handling in depth
  Cairo-based terminals, SVG and HTML5 terminals,
  Latex terminals, terminal workflow

- Fonts and Unicode
  Detailed information on gnuplot's new font selection
  and Unicode strings: special symbols were never so easy!
  
- Loops, scripting, batch operations
  In addition to interactive use, gnuplot can also serve
  as programming environment for graphs. This books shows
  you how.

- ... and so much more!

Thanks to everyone on this list who has helped, through
advice or correspondence - and by keeping gnuplot active
and alive!

I hope you'll find the new edition useful - check it out!

Best,

		Ph.

Re: gnuplot Mac pkg

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

On Fri, 11 Mar 2016, Jun T. wrote:

>
> 2016/03/10 02:05, Allin Cottrell <cot...@wf...> wrote:
>>
>> http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.pkg
>> http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg
>
> Thanks. From the mounted dmg, I can install Gnuplot.app to anywhere,
> for example to my Desktop. If a user has no admin privilege then
> she/he can't install into /Applications.
>
>> On recent OS X this is kind of an "expert" option, since it may be
>> non-obvious what double-clicking on a DMG file does (it'll get mounted,
>> but likely hidden at the bottom of the finder window, so it can look as
>> if "nothing happened").
>
> Usually, when I double click on a dmg file, it is mounted, and its
> window is opened as a frontmost window, i.e., not covered by any other
> windows (at least on OS X 10.9.5). What do you mean by 'recent OS X'?

I'm not a Mac user myself, but... it seems to me that back on OS X 
10.6 my dmg files would open as expected, while from Lion onwards 
when I observed my students trying to install software from dmg 
files they would end up mounted "invisibly". This may have to do 
with settings that I don't understand.

> But yes, if I double click on the gnuplot dmg, it is mounted but no
> window opens. I don't know why.
> Another problem is the dmg is writable.
>
> How did you make the dmg file? Did you try DiskUtility.app? It can
> make a read-only (and compressed) dmg file.

No, I'm not using DiskUtility, I'm doing everything on Linux; that's 
my working environment. (I have occasional access to a Mac for 
testing.) But I think I've found a way of creating a more 
"idiomatic" DMG. There's now an updated build at

http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg

Allin Cottrell

Re: gnuplot Mac pkg

[Jun T. <tak...@kb...>]

2016/03/10 02:05, Allin Cottrell <cot...@wf...> wrote:
> 
> http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.pkg
> http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg

Thanks. From the mounted dmg, I can install Gnuplot.app to anywhere,
for example to my Desktop. If a user has no admin privilege then
she/he can't install into /Applications.

> On recent OS X this is kind of an "expert" option, since it may be
> non-obvious what double-clicking on a DMG file does (it'll get mounted,
> but likely hidden at the bottom of the finder window, so it can look as
> if "nothing happened").

Usually, when I double click on a dmg file, it is mounted, and its
window is opened as a frontmost window, i.e., not covered by any other
windows (at least on OS X 10.9.5). What do you mean by 'recent OS X'?

But yes, if I double click on the gnuplot dmg, it is mounted but no
window opens. I don't know why. 
Another problem is the dmg is writable.

How did you make the dmg file? Did you try DiskUtility.app? It can
make a read-only (and compressed) dmg file.

Re: gnuplot Mac pkg

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

On Wed, 9 Mar 2016, Jun T. wrote:

> On 2016/03/08, at 1:37, Allin Cottrell <cot...@wf...> wrote:
>> I've put up a revised version at the same place,
>> http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg
>
> After install, I've 'sudo mv'ed the Gnuplot.app to places other
> than /Applications/, and it seems it still works fine.
>
> Since the startup script properly sets the environment variables,
> the help file gnuplot.gih and the prologue files for postscript
> terminal are correctly found even if I move the Gnuplot.app. Great!
>
> Isn't it possible to make a dmg from which users can drag and drop
> Gnuplot.app to anywhere they want?

Yes, it's possible. On recent OS X this is kind of an "expert" option, 
since it may be non-obvious what double-clicking on a DMG file does 
(it'll get mounted, but likely hidden at the bottom of the finder 
window, so it can look as if "nothing happened"). However, I've now 
added a dmg file at

http://ricardo.ecn.wfu.edu/pub/gnuplot/

(where the packaged gnuplot version is now 5.0.3).

> One minor problem. If I run
> gnuplot> help
> and type 'q', then 'Help topics available:' is shown, but
> it does not include 'terminal'. I don't now why. But
> gnuplot> help terminal
> still works. But in 'Subtopics available for terminal:', 'aqua'
> is missing but 'x11' exists.

Oops, yes, I included the wrong gih file. That's now fixed in

http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.pkg
http://ricardo.ecn.wfu.edu/pub/gnuplot/gnuplot-5.0.3-quartz.dmg

Allin Cottrell

Re: gnuplot Mac pkg

[Jun T. <tak...@kb...>]

On 2016/03/08, at 1:37, Allin Cottrell <cot...@wf...> wrote:
> I've put up a revised version at the same place,
> http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg


After install, I've 'sudo mv'ed the Gnuplot.app to places other
than /Applications/, and it seems it still works fine.

Since the startup script properly sets the environment variables,
the help file gnuplot.gih and the prologue files for postscript
terminal are correctly found even if I move the Gnuplot.app. Great!

Isn't it possible to make a dmg from which users can drag and drop
Gnuplot.app to anywhere they want?


One minor problem. If I run
gnuplot> help
and type 'q', then 'Help topics available:' is shown, but
it does not include 'terminal'. I don't now why. But
gnuplot> help terminal
still works. But in 'Subtopics available for terminal:', 'aqua'
is missing but 'x11' exists. And
gnuplot>help aqua
does not work.

Maybe a slightly old version of gnuplot.gih is included?

Re: Mac-related buglets

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

> 3) In the toolbar at the top of the wxt window, gnuplot mixes and matches icons 

> provided in bitmap form in the gnuplot source tree and others provided by 
> wxWidgets' wxArt module. This works OK on some platforms but produces a 
> rather horrid appearance with the cocoa version of wx. My suggestion is to cut 
> out wxArt and provide all the icons in uniform bitmap format. This involves 
> adding one bitmap and making minor changes to wxt_gui.cpp and wxt_gui.h. The 
> files to do this can be found at
> 
> http://ricardo.ecn.wfu.edu/pub/gnuplot/patches/
> 
> save_png.h is supposed to go into src/wxterminal/bitmaps/png/ and the two .diff 
> files are supposed to be applied in src/wxterminal.
> 
> Thanks to Mojca, we have "before" and "after" images:
> 
> before:
> http://ricardo.ecn.wfu.edu/pub/gnuplot/patches/gnuplot-wxt-default.png
> 
> after:
> http://ricardo.ecn.wfu.edu/pub/gnuplot/patches/gnuplot-wxt-allin.png
> 
> So far as I can tell (from using wxt on Linux), this modification doesn't 
> mess up the appearance on platforms other than the Mac.
> 
> -- Allin Cottrell



I think that it is better if your patch will be imported to the CVS tree.
Please make a bug ticket and discuss there.

Tatsuro 

Mac-related buglets

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

In building gnuplot for the Mac lately, I've run into a few minor 
issues.

1) When you're building wxt using the cocoa version of wxWidgets, 
the gnuplot 5.0.3 build wants to drag in the GTK libraries even 
though they're not relevant. This is easily fixed by back-porting a 
stanza from configure.ac in CVS. Patch attached: 
gnuplot-503-configure.in.diff.

2) There's a couple of apparently dodgy calls to abs() in 
aquaterm.trm, in the function ENHAQUA_open, which draw warnings
from clang:

   if (abs(base)>0.01) ...

and

   if (abs(fontsize - AQUA_fontSizeCur)>0.01) ...

abs() is a standard library function that takes an int argument and 
returns an int, but here "base" and "fontsize" are doubles. It does 
look as if fabs() should be used instead.

3) In the toolbar at the top of the wxt window, gnuplot mixes and 
matches icons provided in bitmap form in the gnuplot source tree and 
others provided by wxWidgets' wxArt module. This works OK on some 
platforms but produces a rather horrid appearance with the cocoa 
version of wx. My suggestion is to cut out wxArt and provide all the 
icons in uniform bitmap format. This involves adding one bitmap and 
making minor changes to wxt_gui.cpp and wxt_gui.h. The files to do 
this can be found at

http://ricardo.ecn.wfu.edu/pub/gnuplot/patches/

save_png.h is supposed to go into src/wxterminal/bitmaps/png/ and 
the two .diff files are supposed to be applied in src/wxterminal.

Thanks to Mojca, we have "before" and "after" images:

before:
http://ricardo.ecn.wfu.edu/pub/gnuplot/patches/gnuplot-wxt-default.png

after:
http://ricardo.ecn.wfu.edu/pub/gnuplot/patches/gnuplot-wxt-allin.png

So far as I can tell (from using wxt on Linux), this modification 
doesn't mess up the appearance on platforms other than the Mac.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

gnuplot Mac pkg

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

Thanks to those who tested the package I mentioned in
https://sourceforge.net/p/gnuplot/mailman/message/34907517/

I've put up a revised version at the same place,
http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg

In this version I have removed from the Distribution XML file the line

<options hostArchitectures="x86_64"/>

which is apparently more restrictive than I thought. This package just 
needs a 64-bit userspace, but including that line prevents 
installation on systems, such as OS X 10.6, that are not "fully 
64-bit" (10.6 has a 32-bit kernel). I think that should quell the 
"Cannot be installed" message.

I've also found and deleted a few more libraries that are required by 
gretl but not needed for gnuplot, so the package is a little slimmer.

A couple of comments on things I didn't include in the package:

* The libgd-based png terminal. I don't see much point in that one if 
you have pngcairo (unless perhaps, as Ethan has pointed out, you want 
to make animated GIFs). Also, including libgd will drag in a 
fontconfig dependency which is not otherwise needed. (Pango doesn't 
need fontconfig on OS X, it's better off using Apple's CoreText.)

* X11. Given the wxt terminal, IMO the X11 terminal doesn't add value. 
I guess I might have included it if Apple still included an X server 
with OS X by default, but making XQuartz a prerequisite for a gnuplot 
package seems unnecessary.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: More Mac cloning thoughts

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

----- Original Message -----

> From: Thomas Mattison 
> To: gnuplot-beta 
> Cc: 
> Date: 2016/3/6, Sun 04:32
> Subject: More Mac cloning thoughts
> 
>T his is on a Mac mini Core 2 Duo running 10.6.8.
> 
> So far, my recipe is
> 
> Install Aquaterm application and XQuartz
> 
> Do .configure, make, sudo make install, and make DESTDIR=/tmp/gnuplot on the 
> following:
> zlib-1.2.8, libpng-1.5.26, freetype-2.4.10, gd-2.0.33, gnuplot-5.0.3
> 
> This produces a gnuplot with the built-in terminals, X11, Aquaterm, png, and 
> gif.
> That's enough to be useful.
> 
> It also produces a tree under /tmp/gnuplot which has  /usr/local/, under which 
> is
> /bin/ containing the gnuplot executable, and lots of other executables made by 
> the libraries above
> /libexec/ containing /gnuplot/5.0/gnuplot_x11
> /lib/ containing the libraries made above
> /include/ containing headers for the above libraries
> /share/man/man1 with gnuplot.1 and gnuplot-ja.a
> /share/man3/ and /share/man5/ with library man files
> /texlive/ with a tree leading to gnuplot.cfg
> 
> A simple sudo rsync on a different Mac should push all that stuff into the 
> standard locations as if it had been built there.
> For the target case of a student Mac not used for Unix development, would that 
> be expected to cause problems?
> 
> If it would cause problems, is there some simple way to configure the build 
> process so the gnuplot executable would look in some non-standard directory for 
> the libraries, so I could make the rsync put the libraries where they 
> wouldn't cause trouble on the target system?
> 
> 
> 
> I realize that if the target Mac is used for Unix-style development, doing the 
> rsync would be ill-advised.
> But if the Mac is used for Unix-style development, then it would be easy to just 
> do a local build of gnuplot,
> and the rsync approach wouldn't be needed.
> 
> 
> 
> 
> Hopefully Allin Cottrell's gnuplot.app for Mac will become a regular 
> product.  Then non-developer Mac users will be able to enjoy Gnuplot, like 
> non-developer Windows users.  And my humble efforts at cloning Mac installations 
> will be irrelevant.  
> 

I am one of volunteers who makes windows binary for regular release (e.g. 5.0.0 etcs.)
I also have uploaded cvs snapshot of windows and Cygwin binaries.

I have never used modern Mac. I sometime uses Linux (Ubuntu 14.04).

On windows, build process of gnuplot does not use configure but uses specific makefile.
For mingw build, specific makefile is very powerful.
One can build full featured gnuplot, GUI help file, all documents including manual,
windows installer and zip archived packages using the specific makefile if 
one can prepare all libraries and external tools.

For Unix like environments, I do not think that package management system should be 
included in configure and makefile system of gnuplot. 
My opinion is that out of box managements should be desirable.

> Do .configure, make, sudo make install, and make DESTDIR=/tmp/gnuplot on the 
> following:
> zlib-1.2.8, libpng-1.5.26, freetype-2.4.10, gd-2.0.33, gnuplot-5.0.3

I recommend to link with also the fontconfig library. Without it, 
the gd based terminals (png, gif,(jpeg)) cannot pull full features of gnuplot.
(Font specification like "set terminal png font 'Helvatica, 12'" 
and Bold and Italic in the enhanced text mode.)

And gd-2.0.33 is out of date. 
If possible, please use gd library version of which is 2.1.0 or higher.
(gd-2.0.33 has a bug for fontconfig treatments.)

> It also produces a tree under /tmp/gnuplot which has  /usr/local/, under which 
> is
> /bin/ containing the gnuplot executable, and lots of other executables made by 
> the libraries above
> /libexec/ containing /gnuplot/5.0/gnuplot_x11
> /lib/ containing the libraries made above
> /include/ containing headers for the above libraries
> /share/man/man1 with gnuplot.1 and gnuplot-ja.a
> /share/man3/ and /share/man5/ with library man files
> /texlive/ with a tree leading to gnuplot.cfg

Terminals that are built without external libraries include 
the postscript and the canvas terminal and they require additional
files.

On cygwin (cvs 5.1.0) binaries that I distribute is considered to install
to /opt/gp510
Under /opt/gp510

bin: gnuplot.exe (exe extention windows specific) and shared library for wxwidgets 
that are not supported in the official Cygwin.

libexec/gnuplot/5.1/: gnuplot_x11.exe

share/gnuplot/5.1/ : additional script and gnuplot.gih (help file)

share/gnuplot/5.1/Postscipt : files required to use postscript terminal and documents.

share/gnuplot/5.1/app-defaults : "Gnuplot"  the file should be placed at appropriate
place that depends on environmets if you use x11 terminal.

share/gnuplot/5.1/js : files and documents for the canvas terminal.

share/gnuplot/5.1/lua files and documents for lua/tikz terminal.
(In your configuration, lua directory is not necessary.)

Include directory is not necessary but lib directory may not be omitted
if it includes shared libraries (.so files).

Hope the above helps.

Tatsuro

More Mac cloning thoughts

[Thomas M. <mat...@ph...>]

This is on a Mac mini Core 2 Duo running 10.6.8.

So far, my recipe is

Install Aquaterm application and XQuartz

Do .configure, make, sudo make install, and make DESTDIR=/tmp/gnuplot on the following:
zlib-1.2.8, libpng-1.5.26, freetype-2.4.10, gd-2.0.33, gnuplot-5.0.3

This produces a gnuplot with the built-in terminals, X11, Aquaterm, png, and gif.
That's enough to be useful.

It also produces a tree under /tmp/gnuplot which has  /usr/local/, under which is
/bin/ containing the gnuplot executable, and lots of other executables made by the libraries above
/libexec/ containing /gnuplot/5.0/gnuplot_x11
/lib/ containing the libraries made above
/include/ containing headers for the above libraries
/share/man/man1 with gnuplot.1 and gnuplot-ja.a
/share/man3/ and /share/man5/ with library man files
/texlive/ with a tree leading to gnuplot.cfg

A simple sudo rsync on a different Mac should push all that stuff into the standard locations as if it had been built there.
For the target case of a student Mac not used for Unix development, would that be expected to cause problems?

If it would cause problems, is there some simple way to configure the build process so the gnuplot executable would look in some non-standard directory for the libraries, so I could make the rsync put the libraries where they wouldn't cause trouble on the target system?



I realize that if the target Mac is used for Unix-style development, doing the rsync would be ill-advised.
But if the Mac is used for Unix-style development, then it would be easy to just do a local build of gnuplot,
and the rsync approach wouldn't be needed.




Hopefully Allin Cottrell's gnuplot.app for Mac will become a regular product.  Then non-developer Mac users will be able to enjoy Gnuplot, like non-developer Windows users.  And my humble efforts at cloning Mac installations will be irrelevant.  





                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Re: Progress on Mac installation cloning

[Jun T. <tak...@kb...>]

On Mar 5, 2016, at 05:08, Allin Cottrell <cot...@wf...> wrote:

> On Sat, 5 Mar 2016, Jun T. wrote:
>>> * After installation, you can launch gnuplot via its icon in
>>> Applications; this opens an instance of Terminal with gnuplot
>>> running in it.
>> 
>> This doesn't happen (OS X 10.9.5), but
> 
> Hmm. Clicking on the gnuplot icon in Applications should be about
> equivalent to executing
> 
> /Applications/Gnuplot.app/Contents/MacOS/gnuplot.sh
> 
> from the command line. If you have time, could you try that and see what's going wrong?

Never mind. It was due to my (multiple) non-standard settings.

# I will send a long detail personally, since it has nothing to do
# with gnuplot.

Re: More Mac cloning progress

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

On 4 March 2016 at 21:44,  <pl...@pi...> wrote:
>
> Advanced package managers on Linux systems tend to take care of this
> kind of thing and ensure all software installed is consistent.  From
> others comments this is clearly not the case on MacOSX.

It's just that one doesn't come by default. One can still install a
third party package manager.

> The LInux
> package managers  manage the dependency hell you are likely to encounter.

To be fair, Linux would not be much different in this particular case.
Assume that one would want to provide a patched gnuplot binary to
students running linux. The fact that linux is great at managing
dependencies is actually useless in this case because the one
providing the binaries doesn't know whether the target machine has
wxWidgets 2.8 or 3.0 installed for example (the same problem for any
other dependency), so in order to be able to provide linux binaries,
one would either have to ship all the dependencies along with the
binary (not much different from what many are criticising about OS X)
or build one package per each version of each linux distribution that
should be supported.


What Allin provided is *the* solution that should be used to
distribute gnuplot for OS X. No libraries conflict with each other (it
doesn't clutter the user's system and cluttering the system won't
affect Gnuplot.app), it is super easy to handle and just works.

Thomas, if what Allin provided doesn't satisfy your needs for one
reason or another or if you want to be able to build it independently,
try to at last replicate what he did with a potentially different set
of libraries.

Mojca

Re: Progress on Mac installation cloning

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

On Sat, 5 Mar 2016, Mojca Miklavec wrote:

> On 4 March 2016 at 19:27, Allin Cottrell wrote:
>>
>> I thought it might be worth making a gnuplot bundle by stripping 
>> out all the gretl stuff and revising the metadata.
>>
>> You can find the result at
>> http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg
>
> Thanks a lot!
>
> I kept fighting a lot trying to get something like that to work
> properly without success.
>
> I believe I now understand that it might have failed because gnuplot
> didn't know what to do with -psn, but I forgot about that completely.
> Thanks for demonstrating how to create an app bundle with Gnuplot.
>
> Weird enough the installer refuses to work on 10.7 (I didn't try to
> diagnose why), but the app works just fine.
>
> (What about creating a dmg rather than pkg?)

OK, good idea. Both Mojca and Thomas have given me evidence that the 
Apple Package Installer program may be more conservative than I 
thought, and may be blocking installation of my pkg file on Macs 
where it should actually run OK. So here's a DMG version:

http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.dmg

The drill to install is: double-click to mount the disk image, then 
drag from Gnuplot to Applications. This bypasses the official 
installer. (Again, though, it's not going to work on anything other 
than 10.6.6 or higher, 64-bit.)

>> I don't suppose it will meet everyone's needs but here are the
>> specs:
>>
>> * It's an x86_64 build, and will run on OS X 10.6.6 and higher.
>>
>> * The gnuplot code is 5.1 (cvs) as of a few weeks ago.
>>
>> * It's self-contained. No dependency on XQuartz. The only libraries
>> it requires from the OS are ones that are a standard part of the OS
>> X kit from Snow Leopard to El Capitan.
>>
>> * Interactive terminals: wxt and aquaterm. Both are built into the
>> bundle; no need for a separate AquaTerm or wxWidgets installation.
>> The included wx is the native quartz version, so no GTK.
>
> Nice.
>
>> Everything was built on Arch Linux using clang and friends.
>
> Do you really want to say that you cross-compiled the binaries for 
> OS X on Linux?

Yes, indeed; clang is very nice that way, helped along by bomutils 
(packaging) and openssl (signing). You need to install the 
appropriate Apple SDK (I'm using 10.6) but that's fairly 
straightforward.

Allin Cottrell

Re: Progress on Mac installation cloning

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

On 4 March 2016 at 19:27, Allin Cottrell wrote:
>
> I thought it might be worth making a
> gnuplot bundle by stripping out all the gretl stuff and revising the
> metadata.
>
> You can find the result at
> http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg

Thanks a lot!

I kept fighting a lot trying to get something like that to work
properly without success.

I believe I now understand that it might have failed because gnuplot
didn't know what to do with -psn, but I forgot about that completely.
Thanks for demonstrating how to create an app bundle with Gnuplot.

Weird enough the installer refuses to work on 10.7 (I didn't try to
diagnose why), but the app works just fine.

(What about creating a dmg rather than pkg?)

> I don't suppose it will meet everyone's needs but here are the
> specs:
>
> * It's an x86_64 build, and will run on OS X 10.6.6 and higher.
>
> * The gnuplot code is 5.1 (cvs) as of a few weeks ago.
>
> * It's self-contained. No dependency on XQuartz. The only libraries
> it requires from the OS are ones that are a standard part of the OS
> X kit from Snow Leopard to El Capitan.
>
> * Interactive terminals: wxt and aquaterm. Both are built into the
> bundle; no need for a separate AquaTerm or wxWidgets installation.
> The included wx is the native quartz version, so no GTK.

Nice.

> Everything was built on Arch Linux using clang and friends.

Do you really want to say that you cross-compiled the binaries for OS
X on Linux?

Mojca

Re: More Mac cloning progress

[<pl...@pi...>]

On 04/03/16 19:43, Thomas Mattison wrote:
> Thanks everyone for all the help and suggestions.  Here's where I am.
>
> Building gnuplot from source on a 10.6.8 Mac with xcode 3.2.6 and
> command line tools produces a working version, but I don't want to require
> students to install xcode or compile from source.
>
> Doing "make DESTDIR=/tmp/gnuplot" produces a tree that can be put onto
> student machines with a simple script that just does a "sudo rsync ..."
> Students also need to install XQuartz, but that's easy enough.
>
> The bare gnuplot doesn't have png, gif, or pdf support.
>
> If my build machine has Aquaterm installed, the gnuplot build has aquaterm support.
> Aquaterm can save screen graphics as pdf files, and that's adequate pdf support for now.
> Students need to install Aquaterm, but that's also easy.
>
> To add png and gif support, I need the gd library.
> The gd library needs freetype and libpng, and libpng needs zlib.
>
> Richard Gonsalves at SUNY Buffalo teaches a Computational Physics course
> and posted instructions on building gnuplot from source with these libraries.
>
> http://www.physics.buffalo.edu/phy410-505/tools/install/
>
> My first attempt was with
> zlib-1.2.8 (rather than 1.2.7)
> libpng-1.6.21 (rather than 1.5.13)
> freetype-2.4.10 (same as instructions)
> libgd-2.1.1 (rather than gd-2.0.33)
>
> These steps ran, but with some errors.
> But the gnuplot build had errors and didn't produce an executable.
>
> So I tried again using libpng-1.5.26, and gd-2.0.33
>
> The zlib, libpng, and freetype builds ran without errors,
> but the gd-2.0.33 build didn't work properly.
>
> My build machine has Python from Anaconda, which has an
> incompatible version of freetype on it.  The gd-build
> was getting confused by that, so I deleted the files in
> question (after zipping the originals so I can restore them).
>
> Then the gd-build seemed to pick up the right freetype,
> and seemed to work OK.
>
> Then I did the gnuplot build, and I have png and gif terminals,
> as well as Aquaterm, X11, and postscript.  That's good enough for now.
>
> The recipe so far is
> zlib-1.2.8
> libpng-1.5.26
> freetype-2.4.10
> gd-2.0.33
> gnuplot-5.0.3
>
>
> I did a "make DESTDIR=/tmp/pkgname install" for zlib, libpng, freetype, gd-2.0.3
> as well as "sudo make install", so I have copies of what they put where.
>
> I know the rsync trick works for cloning gnuplot and and its components.
>
> The next step will be to also use rsync to clone the libraries into /usr/local/lib .
>
> Do I also need to add things to some dynamic library search list on the target machines?
>
> Can I skip the /usr/local/lib/pkgconfig stuff?
>
> Can I skip the /usr/local/include stuff?
>
> Can I skip the /usr/local/bin/XXX-config binaries?
>
> Can I skip the /usr/local/share/man stuff?
>
>
> Thanks again!
>
>


I would avoid moving stuff  /usr/local ,  especially and because of 
libpng. IIRC they change the headers for many of the library calls and 
rendered 1.5.x and 1.6.x totally incompatible. If you get a mix or other 
software build and linked to a different version you will find all sorts 
fo stuff just starts breaking and it will be a major headache.

Advanced package managers on Linux systems tend to take care of this 
kind of thing and ensure all software installed is consistent.  From 
others comments this is clearly not the case on MacOSX.  The LInux 
package managers  manage the dependency hell you are likely to encounter.

I remember the png change-over on my Gentoo box, I had to rebuild half 
the system !!

Fedora 23  currently has at least four different versions of libpng  ! 
  PNG devs really ought to give a bit more thought to how they design 
their interface so that they do not have to keep redefining it in an 
incompatible way with each release. Backwards comparability MATTERS.

Since OSX does not provide that level of version control for you I 
suggest you stick it all in one place and keep it there.  PNG is too 
central to too many different things I don't think you want to get into 
that mess.


Personally, I don't even use png terminal now, despite that being my 
usual image format . It is good but the inconsistencies from what I see 
on the screen made it more work that it was worth: different line 
widths, text extents, line colours ....  It was a headache.  Now I just 
copy to clipboard and paste into gimp to save.

Gimp is a sledgehammer to crack a walnut in that case but it does the 
job. That way I get exactly what I see when I'm working reproduced as a 
png file.

The historical terminal design of gnuplot was quite clever but it has 
some annoying compromises, such as not knowing what size text is going 
to come out and so text areas and positioning are always approximative.


BTW Gimp is good for creating gif animations if that  is something you 
need to do. You do not need to start with a gif since Gimp will take any 
input format. Their paradigm is "export as" then select whatever format 
you want.  If you want to simplify what you need to install / build / 
copy etc. that may be worth considering.

You need one good interactive terminal to do your work, then let a 
graphics package take care of whatever file format you or your students 
need as an end result.

I prefer wxt but qt is probably technically better/faster .  wxt is 
gnomey which is maccy , so this may be closer to your usual environment. 
  QT is windozey.


You said you had problems with cp.  Maybe look at cp -a   option . 
Nothing wrong with rsync though.


Since you don't need all the gnuplot terminals to get all the different 
formats, I'd be incline to reduce the dependency list to a minimum and 
use some gfx software to do the conversions.

That's the was i'd tackle it.

Peter.

Re: Progress on Mac installation cloning

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

On Sat, 5 Mar 2016, Jun T. wrote:

>
> 2016/03/05 03:27, Allin Cottrell <cot...@wf...> wrote:
>> I package the program that I work on, gretl, for OS X and the gretl
>> bundle includes gnuplot, so I thought it might be worth making a
>> gnuplot bundle by stripping out all the gretl stuff and revising the
>> metadata.
>
> Great!
>
>> You can find the result at
>> http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg
>
> Maybe http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg ?
>
> ... I've just got your next post which corrects the url.
>
>> * After installation, you can launch gnuplot via its icon in
>> Applications; this opens an instance of Terminal with gnuplot
>> running in it.
>
> This doesn't happen (OS X 10.9.5), but

Hmm. Clicking on the gnuplot icon in Applications should be about
equivalent to executing

/Applications/Gnuplot.app/Contents/MacOS/gnuplot.sh

from the command line. If you have time, could you try that and see 
what's going wrong? Utilities/Console might also have something 
relevant to say.

>> * If you want to run gnuplot from the command-line directly, the
>> file to execute is
>>
>> /Applications/Gnuplot.app/Contents/Resources/bin/gnuplot-run.sh
>
> this does works.
> I've tested only aqua, wxt and pngcairo for a few plots, but guess
> other terminals works as well.

Thanks for testing. Good to hear that at least those things work.

Allin Cottrell

More Mac cloning progress

[Thomas M. <mat...@ph...>]

Thanks everyone for all the help and suggestions.  Here's where I am.

Building gnuplot from source on a 10.6.8 Mac with xcode 3.2.6 and 
command line tools produces a working version, but I don't want to require 
students to install xcode or compile from source.  

Doing "make DESTDIR=/tmp/gnuplot" produces a tree that can be put onto
student machines with a simple script that just does a "sudo rsync ..."
Students also need to install XQuartz, but that's easy enough.

The bare gnuplot doesn't have png, gif, or pdf support.

If my build machine has Aquaterm installed, the gnuplot build has aquaterm support.  
Aquaterm can save screen graphics as pdf files, and that's adequate pdf support for now.
Students need to install Aquaterm, but that's also easy.

To add png and gif support, I need the gd library.  
The gd library needs freetype and libpng, and libpng needs zlib.

Richard Gonsalves at SUNY Buffalo teaches a Computational Physics course
and posted instructions on building gnuplot from source with these libraries.

http://www.physics.buffalo.edu/phy410-505/tools/install/

My first attempt was with 
zlib-1.2.8 (rather than 1.2.7)
libpng-1.6.21 (rather than 1.5.13)
freetype-2.4.10 (same as instructions)
libgd-2.1.1 (rather than gd-2.0.33)

These steps ran, but with some errors.
But the gnuplot build had errors and didn't produce an executable.

So I tried again using libpng-1.5.26, and gd-2.0.33

The zlib, libpng, and freetype builds ran without errors,
but the gd-2.0.33 build didn't work properly.

My build machine has Python from Anaconda, which has an
incompatible version of freetype on it.  The gd-build
was getting confused by that, so I deleted the files in
question (after zipping the originals so I can restore them).

Then the gd-build seemed to pick up the right freetype,
and seemed to work OK.

Then I did the gnuplot build, and I have png and gif terminals,
as well as Aquaterm, X11, and postscript.  That's good enough for now.

The recipe so far is
zlib-1.2.8
libpng-1.5.26
freetype-2.4.10
gd-2.0.33
gnuplot-5.0.3


I did a "make DESTDIR=/tmp/pkgname install" for zlib, libpng, freetype, gd-2.0.3
as well as "sudo make install", so I have copies of what they put where.

I know the rsync trick works for cloning gnuplot and and its components.

The next step will be to also use rsync to clone the libraries into /usr/local/lib .

Do I also need to add things to some dynamic library search list on the target machines?

Can I skip the /usr/local/lib/pkgconfig stuff?

Can I skip the /usr/local/include stuff?

Can I skip the /usr/local/bin/XXX-config binaries?

Can I skip the /usr/local/share/man stuff?


Thanks again!



                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324

Re: Progress on Mac installation cloning

[Jun T. <tak...@kb...>]

2016/03/05 03:27, Allin Cottrell <cot...@wf...> wrote:
> I package the program that I work on, gretl, for OS X and the gretl 
> bundle includes gnuplot, so I thought it might be worth making a 
> gnuplot bundle by stripping out all the gretl stuff and revising the 
> metadata.

Great!

> You can find the result at 
> http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg

Maybe http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg ?

... I've just got your next post which corrects the url.

> * After installation, you can launch gnuplot via its icon in 
> Applications; this opens an instance of Terminal with gnuplot 
> running in it.

This doesn't happen (OS X 10.9.5), but

> * If you want to run gnuplot from the command-line directly, the 
> file to execute is
> 
> /Applications/Gnuplot.app/Contents/Resources/bin/gnuplot-run.sh

this does works.
I've tested only aqua, wxt and pngcairo for a few plots, but guess
other terminals works as well.

Re: Progress on Mac installation cloning

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

On Fri, 4 Mar 2016, Allin Cottrell wrote:

> I package the program that I work on, gretl, for OS X and the gretl bundle 
> includes gnuplot, so I thought it might be worth making a gnuplot bundle by 
> stripping out all the gretl stuff and revising the metadata.
>
> You can find the result at 
> http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg

Sorry! That should be

http://ricardo.ecn.wfu.edu/pub/gretl/gnuplot-quartz.pkg

Allin Cottrell

Re: Progress on Mac installation cloning

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

On Thu, 3 Mar 2016, Thomas Mattison wrote:
>
> The goal is to make it easy for a non-computer-science student to 
> install gnuplot on a reasonably modern Mac. [...]

I package the program that I work on, gretl, for OS X and the gretl 
bundle includes gnuplot, so I thought it might be worth making a 
gnuplot bundle by stripping out all the gretl stuff and revising the 
metadata.

You can find the result at 
http://ricardo.ecn.wfu.edu/pub/gretl/gretl-quartz.pkg

I don't suppose it will meet everyone's needs but here are the 
specs:

* It's an x86_64 build, and will run on OS X 10.6.6 and higher.

* The gnuplot code is 5.1 (cvs) as of a few weeks ago.

* It's self-contained. No dependency on XQuartz. The only libraries 
it requires from the OS are ones that are a standard part of the OS 
X kit from Snow Leopard to El Capitan.

* Interactive terminals: wxt and aquaterm. Both are built into the 
bundle; no need for a separate AquaTerm or wxWidgets installation. 
The included wx is the native quartz version, so no GTK.

* All pango/cairo terminals included: pngcairo, pdfcairo, epscairo. 
No Qt, no caca, no nonsense ;-)

* The installed size is about 22 MB, most of that made up by the 
glib/pango/cairo stack and the wxWidgets libraries.

* To install, double-click on the pkg file. It's signed, so 
GateKeeper shouldn't make a fuss. Installs into 
/Applications/Gnuplot.app.

* After installation, you can launch gnuplot via its icon in 
Applications; this opens an instance of Terminal with gnuplot 
running in it.

* If you want to run gnuplot from the command-line directly, the 
file to execute is

/Applications/Gnuplot.app/Contents/Resources/bin/gnuplot-run.sh

This is a shell script which sets up the environment then calls the 
gnuplot binary. One could of course set up a shell alias.

Everything was built on Arch Linux using clang and friends.

Allin Cottrell

Re: Mac installation cloning

[Jun T. <tak...@kb...>]

On 2016/03/04, at 9:22, Thomas Mattison <mat...@ph...> wrote:

> The main capability lacking from plain vanilla gnuplot built on my 10.6.8 Mac from source is the ability to make png or gif output.

Are you (or your students) going to create many (a series of) png
files? Then you will need "png" or "pngcairo" terminals, but either
of them requires several libraries. For example, "pngcairo" requires
lbpng and pango/cairo, pango requires glib, and cairo requires pixman.

If you will only occasionally create a few png files, then you can
use Aquaterm.app to save the plot in pdf file, and use Preview.app
to convert it to png (or jpeg, tiff, gif; you need to option-click
the format menu to enable gif in the save dialog).
Or you can type cmd-C in Aquaterm to copy the plot to the clipboard,
switch to Preview, and type cmd-N to create a new picture from
the clipboard. Then you can save it as png etc.

Building a "clonable" gnuplot with lots of terminals would be (very)
tedious, if not impossible. How about staring with just "aqua" terminal
and try it for some time to see whether it is enough for your students?

Aquaterm, however, has no mouse/keyboard support. For example, you can
not rotate the 3D plot (splot) by mouse. If this is not acceptable,
then you need either "qt" or "wxt" terminal.
"wxt" requires wxWidgets and pango/cairo and harder to build, but
once pango/cairo is installed then "pngcairo" can also use it.
"qt" terminal requires Qt, but Qt has a standard Mac installer
(all of your student must run the installer by themselves, but the
same applies to the Aquaterm installer).

Re: Error plotting lcdemo.dat

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

Am 04.03.2016 um 05:10 schrieb sfeam:
> On Thursday, 03 March 2016 11:31:38 PM Bastian Märkisch wrote:
>> When trying to plot "lcdemo.dat" using the current CVS version, I do get
>> the following warning:
>>
>> gnuplot> plot "lcdemo.dat"
>>                 ^
>>            warning: Unrecognized 5 column plot style; resetting to
>> boxerrorbars
>>
>> Is that to be expected? Does anybody else see that?
>
> Yeah. Sorry, That was a side-effect of adding "pointtype variable".
> That increased the maximum number of columns relevant to "with points"
> from 4 to 5.  That's fine if the plot command actually consumes all 5
> columns, but if the data file contains more columns than the plot command
> uses, then the extra ones have to be ignored gracefully.
> Fixed now.
>
> 	Ethan
>

Thanks for the quick fix!

   Bastian