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

Re: Units for GPVAL_TERM variables?

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

On Saturday, 13 December 2014 01:16:09 PM Philipp K. Janert wrote:
> 
> I was wondering what the "units" for the GPVAL_TERM
> variables are. GPVAL_TERM_XSIZE, for instance, seems
> to be 20*(horizontal pixel count). What determines the
> multiplier?

There are no units.
These are coordinates in the current terminal's coordinate space.
Depending on how the terminal works, this may or may not map
1-to-1 onto pixels.  And for vector terminals clearly it does not.

	Ethan

Units for GPVAL_TERM variables?

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

I was wondering what the "units" for the GPVAL_TERM
variables are. GPVAL_TERM_XSIZE, for instance, seems
to be 20*(horizontal pixel count). What determines the
multiplier?

Best,

		Ph.

Re: Problems with "set linetype cycle" in gp5 rc3

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

On Wednesday, 10 December 2014 05:25:47 PM Philipp K. Janert wrote:
> > # plot all results and superimpose the standard
> > plot for [i=1,96] result(i),  'standard.dat' lt STANDARD
> 
> But for that application, wouldn't you use
> linestyle (rather than linetype)?
> 
> The big distinction between linestyle and
> linetype that I can see is that linetypes
> are incremented automatically. Everything
> that's manual I can do with linestyles.

To me the most important distinction between linestyles
and linetypes is that linetype definitions are persistent.
You can set up your preferred set of linetypes at the 
beginning of a session and they stay that way.
linestyles are lost on every "reset"

	Ethan

Re: Problems with "set linetype cycle" in gp5 rc3

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

On Wed, 10 Dec 2014 17:09:49 -0800
sfeam <sf...@us...> wrote:

> On Wednesday, 10 December 2014 04:25:27 PM Philipp K. Janert wrote:
> > 
> > > > 
> > > > That strikes me as rather odd behavior. I would
> > > > have expected that "set linetype cycle" takes
> > > > precedence.
> > > 
> > > That would have the effect of disabling all linetypes
> > > higher than the cycle count.  
> > 
> > Isn't that precisely the point of "set linetype cycle"?
> > To cycle through the linetypes with an index less than
> > the cycle-period? 
> 
> Cycle through them in auto-generated plots - yes.
> But not to disable use of manually specified linetypes.
> 
> For example:
> 
> # define a linetype distinct from the normal cycle
> set linetype STANDARD lc black lw 3.0
> 
> # plot all results and superimpose the standard
> plot for [i=1,96] result(i),  'standard.dat' lt STANDARD

But for that application, wouldn't you use
linestyle (rather than linetype)?

The big distinction between linestyle and
linetype that I can see is that linetypes
are incremented automatically. Everything
that's manual I can do with linestyles.

Re: More problems with "set linetype cycle" in gp5 rc3

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

[snip]

> For instance I can use a single plot command to quickly
> screen the response curves from a 96-well experiment.
> To distinguish the "hits" from the "noise", I need at
> least 96 distinct curve types.  By default there are 
> 15 point types and 9 line types.   That's not good for
> this use, because those numbers are not relatively prime.
> They only yield 45 distinct line+point combinations.
> But if I either lower the linetype cycle to 7 or
> raise it to 11 I get 7*15=105 or 11*15=165 distinct
> curve types.

Hm...

> Adding "set pointtype cycle N" and "set dashtype cycle N"
> are on the TODO list, but the details of of how these
> would interact with each other are not fully worked out.
> I've put a patch on SourceForge for testing if you
> would like to try it. It's #708

Ok, that makes sense... as a "part of a whole",
I can see the usefulness much better.

Re: Problems with "set linetype cycle" in gp5 rc3

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

On Wednesday, 10 December 2014 04:25:27 PM Philipp K. Janert wrote:
> 
> > > 
> > > That strikes me as rather odd behavior. I would
> > > have expected that "set linetype cycle" takes
> > > precedence.
> > 
> > That would have the effect of disabling all linetypes
> > higher than the cycle count.  
> 
> Isn't that precisely the point of "set linetype cycle"?
> To cycle through the linetypes with an index less than
> the cycle-period? 

