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

Re: General bug - No out of bounds checking on 3D coordinates

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

On Monday 05 July 2004 05:43 am, Hans-Bernhard Broeker wrote:
> On Sun, 4 Jul 2004, Ethan A Merritt wrote:
> > The cleanest is probably to return an error from map3d_xy,
> > but since there are roughly 100 call sites this would be a *lot* of
> > extra code to handle error checking.
>
> Not really.  map3d_xy() is called 41 times:

Oops.  I used grep, and caught a bunch of 'map3d_xyz' instances as well.

> IMHO clipping has to be the duty of the callers of map3d_xy, because only
> they can possibly know what the right reaction should be, or at least
> output an intelligible errors message if they can't seem to find a
> reasonable reaction.

In principle I agree.  But I was hoping for some sort of quick fix for the
blatant error of stuffing negative numbers into an unsigned int.

An easy example of the current error is the demo I just added.
    set term pdf
    set output 'test.pdf'
    load 'datastrings.dem'

will exit when it hits the 3D plotting example because one of the labels is
off the bottom of the plot in the initial view setting. 

Well, clipping labels is easier than clipping line segments.
I could add an error return code to map3d_xy() and check for it in 
the label-handling code.

Is everyone OK with the idea "if a label is out of bounds don't 
try to draw it at all"?   This would be change, as right now some
drivers will draw the piece of the label that is in-bounds even though
the label coordinates themselves are out of bounds.

Re: General bug - No out of bounds checking on 3D coordinates

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

Hans-Bernhard Broeker wrote:

>>- Have map3d_xy() call int_error() if the coordinates go negative?
>>    
>>
>
>No.  map3d_xy is far too deep in the basement of gnuplot to output a
>meaningful int_error() message. 
>

Right.

>>- Have map3d_xy() siliently truncate to zero?
>>    
>>
>
>  
>
>>- Have map3d_xy() truncate, but not so silently?
>>    
>>
>
>No to both.  For the same reason: map3d_xy() has no way of knowing how to
>properly clip positions.  E.g. if the actual thing being drawn is a line
>segment, clipping the out-of-range endpoint to the nearest point on the
>viewport border will rotate the entire edge.  I'm quite sure that's not
>sensible behaviour.
>

I agree with that.

>>The cleanest is probably to return an error from map3d_xy, 
>>    
>>
>
>Agreed.
>

I don't understand why negative coordinates is an error.  Conceptually, 
it's as though our view port is from (0, 0) to (x_max, y_max). 
 Certainly there are some situations where the graphical element may 
make no sense to be outside that range.  But the decision if that is a 
problem or not lies at the very last use, inside the driver.

>IMHO clipping has to be the duty of the callers of map3d_xy, because only
>they can possibly know what the right reaction should be, or at least
>output an intelligible errors message if they can't seem to find a
>reasonable reaction.
>

I agree with that.  There is one thing about the terminal scheme that 
doesn't have a solid concept, or at least I don't recognize it.  It is 
how to have "default" routines of a driver.  The analogy would be like 
the base routine of an object oriented language; a base routine that can 
be overridden.  A couple examples:  Take clipping a line segment at the 
border.  There are probably some terminal drivers which handle this 
cleanly, and perhaps some that don't.  Well, it's a simple routine, and 
all the terminals that can't handle clipping should instead access a 
single gnuplot routine that does the clipping (and of course that 
routine would in turn call the terminal driver for plotting line 
segments that are within bounds).  The second example might be the image 
routines.  I've recently noticed in PostScript and PDF that "skews" can 
be put in images.  That is, rather than use the PM3D routines to plot an 
image with a skew, all that simply need be done for PostScript and PDF 
is give the appropriate parameters, resulting in a more efficient PS or 
PDF file.  My guess is that not all terminals can do this, so gnuplot or 
terminal drivers should default to using PM3D elements for this option. 
 So here would be the alternatives:

1)  Forget about fairly advanced features as this in PostScript where 
images can be given skew.

2)  At the driver level have some type of default routine containing the 
PM3D method (i.e., little paralellograms for pixels).

