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

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Also, an observation--which isn't specifically clarified in "set xrange" documentation--is that currently (tilde means congruence, for lack of better term):

"set zrange [20:-20]" ~ "set zrange [-20:20] reverse" ~ "set zrange [20:-20] reverse"

I assume that is the way it is supposed to be (i.e., double reverse means reverse... as in Spanish, double negative is still negative).  An alternate would be

"set zrange [-20:20]" ~ "set zrange [20:-20] reverse"

Dan

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I can disallow that...  Other things to note about "ticslevel":  There=
=20
>> hasn't been a bug report for the bad behavior of the z-axis line so=20
>> that might mean it isn't used too often. =20
>=20
>=20
> It might equally well mean that other users don't consider it all that=20
> buggy.  Reading minds of people you don't even know exist is not really=
=20
> possibly.
>=20
>> "unset xyplane", wouldn't we expect that to remove the xyplane
>=20
>  > altogether?
>=20
> No.  I would expect that to be refused by the parser, given that it's=20
> not listed in 'help xyplane'.  Whatever 'unset xyplane' does besides=20
> causing an error message, is an undocumented feature, i.e. a bug.
>=20
>  > For example "unset xtics" removes the xtics.
>=20
> And is documented to do so.

I will disallow "unset xyplane" for now in the patch, unless you think "u=
nset xyplane" should be documentated instead.


>> What may have been nice from the start would be to force=20
>> set/show/reset to come as a structure with three functions.  (Or maybe=
=20
>> four, set/unset/show/reset.) =20
>=20
>=20
> Absolutely, except that there should actually be five, but they should=20
> be 'reset/set/unset/show/save').  If I had the time to do it these days=
,=20
> I would have.  If you want to try that, you have all my blessings.

Maybe post 4.2.  That change will be fairly easy (because the compiler wi=
ll complain about any problem with structure entries), but it is sort of =
a destablizing change for a while.  (Plus a patch like that could only go=
 a couple days without hunks being rejected.)

So, that would get rid of all the S_TICLEVELS, S_XAXIS, etc. (which will =
be nice).  The struct would be something like

{
"xyp$lane",
reset_xyplane,
set_xyplane,
unset_xyplane,
show_xyplane,
save_xyplane
};

And then maybe a short little routine to dump the string of set options, =
not exceeding 80 chars, to remove having to manually plut the option name=
 in that text string.

Dan

Re: z_floor and z_ceiling (was Re: various observations)

[<br...@ph...>]

Daniel J Sebald wrote:

> I can disallow that...  Other things to note about "ticslevel":  There 
> hasn't been a bug report for the bad behavior of the z-axis line so that 
> might mean it isn't used too often.  

It might equally well mean that other users don't consider it all that 
buggy.  Reading minds of people you don't even know exist is not really 
possibly.

> "unset xyplane", wouldn't we expect that to remove the xyplane
 > altogether?

No.  I would expect that to be refused by the parser, given that it's 
not listed in 'help xyplane'.  Whatever 'unset xyplane' does besides 
causing an error message, is an undocumented feature, i.e. a bug.

 > For example "unset xtics" removes the xtics.

And is documented to do so.

> What may have been nice from the start would be to force set/show/reset 
> to come as a structure with three functions.  (Or maybe four, 
> set/unset/show/reset.)  

Absolutely, except that there should actually be five, but they should 
be 'reset/set/unset/show/save').  If I had the time to do it these days, 
I would have.  If you want to try that, you have all my blessings.

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Saturday 20 May 2006 04:13 pm, Daniel J Sebald wrote:
> 
>>>you can accomplish the same thing by saying
>>>	set xyplane at func(GPVAL_Z_MIN,GPVAL_Z_MAX)
>>
>>I don't totally follow what "func" does.
> 
>   See below
> 
>>The idea of a relative placement of the xyplane isn't bad.
> 
>   It is not necessary
> 
> 
>>if I want the xyplane 20% below the z-axis I type 0.2 
>>and if I want the xyplane 20% above the z-axis I type -1.2. 
> 
> 
> Ugh.  Too confusing.  I'd rather do:
> 
>   set xyplane at GPVAL_Z_MAX + 1.2*(GPVAL_Z_MIN - GPVAL_Z_MAX)
>   set xyplane at GPVAL_Z_MIN + 1.2*(GPVAL_Z_MAN - GPVAL_Z_MIN)