Cycle through them in auto-generated plots - yes.
But not to disable use of manually specified linetypes.

For example:

# define a linetype distinct from the normal cycle
set linetype STANDARD lc black lw 3.0

# plot all results and superimpose the standard
plot for [i=1,96] result(i),  'standard.dat' lt STANDARD

	Ethan

Re: More problems with "set linetype cycle" in gp5 rc3

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

On Wednesday, 10 December 2014 04:15:23 PM Philipp K. Janert wrote:
> 
> One more thing: set linetype cycle applies only
> to line properties (color and width), but not to
> point properties. That's too bad. 
> 
> Let's say I only want to use two symbols (filled 
> and empty circles, say). Then I can't use the 
> "set linetype" facility to achieve this - I need 
> to set the pointtype (or linestyle) explicitly 
> for each data set in my plot command, right?
> 
> At this point I wonder how useful "set linetype cycle"
> really is. Is there a deep reason to limit its
> effect to line properties only?

Yes. 

I showed you one such reason a couple of weeks back.
If you pick linetype and pointtype cycles that are
relative primes, then the number of distinguishable
plots "with linespoints" is equal to their product.

For instance I can use a single plot command to quickly
screen the response curves from a 96-well experiment.
To distinguish the "hits" from the "noise", I need at
least 96 distinct curve types.  By default there are 
15 point types and 9 line types.   That's not good for
this use, because those numbers are not relatively prime.
They only yield 45 distinct line+point combinations.
But if I either lower the linetype cycle to 7 or
raise it to 11 I get 7*15=105 or 11*15=165 distinct
curve types.

Adding "set pointtype cycle N" and "set dashtype cycle N"
are on the TODO list, but the details of of how these
would interact with each other are not fully worked out.
I've put a patch on SourceForge for testing if you
would like to try it. It's #708


	Ethan

Re: Problems with "set linetype cycle" in gp5 rc3

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

> > 
> > That strikes me as rather odd behavior. I would
> > have expected that "set linetype cycle" takes
> > precedence.
> 
> That would have the effect of disabling all linetypes
> higher than the cycle count.  

Isn't that precisely the point of "set linetype cycle"?
To cycle through the linetypes with an index less than
the cycle-period? 

(Apparently I don't understand the purpose of this 
feature.)

Re: Problems with "set linetype cycle" in gp5 rc3

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

On Wednesday, 10 December 2014 04:00:06 PM Philipp K. Janert wrote:
> 
> Consider the following commands:
> 
> 	set linetype 1 lw 1 lc rgb "red"
> 	set linetype 2 lw 2 lc rgb "black"
> 	set linetype cycle 2
> 
> I expected alternating thin red and thick black
> curves. But that's not what happens...
> 
> A command like:
> 	plot sin(x), cos(x), airy(x), 1/(x**2+1), -exp(-x**2)
> 
> plots the first and second curve as expected,
> but then falls back to predefined line types,
> until line type 8.
> 
> Only beginning with linetype 9 and 10 do I see
> the alternating red/black lines. (This can be
> clearly seen when running the "test" command.)
> 
> I first thought this was a bug, but then I saw
> a line in the documentation: 
> 
>   If the line properties of a higher numbered 
>   linetype are explicitly defined, this takes
>   precedence over the recycled low-number 
>   linetype properties.
> 
> So, I need to precede everything with
> 
> 	unset for [i=1:10] linetype i
> 
> to remove the default line types.
> 
> That strikes me as rather odd behavior. I would
> have expected that "set linetype cycle" takes
> precedence.

That would have the effect of disabling all linetypes
higher than the cycle count.  

More problems with "set linetype cycle" in gp5 rc3

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

One more thing: set linetype cycle applies only
to line properties (color and width), but not to
point properties. That's too bad. 

Let's say I only want to use two symbols (filled 
and empty circles, say). Then I can't use the 
"set linetype" facility to achieve this - I need 
to set the pointtype (or linestyle) explicitly 
for each data set in my plot command, right?

