gnuplot-beta

5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

[Jonathan T. <jt...@as...>]

I've just built 5.0-rc3 from the sourceforge tarball on OpenBSD 5.6
(amd64).  There were minor glitches (see below), but overall -r3c seems
to be in good shape (lots of great new features!), and almost ready for
release.

The terminals I normally use (x11 and ps) work fine in my limited tests
so far, as do pbm and pdfcairo.

Glitches:

Glitch 1: INSTALL refers to the configure option  --enable-bitmap-terminals
but the configure script actually wants  -with-bitmap-terminals  (and
complains about  --enable-bitmap-terminals  being unrecognized).

Glitch 2. The configure script reports some problems with the 'missing'
script:

--- begin start of build transcript ---
Script started on Sat Dec  6 19:39:01 2014
% uname -a
OpenBSD cobalt.astro.indiana.edu 5.6 GENERIC.MP#0 amd64
% /usr/bin/gcc --version
gcc (GCC) 4.2.1 20070719
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% /usr/bin/g++ --version
g++ (GCC) 4.2.1 20070719
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% gmake --version
GNU Make 4.0
Built for x86_64-unknown-openbsd5.6
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
% ./configure --prefix /usr/local/ --disable-history-file --with-readline=gnu --with-bitmap-terminals --without-pdf --without-lua --with-qt CC=/usr/bin/gcc CXX=/usr/bin/g++ LIBS=-lm
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/usr/local/src/gnuplot/gnuplot-5.0.rc3/missing: Unknown `--is-lightweight' option
Try `/usr/local/src/gnuplot/gnuplot-5.0.rc3/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
[[...]]
--- end start of build transcript ---

The other glitches I found were (I suspect) OpenBSD-specific.  Notably,
the wxt terminal compiled and linked ok, but core-dumps at the first
'plot' command -- here's a stack traceback:

(gdb) bt
#0  0x00001e14021cf83a in kill () at <stdin>:2
#1  0x00001e1402231889 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
#2  0x00001e1454e68205 in _rthread_mutex_lock (mutexp=0x1e13fcb446d0, 
    trywait=0, abstime=0x0) at /usr/src/lib/librthread/rthread_sync.c:127
#3  0x00001e13d696eba9 in wxMutexInternal::Lock ()
   from /usr/local/lib/libwx_base.so.3.0
#4  0x00001e11ad34ae2a in wxt_init () at wxterminal/wxt_gui.cpp:1841
#5  0x00001e11ad30dafa in term_initialise () at term.c:486
#6  0x00001e11ad281026 in do_plot (plots=0x1e141c44fc00, pcount=1)
    at graphics.c:523
#7  0x00001e11ad2a631b in plotrequest () at plot2d.c:3356
#8  0x00001e11ad2543b0 in do_line () at command.c:614
#9  0x00001e11ad255023 in com_line () at command.c:321
#10 0x00001e11ad29e4bb in main (argc=0, argv=0x7f7fffff0c48) at plot.c:659
Current language:  auto; currently asm
(gdb)

  I haven't investigated this problem further.

ciao,

-- 
-- Jonathan Thornburg <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

[sfeam <sf...@us...>]

On Saturday, 06 December 2014 09:22:12 PM Jonathan Thornburg wrote:
> I've just built 5.0-rc3 from the sourceforge tarball on OpenBSD 5.6
> (amd64).  There were minor glitches (see below), but overall -r3c seems
> to be in good shape (lots of great new features!), and almost ready for
> release.
> 
> The terminals I normally use (x11 and ps) work fine in my limited tests
> so far, as do pbm and pdfcairo.
> 
> Glitches:
> 
> Glitch 1: INSTALL refers to the configure option  --enable-bitmap-terminals
> but the configure script actually wants  -with-bitmap-terminals  (and
> complains about  --enable-bitmap-terminals  being unrecognized).

Oops.  Will fix.  Thanks for the report.