3)  At the gnuplot level (graphics.c) deal with this, but have the 
terminal indicate if it can handle skewed images, e.g.

if (term->parameters(HAVE_SKEWED_IMAGES)) {
} else {
}

Another one in this category might be the arrow head/line thickness 
problem.  I'm in the camp who think lines with arrows should have the 
head of the arrow stop exactly at the point given to gnuplot.  The code 
to do this isn't too bad provided one knew the thickness of the line in 
question.  One would want to reuse that code.  Should it be at the 
driver level in an object oriented model (2) or should it be at the 
gnuplot level (3) and get the line thickness from the terminal, e.g., 
term->parameters(LINE_THICKNESS)?  I mean, provided it was pressing 
enough to address the issue?

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

On Mon, 5 Jul 2004, Daniel J Sebald wrote:

> Can signed ints be passed back to avoid the use of floating point?  

They can, but that would only delay the problem, not really solve it.

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

Re: Keyboard input losses also on MS Windows

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

On Sun, 4 Jul 2004, Ethan A Merritt wrote:

> On Sunday 04 July 2004 07:46 am, Hans-Bernhard Broeker wrote:
> > Warning:  wgnuplot now tends to lose the first keypress after starting
> > the program.  This did not happen with 4.0.0, and is fixed by back-dating
> > mouse.[ch] and readline.c to that state.
> 
> The last significant change I can see in readline.c is the change 
> 1.33 -> 1.34 (catch EINTR), but that was from 18 Feb 2004 so *before*
> the 4.0.0 tag.

Now that you mention it: right ;-).  A red herring.  On to the next one.

> (1) the pause-for-mouse code - but all of these changes are protected
>     by "if (paused_for_mouse) {...}" so I don't see how they could explain
>     anything that happens immediately on program entry

Agreed.

> (2) the addition of a table of "special keys" (4 Jun 2004).  I can't see
>     anything wrong with this code either, but it's Petr's addition so maybe
>     he can spot something I didn't.

This would be my prime suspect for the moment.

> > Which rather strongly hints at problems with the mousing/keyboard
> > synchronization not only on X11, but also on MS Windows.
> 
> Maybe.  But I don't recall that we ever saw X11 problems on program entry.

Not immediately on program entry, but this problem does feel vaguely like
the early renditions of our select()/buffering problems on X11 / PIPE_IPC,
where e.g. commands typed or piped in while the gnuplot_x11 window was
being started could be dropped, e.g.

	echo -e "plot sin(x)\nplot(cos(x)\n" | gnuplot

might end up with the sine wave plot shown, because the second line of
input was lost in transport.

> None of the recent code additions should be triggered until you actually
> issue a "pause mouse" command.  Is there any conceivable way that
> Windows could manage to start up without having initialized the
> pause_for_mouse TBOOLEAN to FALSE?

I don't think so.

> Does the problem still happen if gnuplot is configured with
> #undef USE_MOUSE ?

To be experimented with.  I'm not even sure the Windows version
still builds in that configuration...

> > But backdating those files to 4.0.0 doesn't cure this problem
> > --- it doesn't seem to occur in 4.0.0 though.
> 
> How about if things are back-dated to just before ANSI-fication?

The OP reported the probleming having appeared considerably earlier than
4.0.1, i.e. before the ANSI-fication.  Anyway, the Windows code was quite
completely ANSI style long before that anyway, since K&R compilers never
existed for MS Windows programs.

But for the record: going back to 4.0.1 didn't help, unless I misremember
the weekend's experiments badly.

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

Re: General bug - No out of bounds checking on 3D coordinates

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

On Sun, 4 Jul 2004, Ethan A Merritt wrote:

> I have encountered a nasty bug that has been around since forever.
> It is not obvious to me what is the best way to deal with it.
> 
> The basic problem is that the 3D mapping routine map3d_xy() in util3d.c
> stuffs its output into (unsigned int) terminal coordinates.
> But it does so without ever checking that the results are positive numbers.  