A value of 0 gets us (GPVAL_Z_MAX + GPVAL_Z_MIN)/2, i.e., half way between.  A value of 1 gets us either GPVALE_Z_MIN or GPVAL_Z_MAX.

OK, I think that is sort of in the -1:0:1 (bottom:middle:top) category.  Well, the agreement is that 0 feels like a natural value for the xyplane to land at the center of the z-axis.

You'd rather have the user spell out the formula using "at" as opposed to just giving a number?  That's what you're saying, right?

Dan

Re: z_floor and z_ceiling (was Re: various observations)

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 20 May 2006 04:13 pm, Daniel J Sebald wrote:
> > you can accomplish the same thing by saying
> > 	set xyplane at func(GPVAL_Z_MIN,GPVAL_Z_MAX)
> 
> I don't totally follow what "func" does.
  See below
> The idea of a relative placement of the xyplane isn't bad.
  It is not necessary

> if I want the xyplane 20% below the z-axis I type 0.2 
> and if I want the xyplane 20% above the z-axis I type -1.2. 

Ugh.  Too confusing.  I'd rather do:

  set xyplane at GPVAL_Z_MAX + 1.2*(GPVAL_Z_MIN - GPVAL_Z_MAX)
  set xyplane at GPVAL_Z_MIN + 1.2*(GPVAL_Z_MAN - GPVAL_Z_MIN)

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Saturday 20 May 2006 01:57 pm, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>I never did understand 'set ticslevel', but whatever it did should
>>>stay that way for backwards compatibility.
>>>
>>>The idea behind 'set xyplane <foo>' is [supposed to be] obvious:
>>>Whatever zrange is, whatever way round the axes are pointing,
>>>yadda yadda,   draw the plane so that it intersects the z axis
>>>at <foo>.
>>
>>'set xyplane *at* <foo>' does as you explain, and that works just as advertised.  
>>
>>The problem is the "percentage of z-axis" form, i.e., 
>>the non "at" form, the form for which the actual values on the z-axis do not matter;
>>rather the user wants the xyplane to be somewhere relative to the z-axis visually.  
> 
> 
> Then let's just get rid of the "no at" form for 'set xyplane'.
> I don't see a need for it.
> 
> With Petr's patch to export GPVAL_Z_MIN and GPVAL_Z_MAX,
> you can accomplish the same thing by saying
> 	set xyplane at func(GPVAL_Z_MIN,GPVAL_Z_MAX)

I don't totally follow what "func" does.  But there may be another problem, one Hans corrected me on something I said in a previous post.  The bottom of the z-axis may not be z_min, if increasing numbers run downward instead of upward.  (That is why I've been making this distinction with "bottom" and "top".)

The idea of a relative placement of the xyplane isn't bad.  It's just that the current ticslevel logic evades me:  if I want the xyplane 20% below the z-axis I type 0.2 and if I want the xyplane 20% above the z-axis I type -1.2.  One can see how that ends up being a trial and error process.  Whereas, I'd think -1.2 for 20% below and 1.2 for 20% above would be easy to comprehend.

Getting rid of the "no at" form of xyplane would be fine too, as a means of not propagating a confusing syntax.  Instead maybe we could use

"set xyplane below 0.2"
"set xyplane above 0.2"

meaning set the xyplane 20% below *z_bottom* or set the xyplane 20% above *z_top*.  To get the xyplane to the center of the z-axis one could type either

"set xyplane below -0.5"
"set xyplane above -0.5"

I don't know if that is very good.  Somehow I like the -1/+1 approach because then to get the xyplane at the center of the z-axis one just types

"set xyplane 0"

It's all one's frame of reference really.

Dan

