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

Re: Please check new TBOOLEAN definition on all platforms.

[Petr M. <mi...@ph...>]

> So, please, everyone who's building gnuplot on one of the relevant
> platforms (cygwin, MinGW, Amiga, OS/2 and MSVC++), check that this is
> indeed the case.

I've tested it for OS/2, Mingw and Cyg.

> We may have to prepare another (hopefully the last!)  release candidate
> tarball because of the possible consequences of this change.

No problem to have a new release candidate (now it's two weeks before the
release).

---
PM

Re: x11 persist under OS/2

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

On Thursday 25 March 2004 10:24 am, Petr Mikulik wrote:
> There is yet another bug in x11 terminal, and it looks like to be there
> since at least 2000. Under OS/2, if I do
>
> set terminal x11 persist
> plot x
> quit
>
> then gnuplot does not quit but waits until I "q" in the x11 terminal or
> I kill it. Somebody knows where to find this problem?

It must be something specific to OS/2.  I've never seen that happen.
Does it make any difference which readline() option is used?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

x11 persist under OS/2

[Petr M. <mi...@ph...>]

There is yet another bug in x11 terminal, and it looks like to be there
since at least 2000. Under OS/2, if I do

set terminal x11 persist
plot x
quit

then gnuplot does not quit but waits until I "q" in the x11 terminal or I
kill it. Somebody knows where to find this problem?


Also, I've noticed that OS/2 has obviously never passed command line
arguments to gnuplot_x11. In x11.trm, routine X11_args() is launching
executable of gnuplot_x11, and there is an OS/2 code with
popen(X11_command), while others have execvpe(X11_command, optvec).
Strange, optvec contains garbage under OS/2. I couldn't find why.

---
Petr Mikulik

Re: NEW BUG: filled arrowheads not working

[Hans-Bernhard B. <br...@ph...>]

On Thu, 25 Mar 2004, Hans-Bernhard Broeker wrote:

> Aargh.  The reason for that is of course, that do_arrow() will become
> term->arrow(), so it *must* match the prototype for that in struct
> TERMENTRY.  OTOH, I don't see any real need to touch that argument of
> do_arrow().  

But in the meantime, I did find it.  The head argument of term->arrow() is
indeed used to pass a literal '2'.  This really is bad, for at least two
reasons.

1) It clearly breaks the entire idea behind having a TBOOLEAN.

2) That '2' should be a named constant.  We don't want magic numbers.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Please check new TBOOLEAN definition on all platforms.

[Hans-Bernhard B. <br...@ph...>]

Hello, everyone,

as Ethan just found out, the new way TBOOLEAN is defined I checked in on
Tuesday exposed some lurking bugs.  I've now added the relevant #define's
for HAVE_STDBOOL_H and HAVE__BOOL to all the preset config.h files.  I've 
assumed that both of these conditions are true, on all those platforms.

So, please, everyone who's building gnuplot on one of the relevant
platforms (cygwin, MinGW, Amiga, OS/2 and MSVC++), check that this is
indeed the case.  With both defaulting to true, you'll get solid compiler
errors if you have to toggle them.

We may have to prepare another (hopefully the last!)  release candidate
tarball because of the possible consequences of this change.  Sorry about
that, but this seemed the only reasonable way we would ever get out of
that mess with MacOS X.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: NEW BUG: filled arrowheads not working

[Hans-Bernhard B. <br...@ph...>]

On Wed, 24 Mar 2004, Ethan Merritt wrote:

> Did this just break recently?  I don't recall getting these errors before.

I probably broke it on Tuesday, when I turned TBOOLEAN into an actual
C99-like bool, on those platforms that have this.  This was needed for the
benefit of Mac OS X, which ran into redefinition problems with bool.