Going negative isn't the only possible error.  Going beyond term->xmax or
term->ymax is just as wrong.  Granted, the terminal drivers don't usually
crash or run into endless loops because of it, but it's wrong nonetheless.

And it's not only map3d_xy that does that.  Traditionally, there has been
next to *no* clipping of positions to visible or allowable ranges anywhere
in gnuplot.  Some terminal drivers do their own clipping, and some
graphics elements did learn to clip properly over time.  But generally
it's still a "you get what you asked for" world down there.

See, e.g. the 'set arrow to far away points causes garbage' bug registered
at SF.  In more technical terms, that bug's title should be "arrows don't
clip".

> - Have map3d_xy() call int_error() if the coordinates go negative?

No.  map3d_xy is far too deep in the basement of gnuplot to output a
meaningful int_error() message. 

> - Have map3d_xy() siliently truncate to zero?

> - Have map3d_xy() truncate, but not so silently?

No to both.  For the same reason: map3d_xy() has no way of knowing how to
properly clip positions.  E.g. if the actual thing being drawn is a line
segment, clipping the out-of-range endpoint to the nearest point on the
viewport border will rotate the entire edge.  I'm quite sure that's not
sensible behaviour.

Anyway, IMHO if map3d_xy() were to clip, it should clip *before* it
transforms, i.e. it should clip points to the boundary of its input
coordinate system (the 3D graph box).  But that would kill time-honoured
hacks like 'set view ,,1.2', which deliberately produce points outside
that volume.

gnuplot is consistently inconsistent in the way it uses signed vs.  
unsigned data types.  E.g. in the context at hand, map3d_xy uses
unsigned int for its result:

    *xt = (unsigned int) ((res[0] * xscaler / w) + xmiddle);
    *yt = (unsigned int) ((res[1] * yscaler / w) + ymiddle);

whereas the other major conversion method from normalized, or "view" 3D
coordinate space (x and y those of the page, z orthogonal to it, origin in
the center of it), to terminal coordinates is the TERMCOORD macro:

/* Maps from normalized space to terminal coordinates */
#define TERMCOORD(v,xvar,yvar)                  \
{                                               \
    xvar = ((int)((v)->x * xscaler)) + xmiddle; \
    yvar = ((int)((v)->y * yscaler)) + ymiddle; \
}

-Wsign-compare is by far the most frequently issued warning you get
building gnuplot with a picky compiler setting:

      1  might be used uninitialized in this function
      1 comparison of unsigned expression < 0 is always false
      2 argument  might be clobbered by  or
      4 signed and unsigned type in conditional expression
     10 unused parameter
     21 cast discards qualifiers from pointer target type
     54 (near initialization for )
     54 missing initializer
    111 comparison between signed and unsigned