> Glitch 2. The configure script reports some problems with the 'missing'
> script:
> 
> --- begin start of build transcript ---
> Script started on Sat Dec  6 19:39:01 2014
> % uname -a
> OpenBSD cobalt.astro.indiana.edu 5.6 GENERIC.MP#0 amd64
> % /usr/bin/gcc --version
> gcc (GCC) 4.2.1 20070719
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> % /usr/bin/g++ --version
> g++ (GCC) 4.2.1 20070719
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> % gmake --version
> GNU Make 4.0
> Built for x86_64-unknown-openbsd5.6
> Copyright (C) 1988-2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> % ./configure --prefix /usr/local/ --disable-history-file --with-readline=gnu --with-bitmap-terminals --without-pdf --without-lua --with-qt CC=/usr/bin/gcc CXX=/usr/bin/g++ LIBS=-lm
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> /usr/local/src/gnuplot/gnuplot-5.0.rc3/missing: Unknown `--is-lightweight' option
> Try `/usr/local/src/gnuplot/gnuplot-5.0.rc3/missing --help' for more information
> configure: WARNING: 'missing' script is too old or missing
> checking for a thread-safe mkdir -p... ./install-sh -c -d
> checking for gawk... gawk
> [[...]]
> --- end start of build transcript ---

So far as I know this message is annoying but harmless.
It has something to do with version mismatch of the "automake" tool.  
What version of automake do you have?
This line in the Makefile
	AUTOMAKE_OPTIONS = foreign
used to suppress the warning but maybe this is no longer sufficient.

I can look into replacing the "missing" script with a newer version,
but I hate making such a change this late in the release process.
On the other hand, I think the script is only relevant to the packaging
process itself, not to simply building or installing the program.
So even if a last-minute replacement fails on some systems, it may
affect only developers, not end users.

> The other glitches I found were (I suspect) OpenBSD-specific.  Notably,
> the wxt terminal compiled and linked ok, but core-dumps at the first
> 'plot' command -- here's a stack traceback:
> 
> (gdb) bt
> #0  0x00001e14021cf83a in kill () at <stdin>:2
> #1  0x00001e1402231889 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
> #2  0x00001e1454e68205 in _rthread_mutex_lock (mutexp=0x1e13fcb446d0, 
>     trywait=0, abstime=0x0) at /usr/src/lib/librthread/rthread_sync.c:127
> #3  0x00001e13d696eba9 in wxMutexInternal::Lock ()
>    from /usr/local/lib/libwx_base.so.3.0
                            ^^^^^^^^^^^^^^^