> The problem is that curr_arrow_headfilled is a TBOOLEAN but then we find
> code like the following in term.c:
> 
> 	curr_arrow_headfilled = arrow_properties->head_filled
> 	...
> 	if (curr_arrow_headfilled == 2) {
> 		...

Which is, of course, plainly wrong.  Are we really getting this sloppy?

> I tried the simple fix of changing curr_arrow_headfilled to be an int
> rather than a TBOOLEAN, and similarly the last parameter to do_arrow(),
> but this just made things worse (hundreds of incompatible pointer
> warnings).

Aargh.  The reason for that is of course, that do_arrow() will become
term->arrow(), so it *must* match the prototype for that in struct
TERMENTRY.  OTOH, I don't see any real need to touch that argument of
do_arrow().  I'm checking in the change to curr_arrow_headfilled right
away.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

NEW BUG: filled arrowheads not working

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

Did this just break recently?  I don't recall getting these errors before.

[1] rm term.o; make

gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8k\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8k/gnuplot.gih\" -I/usr/X11R6/include -I/usr/local/include   -g -O2 -Wall -c term.c
term.c: In function `do_arrow':
term.c:930: warning: comparison is always false due to limited range of data type
term.c:957: warning: comparison is always false due to limited range of data type
term.c:959: warning: comparison is always false due to limited range of data type
term.c:989: warning: comparison is always false due to limited range of data type
In file included from term.h:300,
                 from term.c:1054:
../term/fig.trm: In function `FIG_arrow':
../term/fig.trm:785: warning: comparison is always false due to limited range of data type
../term/fig.trm:807: warning: comparison is always false due to limited range of data type
../term/fig.trm:817: warning: comparison is always false due to limited range of data type


The problem is that curr_arrow_headfilled is a TBOOLEAN but then we find
code like the following in term.c:

	curr_arrow_headfilled = arrow_properties->head_filled
	...
	if (curr_arrow_headfilled == 2) {
		...

which tries to set it to an (int) and then test for values other than TRUE or FALSE.
The same problem arises elsewhere in term.c and in fig.trm
I tried the simple fix of changing curr_arrow_headfilled to be an int rather than
a TBOOLEAN, and similarly the last parameter to do_arrow(),
but this just made things worse (hundreds of incompatible pointer warnings).

Anyhow, the result is that filled arrowheads are not working.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: (un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

[Petr M. <mi...@ph...>]

> But there is a related case for which I am not sure of the
> correct behaviour:
>
> set term x11 1 persist
> plot sin(x)
> set term dumb
>
> At this point the connection between gnuplot and gnuplot_x11 is
> still present but, since the current terminal is no longer x11, mouse
> events are ignored.  Should we explicitly turn mousing over to
> gnuplot_x11 in this case even though the connection is still active?
> Should gnuplot itself continue to handle X-events even though the
> current terminal is now something other than x11?

No, it should not -- e.g. pressing "l" for "set log y" in X11 would change
this property globally, thus also for the other terminal, which is probably
not desired.

> > set mouse
> > set term x11 1 persist
> > plot sin(x)
> > set term x11 2 persist
> > plot x
> > set term x11 3 persist
> > plot tan(x)
> > unset mouse
> >
> > unsets mouse only in terminal 3, and not in all terminals. Also a bug.
>
> Not fixable.  Or at least not fixable in the general case, although the
> specific simple example you give could be changed.   But why is it a
> bug?  If you ask for a persistent X11 window, don't you expect it to
> operate on its own without further input from gnuplot?

This should not depend on whether window is persistent or not.

Question is whether "unset mouse" operates on the current or on all
mouseable terminals. Currently only on the selected one. We can keep this
feature, and then it is not bug.


> > I think gplt_x11.c should react to "m" hotkey to switch the mousing bar on/off.
>
> Good idea.  I will add it to CVS when SourceForge comes back online.

Works nice, just a small annoyance: you have to move your mouse so that the
window resizes itself to adopt space for the mouse bar. Could the resize be
called automatically when mouse gets on/off?


> > Finally, there is some funny behaviour of mousing ruler, when "set x11
> > <another>; replot" -- it would be nicer to position the ruler to its x,y
> > coordinates.
>
> Please explain in more detail.  Do you mean that the new window should
> not inherit the state of the ruler from the previous window?  Or do you
> mean that it *should* inherit the ruler, but the ruler should be re-positioned?

It should inherit the ruler at its x,y position so that the ruler propagates
at the same x,y for all subsequent plots.
Could you please patch it?

---
Petr Mikulik

Re: (un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

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

On Tuesday 23 March 2004 08:04 am, Petr Mikulik wrote:
> According to the bug report "[ 921033 ] pipe+mouse+x11", the following
>
> set mouse
> set term x11 1 persist
> plot sin(x)
> set term x11 2 persist
> plot x
> set term x11 3 persist
> plot tan(x)
> quit
>
> let terminals 1 and 2 mouseable, while not 3. There seems to be a bug
> that does not notify terminal 3 to be active for post-quit mousing.

Fixed in CVS.  If the connection between gnuplot and gnuplot_x11 is
broken (e.g. by 'quit') then gnuplot_x11 will take over the mousing.

But there is a related case for which I am not sure of the 
correct behaviour:

set term x11 1 persist
plot sin(x)
set term dumb

At this point the connection between gnuplot and gnuplot_x11 is
still present but, since the current terminal is no longer x11, mouse
events are ignored.  Should we explicitly turn mousing over to
gnuplot_x11 in this case even though the connection is still active?
Should gnuplot itself continue to handle X-events even though the
current terminal is now something other than x11?


> set mouse
> set term x11 1 persist
> plot sin(x)
> set term x11 2 persist
> plot x
> set term x11 3 persist
> plot tan(x)
> unset mouse
>
> unsets mouse only in terminal 3, and not in all terminals. Also a bug.

Not fixable.  Or at least not fixable in the general case, although the
specific simple example you give could be changed.   But why is it a
bug?  If you ask for a persistent X11 window, don't you expect it to
operate on its own without further input from gnuplot?

In fact, now that I think about it - I consider it a bug that if you type
'set term x11 nopersist; exit' at this point then all the previous windows
are closed even though they were individually opened with "persist".
I think that persist/nopersist should be a per-window property, not a
global one.

> I think gplt_x11.c should react to "m" hotkey to switch the mousing bar on/off.

Good idea.  I will add it to CVS when SourceForge comes back online.

> Finally, there is some funny behaviour of mousing ruler, when "set x11
> <another>; replot" -- it would be nicer to position the ruler to its x,y
> coordinates.

Please explain in more detail.  Do you mean that the new window should
not inherit the state of the ruler from the previous window?  Or do you
mean that it *should* inherit the ruler, but the ruler should be re-positioned?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time/date autoticking --- showstopper?

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

Chr...@ha... wrote:

>Dan :
>
>  
>
>>Well, actually after your discussion and examples, I think what you have 
>>done is better than what is shown.  It seems what you have done is made 
>>things so that the major ticks always lie along the bottom and top 
>>borders.  (Is that correct?)  
>>    
>>
>
>I'm not exactly sure what you're saying here.  All ticks, major or minor,
>should be on the axis, and not 'off the top of the X11 window', as you
>mentioned in the first e-mail.  Perhaps you are referring to the fact
>that the 'test1.ps' has apparent interval of one hour between ticks, so
>that the implied '01:00' tick is out of the X11 window.
>

Yes.  I said that backward; I meant top and bottom borders aligning with 
a major y-axis tic.

Dan

Re: [ gnuplot-Bugs-906056 ] enh-ps: @-aligned string does not work with font change

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

I have patched this bug in CVS.  The fix is conceptually simple,
but I had to add a couple of lines to the already-complicated
PostScript routine MFshow.  Please exercise it thoroughly to
confirm how robust it is (or isn't :-).

This should fix the reported problem for all terminals supporting
enhanced text mode. 


On Thursday 18 March 2004 02:30 pm, SourceForge.net wrote:
> Submitted By: Harald Harders (harders)
> Assigned to: Ethan Merritt (sfeam)
> Summary: enh-ps: @-aligned string does not work with font change
>
> Initial Comment:
> If I align a string with @ to use no space and change the
> font inside this string part, the formatting is broken.
> For example
> try
>
> set xlabel 'A@{^{Times{/Helvetica Helv}Times}}_{bye}'
>
> "Times", "Helvetica", and "Times" again are plotted
> at the same position instead of one after another. In my
> opinion, "TimesHelveticaTimes" should be written, using
> no space for the complete string.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time/date autoticking --- showstopper?

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

Christopher Roth wrote:

>Dan/Hans :
>
>  
>
>>I'm not totally sure what the problem is with this one.  Is it that 
>>there are only the major tics and so few of them that it is difficult to 
>>judge the values?  Are you saying there should be more minor tics here?
>>
>>For example
>>
>>    p [-10 : 36*59] x
>>
>>looks pretty good, aside from the fact that the top tic annotation lies 
>>off the top of the X11 window.  There is a major tic spacing of 3 
>>minutes and minor tic spacing at every minute.
>>    
>>
>
>This first example is looks ok.
>

Well, actually after your discussion and examples, I think what you have 
done is better than what is shown.  It seems what you have done is made 
things so that the major ticks always lie along the bottom and top 
borders.  (Is that correct?)  What I don't like about "test1.ps" is that 
the middle/top major tic is about two thirds the way up the left border 
instead of halfway up the left border.  With that setup it is difficult 
to get a precise guesstimate of values in between the tics.  It's as 
though your eyes can't get a handle on just exactly what the proportions 
are there.

So the more major tics in test1_fixed.ps are helpful and also the tics 
starting and stopping on borders is helpful.  It is certainly nicer and 
what you have is close if not correct.  However, could there be a minor 
tic in "test1_fixed.ps"?  Or are minor tics at fractional units not 
allowed (e.g., 2.5 minutes)?  I think you are saying they are not 
allowed, right?

>>But for
>>
>>    p [-10 : 36*60] x
>>
>>the scale seems to jump to the hourly dynamic range, or mode, or 
>>whatever you want to call it.  So all of a sudden there is only one or 
>>possibly two major tics and no minor tics.  So that tells me the 
>>algorithm in quantize_time_tics() may need some adjustment.  You may 
>>want to stay in the minute mode just a little while longer, say twenty 
>>percent more.  Or it may be that you just want some minor tics in there 
>>to fill things out a little better.  Or, you could put major tics at 
>>every half hour instead of hour when in this region (i.e., just a little 
>>bit beyond an hours time).  Anyway, choosing the better major tic 
>>spacing doesn't seem like a huge issue.  (Is the "guide" parameter meant 
>>to be roughly the number of tics that should be?)  Perhaps you need to 
>>introduce a few more "ranges" inside the enumeration, e.g., 
>>TIMELEVEL_THIRDMINUTES, TIMELEVEL_THIRDHOURS, etc., and then add the 
>>appropriate cases inside the routines.
>>    
>>
>
>I have to say that Hans has great work in quantize_time_ticks(), and it
>does NOT need any adjustment.  The results from this are just fine - 
>it's just that the results are being OVERRIDDEN by this unneccesary
>'zero reset' in the time_tic_just() routine.  My proposed fix averts
>this reset until it is really needed.
>
>Take a look at the both the plot produced and contents of the 'test1.ps'
>and 'test1_fixed.ps' files in the attached tar file.  The important 
>thing to note is the number of time each of the unique time labels are 
>being drawn - the 'test1.ps' shows the '31/12/1999 23:00' label being
>drawn *12* times, and all at the _same_ place, making it look like only
>one label.  Had the minutes not been forced to 0 in the time_tic_just()
>routine, there would have been a nice set of 5-minute interval major 
>time ticks.  The '01/01/2000 00:00' label is drawn *9* times, which
>continues the 5-minute intervals, making the intended top label being 
>'00:40', which exactly correlates with the length of the axis.
>The 'test1_fixed.ps' file shows the same plot, but generated using my
>proposed fix of adding the three pairs of braces in time_tic_just().
>Since the minutes are not being forced to zero, the starting time is 
>at 23:55, rather than 23:00.  The same intended 5-minute interval is
>present, and each time label is drawn only once.
>

test2_fixed.ps looks correct to me.

>>However, this example:
>>
>>    p [-10 : 36*300] x
>>
>>reveals a more sever problem.  Now the hourly major tics seem pretty 
>>good, perhaps still a bit too spaced apart.  But the minor tics aren't 
>>evenly spaced.  It looks as though the minor tic spacing starts out such 
>>that there should be 6 minor tics between major tics, but only the first 
>>two minor tics are displayed.  I would say this one is a bug of the typo 
>>kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
>>than a conceptual thoughto.
>>
>>    
>>
>
>This is the error that drove me to track this bug down.  From looking at
>the 'test2.ps' plot, it appears that every other major tic, and its
>associated minor tics are missing.  Again, the postscript file reveals
>that these labels are not lost, but are drawn on top of the previous
>one.  The first label, '23:00' is drawn twice - first for 23:00, then 
>for 23:30, except that the minutes are being forced to zero -> so it 
>goes to 23:00.  The same thing happens to all other major ticks at 
>'**:30' - they are forced to be '**:00'.
>The plot in 'test2_fixed.ps' shows the way it was intended by the 
>quantize_time_ticks() routine.  Because the minutes are not being forced
>to zero, the starting time is allowed to be at 23:30, and all the other
>major ticks at **:30 now show up where they should.
>

Well, certainly Hans wouldn't have intended to have zero spacing tics...

Anyway, it looks like the bug is near fixed, if not fixed.  Nice work.

Dan

(un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

[Petr M. <mi...@ph...>]

According to the bug report "[ 921033 ] pipe+mouse+x11", the following
commands

set mouse
set term x11 1 persist
plot sin(x)
set term x11 2 persist
plot x
set term x11 3 persist
plot tan(x)
quit

let terminals 1 and 2 mouseable, while not 3. There seems to be a bug that
does not notify terminal 3 to be active for post-quit mousing.

Further,

set mouse
set term x11 1 persist
plot sin(x)
set term x11 2 persist
plot x
set term x11 3 persist
plot tan(x)
unset mouse

unsets mouse only in terminal 3, and not in all terminals. Also a bug.


Actually, I thought that mousing is stopped when quitting gnuplot: this
feature was available in 1998--1999 in OS/2 and later in X11, then removed
due to mousing implementation rewrite. Well, now it is back in X11 -- so,
let's keep it there, but then I think gplt_x11.c should react to "m" hotkey
to switch the mousing bar on/off.

Can somebody fix these things?

Finally, there is some funny behaviour of mousing ruler, when "set x11
<another>; replot" -- it would be nicer to position the ruler to its x,y
coordinates.


---
PM

Re: Time/date autoticking --- showstopper?

[Hans-Bernhard B. <br...@ph...>]

On Mon, 22 Mar 2004, Daniel J Sebald wrote:

> You didn't get much feedback on this one.  I think it is because it is 
> somewhat obsure for most to follow without working with it closely.  

That's why I suggested to go play with it a bit --- the shortcomings
are pretty obvious once you start looking for them.

But with Petr on vacation, and Ethan occupied with the generalization of
postscript enhanced to other terminals, it looks like I'll have to do this
on my own.

I'll just check in my current fix then.  It works different from the one
suggested by the bug's original reporter, in several ways.

> But for
> 
>     p [-10 : 36*60] x
> 
> the scale seems to jump to the hourly dynamic range, or mode, or 
> whatever you want to call it.  

Exactly that's the problem.  To be more precise, timelevel[FIRST_Y_AXIS] 
is TIMELEVEL_HOURS in this case, and that's where the proverbial brown 
stuff hits the fan.  time_tic_just interprets this fact as meaning that 
*all* tics have to lie on integer multiples of hours, whereas 
quantize_time_tics wants it to mean that the tic interval is 1/12th of an 
hour.

> that there should be 6 minor tics between major tics, but only the first 
> two minor tics are displayed.  I would say this one is a bug of the typo 
> kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
> than a conceptual thoughto.

Trust me, it is a "thoughto" alright. 

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Time/date autoticking --- showstopper?

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

  Hans-Bernhard Broeker wrote:

>Gents,
>
>it seems we may have found ourselves a show-stopping bug:
>
> [ 918276 ] Irregularly spaced labels on time axis in v 3.8k.2
>
>Thanks to Chistopher Roth (cc'ed) for spotting this one.
>
>The culprit who committed the code in question is myself, but given the
>schedule of the planned release, I think we'll need all attention we can
>muster focussed on that one.  I for one won't consider the program to be
>release-worthy until we fix it.  (It's marked as release_critical for that
>reason.)
>

You didn't get much feedback on this one.  I think it is because it is 
somewhat obsure for most to follow without working with it closely.  I 
briefly looked through the code for the routines you mention and 
although I can't pinpoint things without really getting into it, maybe a 
dialogue can lead to the problem...

First, let me say that the code looks fairly well organized and logical 
so that if you find the problem, fixing for the 4.0 release wouldn't be 
shaking the tree too much.  The solution is probably just some minor 
adjustment, I would think.

>
>To easily see what the problem is, try the following script:
>
>	reset
>	set ydata time
>	set mytics
>	p [-10 : 36*60] x
>


I'm not totally sure what the problem is with this one.  Is it that 
there are only the major tics and so few of them that it is difficult to 
judge the values?  Are you saying there should be more minor tics here?

For example

    p [-10 : 36*59] x

looks pretty good, aside from the fact that the top tic annotation lies 
off the top of the X11 window.  There is a major tic spacing of 3 
minutes and minor tic spacing at every minute.

But for

    p [-10 : 36*60] x

the scale seems to jump to the hourly dynamic range, or mode, or 
whatever you want to call it.  So all of a sudden there is only one or 
possibly two major tics and no minor tics.  So that tells me the 
algorithm in quantize_time_tics() may need some adjustment.  You may 
want to stay in the minute mode just a little while longer, say twenty 
percent more.  Or it may be that you just want some minor tics in there 
to fill things out a little better.  Or, you could put major tics at 
every half hour instead of hour when in this region (i.e., just a little 
bit beyond an hours time).  Anyway, choosing the better major tic 
spacing doesn't seem like a huge issue.  (Is the "guide" parameter meant 
to be roughly the number of tics that should be?)  Perhaps you need to 
introduce a few more "ranges" inside the enumeration, e.g., 
TIMELEVEL_THIRDMINUTES, TIMELEVEL_THIRDHOURS, etc., and then add the 
appropriate cases inside the routines.

However, this example:

    p [-10 : 36*300] x

reveals a more sever problem.  Now the hourly major tics seem pretty 
good, perhaps still a bit too spaced apart.  But the minor tics aren't 
evenly spaced.  It looks as though the minor tic spacing starts out such 
that there should be 6 minor tics between major tics, but only the first 
two minor tics are displayed.  I would say this one is a bug of the typo 
kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
than a conceptual thoughto.


>Replace the numbers by whatever you like, and watch the y tics.  
>Optionally set the ytics or mytics to some explicit interval.
>
>There's a *lot* of funny things going on there.  The minitics are
>seriously ill, but the major tics aren't exactly perfect either.  The
>functions and data to inspect are all in axis.c:
>
>	t_timelevel timelevel[];
>	AXIS axis_array[];
>
>	quantize_duodecimal_tics()
>	quantize_time_tics()
>	make_auto_time_minitics()
>	time_tic_just()
>
>The main problems seem to be that interpretation of timelevel[] is
>somewhat different between quantize_time_tics() and time_tic_just().
>
>Since I invented quantize_duodecimal_tics(), timelevel[] is set by
>quantize_time_tics() to be the unit the major tic spacing it's *based* on.  
>In particular, that unit is quite often *larger* than the actual tic step,
>i.e. a tick step of 10 minutes is seen as "1/6th of an hour", so
>timelevel[] will be TIMELEVEL_HOURS.  time_tic_just() does quite a number
>of wrong things if tics are spaced as fractions of a timelevel[] unit. In
>particular it moves tics around by zeroing out fields in a time struct,
>causing them to often end up all in the same place. Christopher posted a
>patch for this, but IMHO that's not exactly correct either.
>
>Time axes are actually not all that bad, even --- the strange factor of
>twelve is tricky, but quantize_duodecimal_tics() can handle it.  The real
>bugger is with date axes.  These are (slightly, but significantly)
>irregular by definition, and that's not something the usual auto-ticking
>algorithm can do. In trying to get those right, it's very easy to break
>other aspects, and we did.
>

Well, there seems to be a large amount of code for Gnuplot implementing 
its own form of gmtime().  Yes, that is going to be involved, various 
month lengths, leap year algorithm, etc.  Too bad there isn't some way 
of translating the time values and using the existing gmtime() routine. 
 However, I don't see this as the issue for the major/minor tics.  A 
problem with this routine would only mess up the contents of the tic 
labels, e.g., wrong dates, mainly.

Are we on the same wavelength here?

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Time/date autoticking --- showstopper?

[Hans-Bernhard B. <br...@ph...>]

Gents,

it seems we may have found ourselves a show-stopping bug:

 [ 918276 ] Irregularly spaced labels on time axis in v 3.8k.2

Thanks to Chistopher Roth (cc'ed) for spotting this one.

The culprit who committed the code in question is myself, but given the
schedule of the planned release, I think we'll need all attention we can
muster focussed on that one.  I for one won't consider the program to be
release-worthy until we fix it.  (It's marked as release_critical for that
reason.)

To easily see what the problem is, try the following script:

	reset
	set ydata time
	set mytics
	p [-10 : 36*60] x

Replace the numbers by whatever you like, and watch the y tics.  
Optionally set the ytics or mytics to some explicit interval.

There's a *lot* of funny things going on there.  The minitics are
seriously ill, but the major tics aren't exactly perfect either.  The
functions and data to inspect are all in axis.c:

	t_timelevel timelevel[];
	AXIS axis_array[];

	quantize_duodecimal_tics()
	quantize_time_tics()
	make_auto_time_minitics()
	time_tic_just()

The main problems seem to be that interpretation of timelevel[] is
somewhat different between quantize_time_tics() and time_tic_just().

Since I invented quantize_duodecimal_tics(), timelevel[] is set by
quantize_time_tics() to be the unit the major tic spacing it's *based* on.  
In particular, that unit is quite often *larger* than the actual tic step,
i.e. a tick step of 10 minutes is seen as "1/6th of an hour", so
timelevel[] will be TIMELEVEL_HOURS.  time_tic_just() does quite a number
of wrong things if tics are spaced as fractions of a timelevel[] unit. In
particular it moves tics around by zeroing out fields in a time struct,
causing them to often end up all in the same place. Christopher posted a
patch for this, but IMHO that's not exactly correct either.

Time axes are actually not all that bad, even --- the strange factor of
twelve is tricky, but quantize_duodecimal_tics() can handle it.  The real
bugger is with date axes.  These are (slightly, but significantly)
irregular by definition, and that's not something the usual auto-ticking
algorithm can do. In trying to get those right, it's very easy to break
other aspects, and we did.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Somebody check my patch for SF bug 905651, please

[Petr M. <mi...@ph...>]

> I'm not convinced this can go into CVS before the 4.0 release.  It's a
> pretty serious bug, but I suspect the risk that my patch breaks something
> else is considerable.  I see three ways out of this dilemma:
>
> 1) Put it in CVS, then release yet another release candidate to the
> general public right away, to give this patch as much exposure as
> possible.
>
> 2) Some of us (Petr, most importantly...) test this rigorously before it
> goes in.  Then it goes into CVS for 4.0
>
> 3) Delay this patch until after the release.

It would be worth to submit the patch if it passes "demo/pm3d.dem" as well
... try to run the current and patched gnuplot versions with this file and
compare results. Currently, the new patch does not pass.


> I tried not to affect its operation in PM3D mode, but Petr or someone will
> have to check this.

> Petr: I you should do something about this FIXME comment of yours:
> (graph3d.c:2268 after this patch):
>
> 	if (*X_AXIS.label.text) {
> 	    /* label at xaxis_y + 1/4 of (xaxis_y-other_y) */
> #ifdef USE_GRID_LAYERS /* FIXME: still needed??? what for? */
> 	    if ((surface_rot_x <= 90 && BACKGRID != whichgrid) ||
> 		(surface_rot_x > 90 && FRONTGRID != whichgrid)) {
> #endif

With a simple
	set pm3d; set border 4095
	splot sin(x*y/4)/(x*y)

and rotation by mouse all around, it looks like your patch does sometimes
hide wrong bar of the border, e.g. for view: 146, 37, 1, 1 -- I think these
rot_x >=90 and <=90 conditions are just about this.


> Actually, since the tick labels are defined to always be outside the graph
> box, it shouldn't matter at all, as long as you make sure they're only
> output once.

I see these tics a major trouble here. Immediately the 1st three plots in
pm3d.dem look strange ... as well as all others. Even those splot with "pm3d
solid" are affected -- you see spurious tics without border's label. So
there is something out of proper order.

And "set grid back" is completely broken in the new patch.

Could you please fix it?

Petr

Somebody check my patch for SF bug 905651, please

[Hans-Bernhard B. <br...@ph...>]

Hello, everyone,

I've just filed a patch for this SF bug report:

[ 905651 ] splot: grid and border overlap the plot

The fix, unfortunately, is a pretty massive one:

gnuplot/src> wc graph3d_grid_layers.diff
    386    1791   12707 graph3d_grid_layers.diff

I'm not convinced this can go into CVS before the 4.0 release.  It's a
pretty serious bug, but I suspect the risk that my patch breaks something
else is considerable.  I see three ways out of this dilemma:

1) Put it in CVS, then release yet another release candidate to the
general public right away, to give this patch as much exposure as
possible.

2) Some of us (Petr, most importantly...) test this rigorously before it
goes in.  Then it goes into CVS for 4.0

3) Delay this patch until after the release.

I built it by generalizing Petr's existing PM3D-only hack "whichgrid" to
be usable in all circumstances I could imagine.  I tried not to affect its
operation in PM3D mode, but Petr or someone will have to check this.

Petr: I you should do something about this FIXME comment of yours:
(graph3d.c:2268 after this patch):

	if (*X_AXIS.label.text) {
	    /* label at xaxis_y + 1/4 of (xaxis_y-other_y) */
#ifdef USE_GRID_LAYERS /* FIXME: still needed??? what for? */
	    if ((surface_rot_x <= 90 && BACKGRID != whichgrid) ||
		(surface_rot_x > 90 && FRONTGRID != whichgrid)) {
#endif

I removed several similar if's of that kind from [xyz]tick_callback(),
because they really didn't make much sense.  Whether or not to draw those
tick labels is a question of 'whichgrid' alone.  The surface_rot_x status
almost certainly should not have to be consulted here.  Actually, since
the tick labels are defined to always be outside the graph box, it
shouldn't matter at all, as long as you make sure they're only output
once.  So

	if (FRONTGRID != whichgrid) {

should suffice.  That's what my patch does.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Necessary Libraries

[Harald H. <h.h...@tu...>]

> > Thank you all for your answers. But shouldn't we really prepare a file
> > requirements.txt or a section Requirements in the README where all
> > needed third-party libraries are listed?
>
> Yes, but not in README.  This belongs into INSTALL.

You are right of course.

> They already are
> listed there, but not in all the necessary detail, and the text is
> outdated, and that's where it belongs.  INSTALL is where people building
> the program from sources are supposed to look --- README is for users, not
> builders.

Yes, the library names can be found there. But the information is well
hidden. I think it could be worth adding a section "Third-party libraries"
where all eventually needed libraries are listed with a link to the part
where is written how to switch on and off parts of gnuplot.

> > PS: I have tried to avoid all Umlauts. I hope this mail will be sent as it
> > is, now.
>
> It works.

Okay, then I will try that as workaround in future.

Yours
Harald

-- 
Harald Harders                           Langer Kamp 8
Technische Universitaet Braunschweig     D-38106 Braunschweig
Institut fuer Werkstoffe                 Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: Necessary Libraries

[Hans-Bernhard B. <br...@ph...>]

On Tue, 9 Mar 2004, Harald Harders wrote:

> 
> Thank you all for your answers. But shouldn't we really prepare a file
> requirements.txt or a section Requirements in the README where all
> needed third-party libraries are listed? 

Yes, but not in README.  This belongs into INSTALL.  They already are
listed there, but not in all the necessary detail, and the text is
outdated, and that's where it belongs.  INSTALL is where people building
the program from sources are supposed to look --- README is for users, not
builders.

> PS: I have tried to avoid all Umlauts. I hope this mail will be sent as it
> is, now.

It works.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Necessary Libraries

[Harald H. <h.h...@tu...>]

Thank you all for your answers. But shouldn't we really prepare a file
requirements.txt or a section Requirements in the README where all
needed third-party libraries are listed? It could be possible to write the
library information into the *.trm files with a special format and to
generate the "Requirements" section automatically, e.g. by using grep.

Yours
Harald

PS: I have tried to avoid all Umlauts. I hope this mail will be sent as it
is, now.

-- 
Harald Harders                           Langer Kamp 8
Technische Universitaet Braunschweig     D-38106 Braunschweig
Institut fuer Werkstoffe                 Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: Necessary Libraries

[Petr M. <mi...@ph...>]

> And a last short question: Have my several patches in the last years
> been enough that my name will be added to the list of contributors?

IMHO, people listed in docs/titlepage* are those spending an enormous amount
of time on gnuplot development (new features, patches, documentation,
reviews of work of others), support, and other activities over a period of
at least several years.

People kindly contributing patches (incl. new features) get the proper
credit in ChangeLog file.

---
PM

Re: Necessary Libraries

[Hans-Bernhard B. <br...@ph...>]

On Mon, 8 Mar 2004, Petr Mikulik wrote:

> > Have you been able to read all of my mail? Hans-Bernhard has reported,
> > that he only could read until half of the mail.
> 
> Neither me -- the following is printed by pine:
[...]
>    [Error: Formatting error: Non-hexadecimal character in QP encoding]

I've since diagnosed the problem a little deeper and submitted a SF
support request about it.  The problem is with the sponsor ads SF's
mailing list processor appends to mails.  They may contain '=' characters,
which break mail bodies encoded as quoted-printable, where '=' is an
escape character.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Necessary Libraries

[Petr M. <mi...@ph...>]

> second). Ah, I am missing libgd.so. May be, this is the problem. And, gd.h
> is missing, too. I first will reinstall that and ask again, if necessary.

As others told you about gd-devel rpm package

> I don't understand why my libgd is not totally installed. I think,
> my SuSE 8.2 is the last SuSE on my computers, it is getting worse form
> version to version.

I don't think so -- no problems for me (since 8.0)

> Have you been able to read all of my mail? Hans-Bernhard has reported,
> that he only could read until half of the mail.

Neither me -- the following is printed by pine:


Yours
Harald

--
Harald Harders                           Langer Kamp
   [Error: Formatting error: Non-hexadecimal character in QP encoding]




There were similar problems with Ethan's mail some time ago, but it's gone
now.

---
PM

Re: Necessary Libraries

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

On Monday 08 March 2004 08:35 am, Harald Harders wrote:
>
> "rpm --query gd" gives me "gd-2.0.11-26" which, according to gd.trm,
> should work. In /usr/lib, I find the following files: libgd.so.2,
> libgd.so.2.0.0 (where in fact, the first is a symbolic link to the
> second). Ah, I am missing libgd.so. May be, this is the problem. And,
> gd.h is missing, too.

Yes.  You need both libgd.so and gd.h
However, I recommend that you download version 2.0.21 from
boutell.com, and built from source.  Version 2.0.21 is the first to
correctly support symbol font encoding, which is needed for full
support of enhanced text mode in gnuplot.

> I first will reinstall that and ask again, if 
> necessary. I don't understand why my libgd is not totally installed. I
> think, my SuSE 8.2 is the last SuSE on my computers, it is getting worse
> form version to version.

I do not know how SuSE arrange their packages, but Mandrake and
Redhat both split libraries into two packages. The base package
contains the library itself and is suitable for use by pre-built applications.
The second rpm is called whatever-devel-xxx.rpm and contains the
header files (*.h) and the additional library definitions needed to
build new programs.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195