(The 54 "missing initializer" ones are caused by shortened terminal
structs, i.e. they're completely harmless).

> The cleanest is probably to return an error from map3d_xy, 

Agreed.

> but since there are roughly 100 call sites this would be a *lot* of
> extra code to handle error checking.

Not really.  map3d_xy() is called 41 times:

gnuplot/src $ cscope -L3 map3d_xy | wc -l
     41

The companion function map3d_xyz() doesn't convert all the way to terminal
coordinates, so it doesn't have this particular problem.

IMHO clipping has to be the duty of the callers of map3d_xy, because only
they can possibly know what the right reaction should be, or at least
output an intelligible errors message if they can't seem to find a
reasonable reaction.

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

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan A Merritt wrote:

>I have encountered a nasty bug that has been around since forever.
>It is not obvious to me what is the best way to deal with it.
>
>The basic problem is that the 3D mapping routine map3d_xy() in util3d.c
>stuffs its output into (unsigned int) terminal coordinates.
>But it does so without ever checking that the results are positive numbers.  
>
>This may also happen with 2D plots, but if so I haven't encountered it yet.
>
>Most of the terminal drivers simply clip the resulting absurd values,
>so the error goes unnoticed.  But the pdf driver does not, and it would
>be messy to do so. The illegal values are passed into routines
>in libpdf, which prints an error message and then calls exit().
>
>How should we deal with this?
>
>- Have map3d_xy() call int_error() if the coordinates go negative?
>

Hmm.  Are you referring to situations where, say, some zoom and viewing 
angle is such that coordinates go negative?  I would think that could 
happen fairly often, no?  And in some sense it really isn't an error, is it?

>- Have map3d_xy() siliently truncate to zero?
>

Don't like this one.  map3d_xy() is more of a utility type routine, and 
as such it shouldn't assume too much about the final manner in which the 
data is used.  Here is one case in point.  The image stuff has the 
option of varifying the whole grid us uniformly spaced.  Move some of 
the negative coordinates and it could possible mess up the routine. 
 Even though the final routine may never use those points, the routine 
will think it is not a uniform grid.

>- Have map3d_xy() truncate, but not so silently?
>

How do you mean?

>- Change map3d_xy() to return floating point numbers, and have the
>  caller deal with testing for negative values and then converting into
>  unsigned ints afterward?
>
>- Continue to return unsigned ints but make map3d_xy type 
>  (int) rather than (void), and require that the calling routine check for
>  error status in the return code?
>
>- Leave map3d_xy() alone, and deal with it driver-by-driver, if needed?
>  In the case of pdf.trm this would mean testing all coordinates passed
>  to the driver.
>

Can signed ints be passed back to avoid the use of floating point?  I'd 
prefer that the final routine using the numbers do the sanity check. 
 I'm wondering if, in fact, the pdf utility calls inside pdf.trm don't 
already take care of that, and if one passed a negative coordinate into 
the routines instead of a mangled unsigned coordinate it might know what 
to do, e.g., truncate a line at the border.

Dan

Engines are started; first car is out the gate

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

As of this evening I have merged into CVS the three large
patches I had more or less ready to go [*].  

filledcurves	(no configuration options)
    fill above/below bounding curve
    fill between 2 curves
    apply fill styles to filledcurves
    allow term->filled_polygon() even without PM3D support
    demo:  fillbetween.dem

datastrings	(defaults to --enable-datastrings)
    plot with labels
    splot with labels
    using xticlabels(<col>) title <col>
    demo: datastrings.dem

histograms	(defaults to --disable-histograms)
    set style data histograms <opts>
    with histograms {clustered|rowstacked|columnstacked}
    set key invert
    demo: histograms.dem histograms2.dem


I have a few other minor patches that need to be revisited
post-ANSIfication, but they are not likely to be road obstacles
to others.  I will feed them in as I get a chance to check them.

I also have some largish patches corresponding to implementations
of several different flavors of user-accessible string variables.
These have been discussed off and on over the last year or so,
but I never sensed a real consensus as to which approach was
best. I will not merge any of these into CVS without further discussion
on the mailing list.  As I find time I will update them and put them
on SourceForge for people to look at again.  


	So -- who is next out of the gate?  


[*] They were quite ready a week ago, but the ANSIfication of the
source tree made them rather less so.  I'm still tracking down a
few minor glitches introduced into the code for columnstacked
histograms.  I also discovered and fixed a number of problems
arising if you try to build with --disable-pm3d.  Some of these should
probably be fixed in the 4.0 tree as well.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Keyboard input losses also on MS Windows

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

On Sunday 04 July 2004 07:46 am, Hans-Bernhard Broeker wrote:
> Warning:  wgnuplot now tends to lose the first keypress after starting
> the program.  This did not happen with 4.0.0, and is fixed by back-dating
> mouse.[ch] and readline.c to that state.

The last significant change I can see in readline.c is the change 
1.33 -> 1.34 (catch EINTR), but that was from 18 Feb 2004 so *before*
the 4.0.0 tag.

More has changed in mouse.c, but I can't see anything that would explain
the observed symptom.  The changes are basically all related to two
things
(1) the pause-for-mouse code - but all of these changes are protected
    by "if (paused_for_mouse) {...}" so I don't see how they could explain
    anything that happens immediately on program entry
(2) the addition of a table of "special keys" (4 Jun 2004).  I can't see
    anything wrong with this code either, but it's Petr's addition so maybe
    he can spot something I didn't.

> Which rather strongly hints at problems with the mousing/keyboard
> synchronization not only on X11, but also on MS Windows.

Maybe.  But I don't recall that we ever saw X11 problems on program entry.
None of the recent code additions should be triggered until you actually
issue a "pause mouse" command.  Is there any conceivable way that
Windows could manage to start up without having initialized the
pause_for_mouse TBOOLEAN to FALSE?

Does the problem still happen if gnuplot is configured with
#undef USE_MOUSE ?

> But backdating those files to 4.0.0 doesn't cure this problem
> --- it doesn't seem to occur in 4.0.0 though.

How about if things are back-dated to just before ANSI-fication?
Maybe Windows is not so ANSI-compliant as it might be.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

General bug - No out of bounds checking on 3D coordinates

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

I have encountered a nasty bug that has been around since forever.
It is not obvious to me what is the best way to deal with it.

The basic problem is that the 3D mapping routine map3d_xy() in util3d.c
stuffs its output into (unsigned int) terminal coordinates.
But it does so without ever checking that the results are positive numbers.  

This may also happen with 2D plots, but if so I haven't encountered it yet.

Most of the terminal drivers simply clip the resulting absurd values,
so the error goes unnoticed.  But the pdf driver does not, and it would
be messy to do so. The illegal values are passed into routines
in libpdf, which prints an error message and then calls exit().

How should we deal with this?

- Have map3d_xy() call int_error() if the coordinates go negative?

- Have map3d_xy() siliently truncate to zero?

- Have map3d_xy() truncate, but not so silently?

- Change map3d_xy() to return floating point numbers, and have the
  caller deal with testing for negative values and then converting into
  unsigned ints afterward?

- Continue to return unsigned ints but make map3d_xy type 
  (int) rather than (void), and require that the calling routine check for
  error status in the return code?

- Leave map3d_xy() alone, and deal with it driver-by-driver, if needed?
  In the case of pdf.trm this would mean testing all coordinates passed
  to the driver.

My inclination is to silently truncate to zero, but because this is not
real clipping it can cause strange-looking output plots (extra junk
piles up along the bottom and left edge).

The cleanest is probably to return an error from map3d_xy, but since
there are roughly 100 call sites this would be a *lot* of extra code to
handle error checking.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Keyboard input losses also on MS Windows

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

One further problem I just discovered after a problem report by Dietmar 
Warning:  wgnuplot now tends to lose the first keypress after starting
the program.  This did not happen with 4.0.0, and is fixed by back-dating
mouse.[ch] and readline.c to that state.  Which rather strongly hints at
problems with the mousing/keyboard synchronization not only on X11, but
also on MS Windows.

Dietmar's original problem is vaguely similar, but harder to reproduce:
flipping open the menu of the text window, click on the title bar of the
text window, then type something.  Sometimes the first keypress will be
ignored.  But backdating those files to 4.0.0 doesn't cure this problem 
--- it doesn't seem to occur in 4.0.0 though.

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

Re: Move arbitrary text by an offset

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

On Saturday 03 July 2004 07:24 am, Harald Harders wrote:
> The main questions are:
> - Which kind of interface do you think is best, and shall all kinds of
>   text output have the `offset' functionality?

I think it can be applied to all text entries.  The most annoying thing,
as you already noted, is backwards compatibility with commands that
provide an offset with no key word.

> - How shall this new function be implemented? Which function and which
>   struct are to be extended?

Both the label_struct and text_label structures already contain
x and y offsets as type (double).  I propose that all text entities in gnuplot
can be moved into one of these two structures if they are not already
stored that way.  In fact, a while ago I looked at consolidating these into a 
single structure; at the time it didn't seem worth it, but we could revisit
that idea.  However if you want to allow different types of offsets
("graph", "plot", "character", etc) then an additional structure member
is needed to hold this.  

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Move arbitrary text by an offset

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

On Sat, 3 Jul 2004, Harald Harders wrote:

> There is one problem with logarithmic axes: It is difficult to handle
> offsets given in plot coordinates (`first', `second') with log axes.
> Hans-Bernhard has suggested to use the coordinates as factors then.
> `offset first 2,2' could mean to put the text to the position with double
> value of the default position. This sounds good to me.

While at it, let's also note that vaguely similar problems exist with
relative positions on time/date axes.  It's surprisingly hard to 
predict what 'set xtics' & friends will do if you specify the tic step 
size explicitly.

There's another precedent to be kept in mind: the 'rto' way of specifying
arrow endpoints relative to their starts instead of absolutely.  All such
usages of relative positions and offsets had better have a consistent user
interface.  E.g. 'rto' could be renamed to 'to offset'.

> - Which kind of interface do you think is best, 

I like the idea you've presented.  'offset' tells the reader of the
command exactly what it does, and it should be easy to memorize.

> and shall all kinds of text output have the `offset' functionality?