At this point I wonder how useful "set linetype cycle"
really is. Is there a deep reason to limit its
effect to line properties only?

Best,

		Ph.

Problems with "set linetype cycle" in gp5 rc3

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

Consider the following commands:

	set linetype 1 lw 1 lc rgb "red"
	set linetype 2 lw 2 lc rgb "black"
	set linetype cycle 2

I expected alternating thin red and thick black
curves. But that's not what happens...

A command like:
	plot sin(x), cos(x), airy(x), 1/(x**2+1), -exp(-x**2)

plots the first and second curve as expected,
but then falls back to predefined line types,
until line type 8.

Only beginning with linetype 9 and 10 do I see
the alternating red/black lines. (This can be
clearly seen when running the "test" command.)

I first thought this was a bug, but then I saw
a line in the documentation: 

  If the line properties of a higher numbered 
  linetype are explicitly defined, this takes
  precedence over the recycled low-number 
  linetype properties.

So, I need to precede everything with

	unset for [i=1:10] linetype i

to remove the default line types.

That strikes me as rather odd behavior. I would
have expected that "set linetype cycle" takes
precedence.

Best,

		Ph.

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

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: 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

Re: Persistent confusion about gnuplot -persist

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

Am 08.12.2014 um 07:03 schrieb sfeam:
> On Wednesday, 24 September 2014 03:54:10 PM Tatsuro MATSUOKA wrote:
>>>
>>> In command.c
>>>
>>>
>>> line around 455 => 1455
>>> #=====================================================================
>>>
>>> #if defined(_Windows)
>>> # ifdef WXWIDGETS
>>> if (!strcmp(term->name, "wxt")) {
>>>     /* copy of the code below:  !(_Windows || OS2) */
>>>     if (term && term->waitforinput && paused_for_mouse){
>>> fprintf(stderr, "%s\n", buf);
>>> term->waitforinput(0);
>>>     } else {
>>> #  if defined(WGP_CONSOLE)
>>> fprintf(stderr, "%s\n", buf);
>>> if (term && term->waitforinput)
>>>     while (term->waitforinput(0) != (int)'\r') {}; /* waiting for
>>> Enter*/
>>> #  else /* !WGP_CONSOLE */
>>> if (!Pause(buf))
>>>     bail_to_command_line();
>>> #  endif
>>>     }
>>> } else
>>> # endif /* _Windows && WXWIDGETS */
>>>
>>> #=====================================================================
>>>
>>>
>>> For qt, are similar treatments required?
>
> Sorry, I lost track of this question.
> I think you are right that qt needs the same treatment.
> Please try this patch (in-line and also attached):
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot/src/command.c	2014-09-14 11:21:12.000000000 -0700
> +++ gnuplot-cvs/src/command.c	2014-12-07 21:58:07.958118580 -0800
> @@ -1453,8 +1453,8 @@ pause_command()
>
>       if (sleep_time < 0) {
>   #if defined(_Windows)
> -# ifdef WXWIDGETS
> -	if (!strcmp(term->name, "wxt")) {
> +# if defined(WXWIDGETS) || defined(QTTERM)
> +	if (!strcmp(term->name, "wxt") || !strcmp(term->name, "qt")) {
>   	    /* copy of the code below:  !(_Windows || OS2) */
>   	    if (term && term->waitforinput && paused_for_mouse){
>   		fprintf(stderr, "%s\n", buf);
> @@ -1470,7 +1470,7 @@ pause_command()
>   #  endif
>   	    }
>   	} else
> -# endif /* _Windows && WXWIDGETS */
> +# endif /* _Windows && WXWIDGETS or QTTERM */
>   	{
>   # ifdef USE_MOUSE
>   	    if (paused_for_mouse && !GraphHasWindow(graphwin)) {
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>
> 	Ethan
>
>

Please also set the tracker item
https://sourceforge.net/p/gnuplot/bugs/1502/
which includes a patch.

    Bastian

Re: Persistent confusion about gnuplot -persist

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

On Wednesday, 24 September 2014 03:54:10 PM Tatsuro MATSUOKA wrote:
> > 
> > In command.c
> > 
> > 
> > line around 455 => 1455
> > #=====================================================================
> > 
> > #if defined(_Windows)
> > # ifdef WXWIDGETS
> > if (!strcmp(term->name, "wxt")) {
> >    /* copy of the code below:  !(_Windows || OS2) */
> >    if (term && term->waitforinput && paused_for_mouse){
> > fprintf(stderr, "%s\n", buf);
> > term->waitforinput(0);
> >    } else {
> > #  if defined(WGP_CONSOLE)
> > fprintf(stderr, "%s\n", buf);
> > if (term && term->waitforinput)
> >    while (term->waitforinput(0) != (int)'\r') {}; /* waiting for 
> > Enter*/
> > #  else /* !WGP_CONSOLE */
> > if (!Pause(buf))
> >    bail_to_command_line();
> > #  endif
> >    }
> > } else
> > # endif /* _Windows && WXWIDGETS */
> > 
> > #=====================================================================
> > 
> > 
> > For qt, are similar treatments required?

Sorry, I lost track of this question.
I think you are right that qt needs the same treatment.
Please try this patch (in-line and also attached):

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/command.c	2014-09-14 11:21:12.000000000 -0700
+++ gnuplot-cvs/src/command.c	2014-12-07 21:58:07.958118580 -0800
@@ -1453,8 +1453,8 @@ pause_command()
 
     if (sleep_time < 0) {
 #if defined(_Windows)
-# ifdef WXWIDGETS
-	if (!strcmp(term->name, "wxt")) {
+# if defined(WXWIDGETS) || defined(QTTERM)
+	if (!strcmp(term->name, "wxt") || !strcmp(term->name, "qt")) {
 	    /* copy of the code below:  !(_Windows || OS2) */
 	    if (term && term->waitforinput && paused_for_mouse){
 		fprintf(stderr, "%s\n", buf);
@@ -1470,7 +1470,7 @@ pause_command()
 #  endif
 	    }
 	} else
-# endif /* _Windows && WXWIDGETS */
+# endif /* _Windows && WXWIDGETS or QTTERM */
 	{
 # ifdef USE_MOUSE
 	    if (paused_for_mouse && !GraphHasWindow(graphwin)) {
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


	Ethan

Re: Alpha blending details?

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

On Sat, 06 Dec 2014 22:22:38 -0800
sfeam <sf...@us...> wrote:

> On Saturday, 06 December 2014 08:40:19 AM Philipp K. Janert wrote:
> > 
> > What blending mode or operator does gnuplot
> > use for alpha blending?
> > 
> > According to this page, there are many possible
> > choices:
> > 	http://cairographics.org/operators/
> > 
> > Based on some tests, possible options seem to be 
> > OPERATOR_OVER, OPERATOR_ADD, and OPERATOR_SATURATE.
> > 
> > Does anyone know?
> 
> Polygons are drawn with
> cairo_set_operator(context,CAIRO_OPERATOR_SATURATE);
> 
> I don't see any separate set operation for RGBA lines.  They are
> drawn with cairo_set_source_rgba() but I do not know if that means
> they end up using the default operator (OVER) or whether the SATURATE
> operator carries over from some previous fill_polygon() operation, if
> any.

Thanks!

	Ph.

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

[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

[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

[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: Alpha blending details?

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

On Saturday, 06 December 2014 08:40:19 AM Philipp K. Janert wrote:
> 
> What blending mode or operator does gnuplot
> use for alpha blending?
> 
> According to this page, there are many possible
> choices:
> 	http://cairographics.org/operators/
> 
> Based on some tests, possible options seem to be 
> OPERATOR_OVER, OPERATOR_ADD, and OPERATOR_SATURATE.
> 
> Does anyone know?

Polygons are drawn with cairo_set_operator(context,CAIRO_OPERATOR_SATURATE);

I don't see any separate set operation for RGBA lines.  They are drawn with
cairo_set_source_rgba() but I do not know if that means they end up
using the default operator (OVER) or whether the SATURATE operator carries
over from some previous fill_polygon() operation, if any.

	Ethan

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

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"