Unfortunately wxt 3.0 does not work with gnuplot.
(I'm sure they would claim that is better said "gnuplot does not
work with wxt 3.0" ;-)   

No fix is known and I am not aware of anyone working on it.
It may not be fixable in general, although a couple of people have reported
that
	./configure   --with-wx-single-threaded
allows it to run correctly even though it prints alarming error messages.
For me that configuration option doesn't make any apparent difference.

This problem has already hit gnuplot packaging on both OSX and Debian,
both of which have switched to the newer wxt and not made adequate provision
for programs that require the older version 2.8.  Sad, really.
The only work-around I can recommend at this point is to use the qt terminal
instead.

	Ethan

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

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

Am 07.12.2014 um 05:54 schrieb sfeam:
> On Saturday, 06 December 2014 09:22:12 PM Jonathan Thornburg wrote:

>> configure: WARNING: 'missing' script is too old or missing

> So far as I know this message is annoying but harmless.
> It has something to do with version mismatch of the "automake" tool.

Indeed.  If aclocal.m4 was built by automake-1.13 or newer, but the 
'missing' script is older, you get this warning from the generated 
'configure' script.

FWIW, I have updates of the auto toolage to automake-1.14 / 
autoconf-2.69 sitting here, as mentioned previously in another thread. 
They seem to work fine.

> I can look into replacing the "missing" script with a newer version,
> but I hate making such a change this late in the release process.

I agree that auto tools changes should not go into the 5.0 branch just 
now. But they might be worth putting into HEAD.

> On the other hand, I think the script is only relevant to the packaging
> process itself, not to simply building or installing the program.
> So even if a last-minute replacement fails on some systems, it may
> affect only developers, not end users.
>
>> The other glitches I found were (I suspect) OpenBSD-specific.  Notably,
>> the wxt terminal compiled and linked ok, but core-dumps at the first
>> 'plot' command -- here's a stack traceback:
>>
>> (gdb) bt
>> #0  0x00001e14021cf83a in kill () at <stdin>:2
>> #1  0x00001e1402231889 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
>> #2  0x00001e1454e68205 in _rthread_mutex_lock (mutexp=0x1e13fcb446d0,
>>      trywait=0, abstime=0x0) at /usr/src/lib/librthread/rthread_sync.c:127
>> #3  0x00001e13d696eba9 in wxMutexInternal::Lock ()
>>     from /usr/local/lib/libwx_base.so.3.0
>                              ^^^^^^^^^^^^^^^
>
> Unfortunately wxt 3.0 does not work with gnuplot.
> (I'm sure they would claim that is better said "gnuplot does not
> work with wxt 3.0" ;-)
>
> No fix is known and I am not aware of anyone working on it.
> It may not be fixable in general, although a couple of people have reported
> that
> 	./configure   --with-wx-single-threaded
> allows it to run correctly even though it prints alarming error messages.
> For me that configuration option doesn't make any apparent difference.
>
> This problem has already hit gnuplot packaging on both OSX and Debian,
> both of which have switched to the newer wxt and not made adequate provision
> for programs that require the older version 2.8.  Sad, really.
> The only work-around I can recommend at this point is to use the qt terminal
> instead.

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

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

> Unfortunately wxt 3.0 does not work with gnuplot.
> (I'm sure they would claim that is better said "gnuplot does not
> work with wxt 3.0" ;-)
>
> No fix is known and I am not aware of anyone working on it.
> It may not be fixable in general, although a couple of people have reported
> that
>         ./configure   --with-wx-single-threaded
> allows it to run correctly even though it prints alarming error messages.
> For me that configuration option doesn't make any apparent difference.
>
> This problem has already hit gnuplot packaging on both OSX and Debian,
> both of which have switched to the newer wxt and not made adequate provision
> for programs that require the older version 2.8.  Sad, really.
> The only work-around I can recommend at this point is to use the qt terminal
> instead.

Just to make it clear:

- gnuplot + wxWidgets 3.0 works fine for me on OS X; it has worked ok
for a long time already, so saying that "wxt 3.0 doesn't work with
gnuplot" is not entirely correct. There might be problems on linux,
but it has worked fine on OS X long before anyone tested it on linux.
(There might be special cases that fail to work, but in general it
works.)

- I believe there are still issues with gnuplot + Qt 5 on OS X, but I
don't remember the details (I don't use Qt 5 on regular basis yet).

- wxWidgets 2.8 cannot be compiled for x86_64-darwin and it cannot be
compiled on OS X 10.7 or later; Apple dropped a library that wxWidgets
relied on and wxWidgets developers are not interested in fixing
version 2.8. But if someone would compile gnuplot against wxWidgets
2.8 on Mac OS X 10.6 for i386, that version would work. A number of
applications are distributed that way, but gnuplot is a bit difficult
to distribute in a binary form on Mac. (The problem is that someone
would need to invest a non-trivial amount of work to make gnuplot
Mac-friendly as a standalone app. I tend to believe that most mac
users "compile" gnuplot from source via their package managers.)

Specifically about:

> both of which have switched to the newer wxt and not made adequate provision
> for programs that require the older version 2.8.  Sad, really.

OS X didn't "switch" to anything, OS X doesn't ship with any version
of wxWidgets. wxWidgets 2.8 depended on an ancient library that was
abandoned by Apple at some point. That's the whole story. (Besides
wxWidgets lacking sufficient developers to keep up with changes in OS
X.)