Definitely.

> - How shall this new function be implemented? Which function and which
>   struct are to be extended?

Wrap both term->put_text() and write_multiline() into new functions,
term_offset_text() and write_multiline_offset that call the basic 
functions with the appropriate changes to the position.

Which reminds me of another project that feels overdue: splitting term.c
into (at least) 3 parts: routines called by *.trm functions (e.g.  
do_point(), do_arrow()); wrappers around term->foo() functions serving as
a buffer layer between them and the main core of gnuplot, and a .c file
whose sole job it is to #include "term.h".  Effectively, we may end up
renaming term.h to a .c file...

The new "output text with positional offset" functions would go into
the second of those parts.

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

Move arbitrary text by an offset

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

On sourceforge, I have had a discussion with Hans-Bernhard about moving
ticmarks by an offset (patch #807026). We have decided to continue this
discussion in this mailing list.

In some cases, it is useful to move different kinds of text relative to
their default position. For example, the ticmarks are too far away from
the axis in some cases (for relatively small plots in postscript mode, for
instance). The axis labels (xlabel, ...) can already be moved by an
offset. But it seems useful to me to be able to move all kinds of text by
an offset that is given in measures of plot coordinates (`first',
`second'), `screen', `graph', or in font coordinates (as it is now for
xlabel). The font specific length may be called `glyph' or `character'.

A possible example:

set xtics offset graph 0.03,glyph 0.5
set xlabel 'x' offset screen 0.05,first 0.2

I suggest alwas to use the keyword `offset' to specify an offset with the
general coordinates (`first' ,`second', `screen', `graph', `glyph'). These
kinds of text that have an offset right now ([xyz]label, title) could then
behave as used when not using `offset' and use the general coordiantes
when using the keyword.

There is one problem with logarithmic axes: It is difficult to handle
offsets given in plot coordinates (`first', `second') with log axes.
Hans-Bernhard has suggested to use the coordinates as factors then.
`offset first 2,2' could mean to put the text to the position with double
value of the default position. This sounds good to me.

The main questions are:
- Which kind of interface do you think is best, and shall all kinds of
  text output have the `offset' functionality?