Re: z_floor and z_ceiling (was Re: various observations)

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 20 May 2006 01:57 pm, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > I never did understand 'set ticslevel', but whatever it did should
> > stay that way for backwards compatibility.
> > 
> > The idea behind 'set xyplane <foo>' is [supposed to be] obvious:
> > Whatever zrange is, whatever way round the axes are pointing,
> > yadda yadda,   draw the plane so that it intersects the z axis
> > at <foo>.
> 
> 'set xyplane *at* <foo>' does as you explain, and that works just as advertised.  
> 
> The problem is the "percentage of z-axis" form, i.e., 
> the non "at" form, the form for which the actual values on the z-axis do not matter;
> rather the user wants the xyplane to be somewhere relative to the z-axis visually.  

Then let's just get rid of the "no at" form for 'set xyplane'.
I don't see a need for it.

With Petr's patch to export GPVAL_Z_MIN and GPVAL_Z_MAX,
you can accomplish the same thing by saying
	set xyplane at func(GPVAL_Z_MIN,GPVAL_Z_MAX)

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Saturday 20 May 2006 12:01 am, Daniel J Sebald wrote:
> 
>>>OK people, any preference as to xyplane (not 'ticslevel') having bottom 
>>>of zrange as 0 and top of zrange as 1? 
>>
>>That is should top of zrange be 1 or -1 for 'xplane'?
> 
> 
> I was not following this thread, and now that I look back through
> it I don't understand what the issue really is.
> 
> I never did understand 'set ticslevel', but whatever it did should
> stay that way for backwards compatibility.
> 
> The idea behind 'set xyplane <foo>' is [supposed to be] obvious:
> Whatever zrange is, whatever way round the axes are pointing,
> yadda yadda,   draw the place so that it intersects the z axis
> at <foo>.  Have you found some case where this doesn't happen?

But unless you've mis-typed, you have that wrong... and this is an example of the source of confusion.  'set xyplane *at* <foo>' does as you explain, and that works just as advertised.

The problem is the "percentage of z-axis" form, i.e., the non "at" form, the form for which the actual values on the z-axis do not matter; rather the user wants the xyplane to be somewhere relative to the z-axis visually.

Somehow we are trying to make a linear number range represent that concept.  Some logical choices would be

bottom     top
z-axis    z-axis
value     value
------    ------
  0         -1     (current)
  0         +1     (I think more intuitive)
 -1          0     (just as intuitive I guess)
 +1          0     (no)
 -1         +1     (maybe *this* is the most intuitive choice)
 +1         -1     (no way!)