The "sad" part would be gnuplot not being fixed to start working with
wxWidgets 3.0 properly. (I don't have problems with 3.0 though.)

Nobody will convince Apple to rewrite parts of Carbon to start working
with x86_64. And nobody will convince the wxWidgets developers to port
wxWidgets 2.8 to Cocoa. The only proper and future-proof solution
would be to have fully working support for wxWidgets 3.0 (and
wxWidgets 3.1/3.2) in gnuplot.

Another very nice thing that would often help alleviate these kind of
issues would be to start distributing gnuplot for Mac in a binary
form. But that requires extra work.

One can in principle compile gnuplot against wxGTK 2.8 on Mac. But
that's not something that users would want to use.

Mojca

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

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

On Sun, 7 Dec 2014, Mojca Miklavec wrote:

> OS X didn't "switch" to anything, OS X doesn't ship with any version
> of wxWidgets. wxWidgets 2.8 depended on an ancient library that was
> abandoned by Apple at some point. [...]
>
> Nobody will convince Apple to rewrite parts of Carbon to start working
> with x86_64. And nobody will convince the wxWidgets developers to port
> wxWidgets 2.8 to Cocoa.

You imply that there's an old ("Carbon") 32-bit library upon which 
wxWidgets 2.8 depends on the Mac. Could you tell us what library 
that is? This information might be helpful.

(My own view is that having gnuplot depend on wxWidgets is somewhat 
problematic. wxWidgets is a sort of "wrapper" which supposedly 
provides a degree of platform independence, but this seems to be 
fragile and I think it would be better to depend on GTK directly.)

Allin Cottrell

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

[sfeam <sf...@us...>]

On Sunday, 07 December 2014 06:43:07 PM Allin Cottrell wrote:

> (My own view is that having gnuplot depend on wxWidgets is somewhat 
> problematic. wxWidgets is a sort of "wrapper" which supposedly 
> provides a degree of platform independence, but this seems to be 
> fragile and I think it would be better to depend on GTK directly.)

Wouldn't that essentially require writing an entirely new graphics 
library that provides the equivalent layer that wx provides now?

It's hard to see how that would ever be worth the amount of work
involved.  And then Mojca would be unhappy because OSX wants the
graphics to go through Cocoa or Carbon, not gtk.

Since Mojca reports that there is no longer a problem on OSX,
I think what we are left with is a non-optimal packaging 
decision specifically by Debian/Ubuntu.
Gnuplot works fine with wxt 2.8, and this library version is still
available in Debian, but they have chosen not to provide a gnuplot
package that uses it.
 
	Ethan

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

[sfeam <sf...@us...>]

On Sunday, 07 December 2014 11:51:57 PM Mojca Miklavec wrote:
> > Unfortunately wxt 3.0 does not work with gnuplot.
> > (I'm sure they would claim that is better said "gnuplot does not
> > work with wxt 3.0" ;-)
> >
> > No fix is known and I am not aware of anyone working on it.
> > It may not be fixable in general, although a couple of people have reported
> > that
> >         ./configure   --with-wx-single-threaded
> > allows it to run correctly even though it prints alarming error messages.
> > For me that configuration option doesn't make any apparent difference.
> >
> > This problem has already hit gnuplot packaging on both OSX and Debian,
> > both of which have switched to the newer wxt and not made adequate provision
> > for programs that require the older version 2.8.  Sad, really.
> > The only work-around I can recommend at this point is to use the qt terminal
> > instead.
> 
> Just to make it clear:
> 
> - gnuplot + wxWidgets 3.0 works fine for me on OS X; it has worked ok
> for a long time already, so saying that "wxt 3.0 doesn't work with
> gnuplot" is not entirely correct. 

That is good to hear. Thanks.
I don't recall hearing from you that things had started working with 
wxt 3.0.   The last Email I have was with regard to wxt 2.9, admittedly
from quite a while back.  You said then:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
From:	Mojca Miklavec <moj...@gm...>
To:	sf...@us...
CC:	gnu...@li...
Date:	01 Aug 2011 09:40
> > Anyhow, I take it the bottom line is that wxWidgets 2.8 does work,
> > but 2.9 does not?
> 
> True. I'm not sure what is wrong with 2.9, but it might also be a bug
> in their code, not just the need to rewrite the program. It would make
> a lot of sense to resolve such bugs before 3.0 is released, but I
> don't know how to create a minimal example to submit a bug report (if
> there is one).
> 
> Mojca
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Which is fine, but then I never heard that 3.0 did indeed fix things.
I will correct the Release Notes accordingly.

> There might be problems on linux,
> but it has worked fine on OS X long before anyone tested it on linux.
> (There might be special cases that fail to work, but in general it
> works.)

Hmm.  But wxt runs single-threaded on OSX, right?
So this may be another case where the single-threaded configuration
option is sufficient fix, except that on OSX this option is selected
automatically.


> The "sad" part would be gnuplot not being fixed to start working with
> wxWidgets 3.0 properly. (I don't have problems with 3.0 though.)

Only if you accept that the problem is fixable on gnuplot's end.
That might be true, but if so no one has yet suggested what exactly 
would need to be changed.  The closest is a suspicion that it has
to do with threading.  As I noted, some people have reported that
limiting gnuplot+wxt to a single thread makes things work better.
But for other people it doesn't.  After that the list of suggestions
is empty.

> Another very nice thing that would often help alleviate these kind of
> issues would be to start distributing gnuplot for Mac in a binary
> form. But that requires extra work.

The Windows binaries on SourceForge are provided by volunteers.
If you have a line on a volunteer to provide Mac binaries...
Anyhow, isn't this exactly what fink, macports, and similar projects
exist for?

> Mojca

	thanks for the update,

		Ethan

Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

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

On Mon, Dec 8, 2014 at 1:11 AM, sfeam wrote:
> On Sunday, 07 December 2014 11:51:57 PM Mojca Miklavec wrote:
>
>> - gnuplot + wxWidgets 3.0 works fine for me on OS X; it has worked ok
>> for a long time already, so saying that "wxt 3.0 doesn't work with
>> gnuplot" is not entirely correct.
>
> That is good to hear. Thanks.
> I don't recall hearing from you that things had started working with
> wxt 3.0.

I confirmed that it worked in
http://sourceforge.net/p/gnuplot/patches/556/ plus a private thank you
note to Adam and you (Tue, Sep 27, 2011). It wasn't the change from
wxWidgets 2.9 to 3.0, but a change is gnuplot's source code that made
it work.

>  The last Email I have was with regard to wxt 2.9, admittedly
> from quite a while back.  You said then:
>
> From:   Mojca Miklavec <moj...@gm...>
> To:     sf...@us...
> CC:     gnu...@li...
> Date:   01 Aug 2011 09:40

The relevant changes and fixes were probably committed with:
    2011-10-09 Adam Strzelecki
    Work around compile issues on 64-bit OSX Lion (wx2.9 Cocoa)

wxWidgets probably started working with:
    2011-07-23 Adam Strzelecki
    On OSX, use single-threaded GUI and event loop
which is when it made sense to raise the isssue about wxWidgets 2.9.

>> There might be problems on linux,
>> but it has worked fine on OS X long before anyone tested it on linux.
>> (There might be special cases that fail to work, but in general it
>> works.)
>
> Hmm.  But wxt runs single-threaded on OSX, right?
> So this may be another case where the single-threaded configuration
> option is sufficient fix, except that on OSX this option is selected
> automatically.

Yes, that might be the case. (I also remember complaints about
"persist" option breaking things.)

>> The "sad" part would be gnuplot not being fixed to start working with
>> wxWidgets 3.0 properly. (I don't have problems with 3.0 though.)
>
> Only if you accept that the problem is fixable on gnuplot's end.
> That might be true, but if so no one has yet suggested what exactly
> would need to be changed.

I don't know that either.

> The closest is a suspicion that it has
> to do with threading.  As I noted, some people have reported that
> limiting gnuplot+wxt to a single thread makes things work better.
> But for other people it doesn't.  After that the list of suggestions
> is empty.
>
>> Another very nice thing that would often help alleviate these kind of
>> issues would be to start distributing gnuplot for Mac in a binary
>> form. But that requires extra work.
>
> The Windows binaries on SourceForge are provided by volunteers.
> If you have a line on a volunteer to provide Mac binaries...
> Anyhow, isn't this exactly what fink, macports, and similar projects
> exist for?

Yes, but ... until MacPorts started to provide binary packages,
installing gnuplot with Qt support meant that one had to compile the
whole Qt from source. And as long as Lion supported compiling 32-bit
wxWidgets 2.8 installing gnuplot with both Qt and wxWidgets meant that
users had to *recompile* the whole Qt to include both 32-bit and
64-bit architectures (universal variant). At the moment Qt 5 cannot be
installed together with Qt 4 and because many packages would fail to
work with Qt 5, Qt 4 is still the default.

Having a standalone app would be nice. Then whoever would package
gnuplot could simply provide Qt 5, any version of wxt or whatever
other libraries. And it would be easy to install for the users. The
reason why this is more complicated than it should be is because
gnuplot isn't working as a "standalone" application, but rather as a
command-line tool. On windows there's a lot of code dedicated to that
part: gnuplot on windows provides its own "terminal/console" (the part
where user enters code, as opposed to providing just the plotting
panel). On other OSes that part is missing. Implementing it in Qt
should be feasible for someone familiar with Qt programming. I'm not
skilled enough to figure out how to implement that part, but I would
gladly volunteer to do the packaging of Gnuplot.app for Mac if such a
tiny gui app existed.

(At the moment the situation is somewhat acceptable. Fink, MacPorts,
HomeBrew do their job, but having a binary download would nonetheless
be nice.)

Mojca

wxt and qt on Mac (Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches)

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

2014/12/08 18:55, Mojca Miklavec <moj...@gm...> wrote:
>  At the moment Qt 5 cannot be
> installed together with Qt 4 and because many packages would fail to
> work with Qt 5, Qt 4 is still the default.

I'm using the official binary installers from qt-project.org, and
I can have both Qt4 and Qt5 simultaneously on my Mac without any
interference (OS X 10.8 and 10.9).

2014/12/08 07:51, Mojca Miklavec <moj...@gm...> wrote:
> - I believe there are still issues with gnuplot + Qt 5 on OS X, but I
> don't remember the details (I don't use Qt 5 on regular basis yet).

gnuplot works "OK" with Qt5 (and Qt4) on my Macs.
(with Qt5, it says 'slow font initialization' before the 1st plot,
but I think it is harmless). 

I've reported (with possible patches) two minor issues
  "Arrow keys not working on qt terminal for Mac OS X"
  "double-click on qt terminal" (this is not restricted to Mac)
Could anyone test my patch?

There may be more minor issues, but I feel gnuplot with Qt4/5 on Mac
is quite usable.

wxt on Mac has a problem with --persist, which I have reported earlier:
http://sourceforge.net/p/gnuplot/mailman/message/32871148/

---
Jun Takimoto

Re: wxt and qt on Mac (Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches)

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

On Mon, Dec 8, 2014 at 4:56 PM, Jun T. wrote:
> 2014/12/08 18:55, Mojca Miklavec wrote:
>>  At the moment Qt 5 cannot be
>> installed together with Qt 4 and because many packages would fail to
>> work with Qt 5, Qt 4 is still the default.
>
> I'm using the official binary installers from qt-project.org, and
> I can have both Qt4 and Qt5 simultaneously on my Mac without any
> interference (OS X 10.8 and 10.9).

The sentence about simultaneous installation of Qt 4 and Qt 5 was
referring to MacPorts, mentioned earlier in the paragraph
(http://trac.macports.org/ticket/44193). I'm sorry, I just wasn't
clear enough when I wrote that.

Sure, both Qt versions can easily be installed side-by-side outside of
the package manager, but then users need to compile gnuplot manually.
(I didn't check how Fink and HomeBrew deal with packaging.)

In any case the situation with gnuplot + wxt and qt on Mac is a lot
better than it used to be a few years ago.

Mojca