- How shall this new function be implemented? Which function and which
  struct are to be extended?
- And who will do the programming? (unfortunately, I am not able to start
  work on it before january.)

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr 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: Tagged branch-4-0-stable, head now 4.1.0

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

Hans-Bernhard Broeker wrote:

>To avoid us getting in each other's way massively, I suggest Ethan goes
>first, since his list of patches ready to throw in seems the most
>massive...  Once those are out of the way, we'll have to discuss which
>of the other patchsets available at SourceForge we want to merge in
>as they are, and which need further consideration.
>
>"Gentleman, start your engines."
>

Bruum, bruum...

>May the madness ensue --- *now*.
>

Just to get the worst over, I've updated the image patch including the 
coding style suggestions.  For the most part it wasn't too bad.  One big 
hunk was a problem, however.  I basically did a diff on the latest file 
in question and its corresponding previous working file, which turned 
out fairly small.  After block copying the bad hunk, I searched the 
newly created diff file for any white space or function declaration 
problems that conflicted, located and fixed them and that was it... oh 
and the four strange compiler warnings are gone (yay!).

Dan

Tagged branch-4-0-stable, head now 4.1.0

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

Hi, everyone,

as I warned you yesterday, I've now branched off a 4.0 stable branch. It's
essentially the same as 4.0.2 except for Ethan's patch to fit.c.  The
branch is tagged to the name branch-4-0-stable.  This branch should be
considered stable, i.e. only *necessary* changes go in there.  New
features strictly on the trunk version only, please.