My point in all this is that I have no qualms about someone wanting axis values to be increasing in one direction or the other (I've seen things plotted many ways and for various reasons), but when we step one level back and speak of the axis relatively, the convention is increasing to the right, increasing up I would think.

As it stands, 0/-1 is the way non-at 'xyplane' is going to be for consistency with 'ticslevel'.   "ticslevel at <foo>" will not be allowed.

Dan

Re: z_floor and z_ceiling (was Re: various observations)

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 20 May 2006 12:01 am, Daniel J Sebald wrote:
> > OK people, any preference as to xyplane (not 'ticslevel') having bottom 
> > of zrange as 0 and top of zrange as 1? 
> That is should top of zrange be 1 or -1 for 'xplane'?

I was not following this thread, and now that I look back through
it I don't understand what the issue really is.

I never did understand 'set ticslevel', but whatever it did should
stay that way for backwards compatibility.

The idea behind 'set xyplane <foo>' is [supposed to be] obvious:
Whatever zrange is, whatever way round the axes are pointing,
yadda yadda,   draw the place so that it intersects the z axis
at <foo>.  Have you found some case where this doesn't happen?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> OK people, any preference as to xyplane (not 'ticslevel') having=20
>> bottom of zrange as 0 and top of zrange as 1?
>=20
>=20
> I would prefer to keep things as they are.  I think the possible benefi=
t=20
> of flipping this sign around is too small to warrant the confusion this=
=20
> is likely to cause among users.

OK, easy change if you want to try things the other way before the next r=
elease.

> If the current behaviour isn't easy to understand from existing=20
> documentation, I say fix the documentation, not the behaviour.
>=20
>> Should "set ticslevel at <zvalue>" be allowed? =20
>=20
>=20
> I don't really care.  This command in a script would have caused a=20
> syntax error in all earlier versions of gnuplot, so it can be added=20
> without causing compatibility problems.  OTOH, 'set ticslevel' is=20
> arguably the single worst option name gnuplot ever had, so it's probabl=
y=20
> not a good idea to add things to it.

I can disallow that...  Other things to note about "ticslevel":  There ha=
sn't been a bug report for the bad behavior of the z-axis line so that mi=
ght mean it isn't used too often.  "unset xyplane", wouldn't we expect th=
at to remove the xyplane altogether?  For example "unset xtics" removes t=
he xtics.

What may have been nice from the start would be to force set/show/reset t=
o come as a structure with three functions.  (Or maybe four, set/unset/sh=
ow/reset.)  The use of "reset xtics", "reset xyplane" wouldn't be ambiguo=
us the way "unset xtics", "unset xyplane" might be.

Dan

Re: X Resources file for x11 terminal

[<br...@ph...>]

Ethan A Merritt wrote:
> I've created an X Resources file for gnuplot.
> But which directory should it be kept in?
>   .../term
>   .../share
>   .../docs

Either share or src.  This is neither a terminal driver, nor is it 
documentation.  Of these two, share makes more sense.

> And is there a way to have the autoconfigure
> tools figure out where such files are kept on the
> system so that it can be installed?  

Environment variables XUSERFILESEARCHPATH, APPLRESDIR, XFILESEARCHPATH
control this (--> 'man X'), otherwise it'll be next to the library and 
include paths found by autoconf macro AC_PATH_X.

Re: z_floor and z_ceiling (was Re: various observations)

[<br...@ph...>]

Daniel J Sebald wrote:

> OK people, any preference as to xyplane (not 'ticslevel') having bottom 
> of zrange as 0 and top of zrange as 1?

I would prefer to keep things as they are.  I think the possible benefit 
of flipping this sign around is too small to warrant the confusion this 
is likely to cause among users.

If the current behaviour isn't easy to understand from existing 
documentation, I say fix the documentation, not the behaviour.

> Should "set ticslevel at <zvalue>" be allowed?  

I don't really care.  This command in a script would have caused a 
syntax error in all earlier versions of gnuplot, so it can be added 
without causing compatibility problems.  OTOH, 'set ticslevel' is 
arguably the single worst option name gnuplot ever had, so it's probably 
not a good idea to add things to it.

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> OK people, any preference as to xyplane (not 'ticslevel') having bottom 
> of zrange as 0 and top of zrange as 1?

That is should top of zrange be 1 or -1 for 'xplane'?

> 
> Right now, as the code exists, 'xyplane' and 'ticslevel' are synonyms.  
> That is "set ticslevel at -10" is valid even though the documentation 
> indicates that this is possible:

*does not indicate* that this is possible.

> 
> Syntax:
>       set ticslevel <frac>
>       set xyplane <frac>
>       set xyplane at <zvalue>
>       show xyplane

Dan

Re: z_floor and z_ceiling (was Re: various observations)

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:

> Actually, the simplest explanation is probably the best here:  just=20
> state that ticlevels 0 and -1 correspond to the bottom and top of the z=
=20
> axis (_not_ the min and max, actually --- z axis can be reversed!), and=
=20
> that the coordinate moves linearly.
>=20
>> At this point though, changing the polarity might just confuse matters.
>=20
>=20
> This is not a question of what "might" happen.  The polarity in the 'se=
t=20
> ticslevel' parameter will not change, period.  I won't have script=20
> compatibility compromised.  What can be discussed is whether we should=20
> split up the old 'set ticslevel' and its alias, 'set xyplane <level>'.=20
> These two could have different scales.

OK people, any preference as to xyplane (not 'ticslevel') having bottom o=
f zrange as 0 and top of zrange as 1?

Right now, as the code exists, 'xyplane' and 'ticslevel' are synonyms.  T=
hat is "set ticslevel at -10" is valid even though the documentation indi=
cates that this is possible:

 Syntax:
       set ticslevel <frac>
       set xyplane <frac>
       set xyplane at <zvalue>
       show xyplane

Should "set ticslevel at <zvalue>" be allowed?  If not, then it is probab=
ly best to have enumerations of S_TICSLEVEL and S_XYPLANE, because there =
really isn't a nice way to determine what syntax cause the program to arr=
ive at the point in the case statement otherwise.

Dan

X Resources file for x11 terminal

[Ethan A M. <merritt@u.washington.edu>]

I've created an X Resources file for gnuplot.
But which directory should it be kept in?
  .../term
  .../share
  .../docs

And is there a way to have the autoconfigure
tools figure out where such files are kept on the
system so that it can be installed?  

On my machines these files live variously in
   /usr/X11R6/lib/X11/app-defaults
   /usr/lib/X11/app-defaults
but I'm sure other systems keep them other places.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal commited

[Lars H. <lhe...@us...>]

> >  on top of yours - making src/wxterminal a full autotoolified directory
> > with
> >  its own Makefile.am. I prefer this, and will make the necessary changes.
> 
> Oh, yes, that would be ideal ! I tried to do it at first (long before the
> commit) but my autoconf/automake skills were (are?) not enough...
> Thank you very much.
 
 No problem. I won't be able to get to it before next week, though.

Re: wxWidgets terminal commited

[<tim...@en...>]

>
>> > Ok, I agree. I will make this change soon, unless Lars does it befor=
e
>> me.
>>
>>  Fine by me. I'll hold off the other changes until after.
>
>  There is another alternative, which will obsolete some of the changes =
I
> made
>  on top of yours - making src/wxterminal a full autotoolified directory
> with
>  its own Makefile.am. I prefer this, and will make the necessary change=
s.

Oh, yes, that would be ideal ! I tried to do it at first (long before the
commit) but my autoconf/automake skills were (are?) not enough...
Thank you very much.

Timoth=E9e

Re: wxWidgets terminal commited

[Lars H. <lhe...@us...>]

 
> > Ok, I agree. I will make this change soon, unless Lars does it before me.
>  
>  Fine by me. I'll hold off the other changes until after.
 
 There is another alternative, which will obsolete some of the changes I made
 on top of yours - making src/wxterminal a full autotoolified directory with
 its own Makefile.am. I prefer this, and will make the necessary changes.

Re: GPGET('terminal')

[Ethan M. <merritt@u.washington.edu>]

On Thursday 18 May 2006 09:35 am, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> > gnuplot> show xrange=20
> >
> >   set xdata time
> >   set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse
> > nowriteback
> >
> > gnuplot> print GPVAL_X_MIN
> > -207792000.0
> > gnuplot> print GPVAL_X_MAX
> > -194572800.0
>
> That's to be expected.  Time internally is kept in seconds since the
> millenium.  I.e. there's nothing wrong with the above.

I understand that the values are correct in some abstract sense
(apart from being printed as negative numbers).  But if the point
of these GPVAL_* variables is to make the information available to
a script, this format fails.  We have no mechanism in place to
use the value that is returned.

=46or example, if you want to lock the x2 axis to agree with x1,
the following seems the obvious way to do it:

  set x2range[ GPVAL_X_MIN : GPVAL_X_MAX ]

But that won't work in the above case. =20
I admit to being very unfamiliar with the time/date code.
I recently tried to use it for what I thought was a simple
case, but got thoroughly tangled up.  So I don't even have
a suggestion as to how this *should* work, or what would need
to be changed.

Perhaps it would be sufficient to provide conversion routines?
   internal-time-in-seconds  <=3D=3D>  timefmt string

Then (I think) it would work to say something like

  set x2range[ timestring(GPVAL_X_MIN) : timestring(GPVAL_X_MAX) ]


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: wxWidgets terminal commited

[Lars H. <lhe...@us...>]

Timoth?e Lecomte writes:
> > Timoth?e Lecomte wrote:
> >
> >> * There's another option : we can remove both 'subdir-objects' in
> >> src/Makefile.am and AM_PROG_CC_C_O in configure.in
> >> Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of
> >> src/wxterminal/, but I can definitely live with that.
> >>
> >> So, what's your preference ?
> >
> > The above.
> 
> Ok, I agree. I will make this change soon, unless Lars does it before me.
 
 Fine by me. I'll hold off the other changes until after.

Re: wxWidgets terminal commited

[<tim...@en...>]

> Timoth=E9e Lecomte wrote:
>
>> * There's another option : we can remove both 'subdir-objects' in
>> src/Makefile.am and AM_PROG_CC_C_O in configure.in
>> Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of
>> src/wxterminal/, but I can definitely live with that.
>>
>> So, what's your preference ?
>
> The above.

Ok, I agree. I will make this change soon, unless Lars does it before me.

Timoth=E9e

Re: wxWidgets terminal commited

[<br...@ph...>]

Timothée Lecomte wrote:

> * There's another option : we can remove both 'subdir-objects' in
> src/Makefile.am and AM_PROG_CC_C_O in configure.in
> Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of
> src/wxterminal/, but I can definitely live with that.
> 
> So, what's your preference ?

The above.

Re: wxWidgets terminal commited

[<tim...@en...>]

> Timoth=E9e Lecomte writes:
>> Dear gnuplot developpers,
>>
>> After 11 months of development, the wxWidgets has landed to the CVS ! =
(I
>> hope I did not make any mistake by the way)
>
>  Timoth=E9e,
>
>  I'm trying to repair the build system after this commit.

Thank you for paying attention to this.

> There are two issues:
>
> | dnl Check for object files creation, needed to build these object fil=
es
> in subdirs
> | AM_PROG_CC_C_O
>
>  This is not what AM_PROG_CC_C_O does. It is a wrapper for AC_PROG_CC_C=
_O:
>
> |     If the C compiler does not accept the `-c' and `-o' options
> |     simultaneously, define `NO_MINUS_C_MINUS_O'.  This macro actually
> |     tests both the compiler found by `AC_PROG_CC', and, if different,
> |     the first `cc' in the path.  The test fails if one fails.  This
> |     macro was created for GNU Make to choose the default C compilatio=
n
> |     rule.
>
>  It's not needed. Can I remove it?

Interesting remark. In fact, I can see two alternatives :

* I introduced the automake option 'subdir-objects', so that wxt_gui.o fo=
r
example will be put in src/wxterminal/wxt_gui.o instead of src/wxt_gui.o.
Even if it is not specified clearly in the documentation, with
'subdir-objects', we need this AM_PROG_CC_C_O.

If I remove it on my machine (autoconf 2.59, automake 1.9.6), ./prepare
(or autonconf) fails with the following message :

src/Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in
`configure.in'

However, the current code is probably wrong as AM_PROG_CC_C_O should be
checked unconditionnally, since 'subdir-objects' is used unconditionnally.

* There's another option : we can remove both 'subdir-objects' in
src/Makefile.am and AM_PROG_CC_C_O in configure.in
Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of
src/wxterminal/, but I can definitely live with that.

So, what's your preference ?

>  Number two: if no wxWidgets are installed, the result for $WX_CONFIG i=
s
> "no",
>  and configure then tries to run the command "no". I have changed the
> logic.
>
>  if test $WX_CONFIG
>  ...
>  fi
>  if expr 2.3.3 \> `${WX_CONFIG} --version`
>  fi
>
>  to
>
>  if test $WX_CONFIG
>  ...
>  else
>    if expr 2.3.3 \> `${WX_CONFIG} --version`
>    fi
>  fi
>
>  Ok?

Yes, you are right. Thanks for pointing this out !

Timoth=E9e

Re: stat.inc

[<br...@ph...>]

Daniel J Sebald wrote:
> The way to address this would be to define
> 
> #
> #define unit step function
> #
> u_step(x) = x<0 ? 0 : 1
> 
> then multiply all the pertinent density/distribution functions by the 
> unit step.

I think it would be easier to just prefix the existing definitions with

	x<0 ? 0 :

> Should I put together a patch for this?

Sure.

Re: GPGET('terminal')

[<br...@ph...>]

Ethan Merritt wrote:
> %%%%%%% How to handle time data on axes? %%%%%%%%%%%%%%%%%%
> 
> Terminal type set to 'wxt'
> gnuplot> load 'timedat.dem'
> Hit return to continue
> gnuplot> show xrange
> 
>   set xdata time
>   set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse nowriteback
> 
> gnuplot> print GPVAL_X_MIN
> -207792000.0
> gnuplot> print GPVAL_X_MAX
> -194572800.0

That's to be expected.  Time internally is kept in seconds since the 
millenium.  I.e. there's nothing wrong with the above.