The head revision of the trunk I renamed to 4.1 patchlevel 0 to reflect
that.  Note that this marks a change to the Linux way of release
numbering: even minor is stable, odd minor is the work-in-progress code.
The 4.1 trunk revision is now ready for all those patches y'all have been
aching to put in ever since the release turned from a dream into an actual
plan, or longer.  

To avoid us getting in each other's way massively, I suggest Ethan goes
first, since his list of patches ready to throw in seems the most
massive...  Once those are out of the way, we'll have to discuss which
of the other patchsets available at SourceForge we want to merge in
as they are, and which need further consideration.

"Gentleman, start your engines."

May the madness ensue --- *now*.

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

postscript dots (was Re: 4.0.1 tagged, next steps...)

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

On Thu, 1 Jul 2004, Daniel J Sebald wrote:

> (Note though, that points of "Lattice test for random 
> numbers" are so faint in PostScript they can hardly be seen... wiping 
> the dust off my screen helped a bit.  Probably a GhostView issue because 
> when the file is translated to PDF the points are darker.  There a bit 
> more detectable when the PostScript image is printed out, but not much.)

I think this is caused by ghostscript's anti-aliasing technique being in
use.  These dots are considerably smaller than a screen pixel, so in the
antialiased view, ghostscripts will display them not as black, but as the
average of a small black dot and a large white rest of the pixel's area,
coming out as a light gray.

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

Re: 4.0.1 tagged, next steps...

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

Daniel J Sebald wrote:

> to PDF the points are darker.  There a bit more detectable when the 
> PostScript image is printed out, but not much.) 

^^^^^

Oy, "They're" not "There".

Dan

4.0.2 (ANSI-fied) checked in, tagged.

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

Hello, everyone,

just as I threatened yesterday, I now submitted what may well be the
single largest check-in in the history of our CVS repository.  The version
string is 4.0 patchlevel 2, aka 4.0.2, tagged GNUPLOT_RELEASE_4_0_2.

With this change, the current head-of-tree is now supposed to be free of
any K&R function definitions.  I also took the liberty of getting rid of
all trailing whitespace in source lines (which appears to have saved a
whopping 5 KB on the .tar.gz...:-)).  I also checked in the ChangeLog
cycling:

-rw-r--r--    1 hbb      users      457424 2004-07-01 18:56 ChangeLog.0
-rw-r--r--    1 hbb      users       15812 2004-07-01 19:01 ChangeLog

I cut it at the GNUPLOT_RELEASE_4_0_0 tag (2004-04-15).

I'll tag 4.0.2 the branch base for the 4.0 stable branch about this time
tomorrow.  Objections, if any, to be raised before that, please...

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

Re: 4.0.1 tagged, next steps...

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

Hans-Bernhard Broeker wrote:

>Hello, everyone.
>
>I've just upped the PATCHLEVEL to 1, so the CVS head is now 4.0 patchlevel
>1, a.k.a. 4.0.1, and tagged it as GNUPLOT_RELEASE_4_0_1.
>
>I've also checked in some changes that had been sitting on my home box 
>for
>ages, including another optimization of the postscript driver's output
>which avoids breaking the path for the case of linewidth change requests
>that don't actually change the width.
>
>Please shake this down a bit to make sure I didn't introduce any major
>breakage.
>

I see no major breakage.  All the demos appear to run through X11 and 
PostScript fine.  (Note though, that points of "Lattice test for random 
numbers" are so faint in PostScript they can hardly be seen... wiping 
the dust off my screen helped a bit.  Probably a GhostView issue because 
when the file is translated to PDF the points are darker.  There a bit 
more detectable when the PostScript image is printed out, but not much.)

Dan

Re: Cycle the ChangeLog?

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

Hans-Bernhard Broeker writes:
> Hello, everyone,
> 
> the size of our ChangeLog file is beyond sensible bounds by now.  I
> suggest we move current contents to a new file and start from a
> fresh one, as part of the 4.0.2 tag/branch.  Opinions?
 
 No problem, please rotate it to ChangeLog.0.

Re: Cycle the ChangeLog?

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

On Thursday 01 July 2004 08:47 am, Hans-Bernhard Broeker wrote:
> Hello, everyone,
>
> the size of our ChangeLog file is beyond sensible bounds by now.  I
> suggest we move current contents to a new file and start from a
> fresh one, as part of the 4.0.2 tag/branch.  Opinions?

Sounds good to me.
Maybe rather than a totally clean slate, you should truncate it 
at the point of the 4.0 release.

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

Cycle the ChangeLog?

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

Hello, everyone,

the size of our ChangeLog file is beyond sensible bounds by now.  I
suggest we move current contents to a new file and start from a
fresh one, as part of the 4.0.2 tag/branch.  Opinions?

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

4.0.1 tagged, next steps...

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

Hello, everyone.

I've just upped the PATCHLEVEL to 1, so the CVS head is now 4.0 patchlevel
1, a.k.a. 4.0.1, and tagged it as GNUPLOT_RELEASE_4_0_1.

I've also checked in some changes that had been sitting on my home box 
for
ages, including another optimization of the postscript driver's output
which avoids breaking the path for the case of linewidth change requests
that don't actually change the width.

Please shake this down a bit to make sure I didn't introduce any major
breakage.  Unless there are problems with this version, I'll continue by
checking my rather monstrous change that removes all remaining K&R
function definitions (and gets rid of whatever other CodeStyle violations
I stumbled upon in the process).  I've also healed the major K&R
incompatibilities in the terminal API layer ('head' argument of
term->arrow(), 'c' argument of term->writec() are both int now). Once I've
checked that in, it'll become patchlevel 2, and become the branch-off
point for the 4.0 stable branch.

Some reminders from the CodeStyle department which would have made this
job easier if all of us had stuck to them more consequentially:

*) Function definitions are supposed to have the return type (including
all flags) on a line of its own, i.e.:

	static int
	foo(unsigned int x)
	{
	  ...

   not

	TBOOLEAN int PNG_PointX(int type)

*) Only file-scope objects and their comments ever start in colum 1.

*) Function-like macros that expand to a statement should never end with a
semicolon --- that's for the caller to supply, to avoid royally confusing
auto-indenting editors by apparently unfinished function calls.  In case
of doubt, use the do {} while (0) trick, and define them as tightly as
possible, i.e. inside the function using them, and #undef them again ASAP.

*) Please, no blanks at the () of a function call, declaration or 
definition.  I.e. make it 

	a = sin(x);

not

	a = sin( x ) ;

We want whitespace around operators, but typically not to the left of ')',
to the right of '(', nor to the left of ';' or ','.

*) Absolutely no dangling white space at line ends.

*) Please, every statement on a line of its own.  No

	a.x = foo ; a.y = bar;
	if (c) return 0;

but

	a.x = foo;
	a.y = bar;
	if (c)
	    return 0;

*) Opening braces go on the same line as the block's controlling for(), 
while(), if() or "do" clause.

*) "} else" goes in one line.

*) If you open a { } for a case in a switch(), put the closing "break;"  
line *inside* those braces.
	
-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: ! commands

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

On Mon, 28 Jun 2004, Fabrizio Bardelli wrote:

> 
> In gnuplot 4.0 i cannot launch MSDOS or UNIX commands like:
> ! rm filename
> or even run a program from the interactive window.

More information, please.  What version of gnuplot are you running,
exactly, on what platform, and how do such commands fail?

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

! commands

[Fabrizio B. <bar...@es...>]

In gnuplot 4.0 i cannot launch MSDOS or UNIX commands like:
! rm filename
or even run a program from the interactive window.

I based the graphical output of my data analysis programs on gnuplot and
now i can no longer use them correctly.

please help me!