Re: accumulated patches

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

Ethan Merritt wrote:
> On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
>>[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
>>[ gnuplot-Bugs-1525665 ] help has problems with
>>[ gnuplot-Patches-1531560 ] recursive history warning instead of error
> 
> 
> I agree these are relatively high priority.
> They almost went into 4.2, but were held out because bugs
> turned up at the last minute.  IOW they are not quite working yet.
> I would very much like to see them cleaned up, thoroughly tested,
> and added to CVS.
> 
> Please combine them into a single patch set against current source
> and let's give them a workout to shake out any remaining bugs.

Will do.


>>[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
>>
>>I think it is correct, others may not.  It appears to work on Linux and Mac and 
>>I'm fairly confident it won't cause any problems.
> 
> 
> It was never broken on linux, and I believe it is no longer needed
> on OSX either.  So the risk of breaking some minor platform seems larger
> than the benefit to any known system.  Please correct me if I'm wrong.

I'm not familiar with OSX other than that user said it works correctly when it 
was needed at the time.  Have to ask the OSX user who had a problem on this one.


>>[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
>>
>>Full implementation of mouse/clipboard behavior consistent with the vast
>>majority of X applications.
> 
> 
> ???  Not as seen here.  I have had no problems with the current implementation.
> That doesn't make your fix wrong, but I don't understand what problem is fixing.

It's added features for the most part.  But still I think the existing 
implementation doesn't really place a plot in the X clipboard, and furthermore 
it doesn't properly handle Atom translation.  The existing "clipboard" was a 
hastily constructed version that was made to work for one app and assumed to be 
a full and proper implementation.  The documentation currently states that the 
plot automatically goes into the clipboard.  But try doing a cntrl-V inside 
something like oowriter or your favorite word processor.  Nothing happens. 
There are actually two different entities, clipboard and "selection".  Those 
both have to be handled in the proper X implementation.  There needs to be 
communication about what file formats gnuplot_x11 can provide to the application 
and then gnuplot_x11 has to respond with the proper file format when requested.

The only think is that I didn't know it was possible to interpret cntrl-? keys, 
so 'c' is what puts a plot into the clipboard.  I'll see if I can fix that up to 
the cntrl-c (copy)/cntrl-v (paste) convention.


>>[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
> 
> 
> I think this is a non-issue, and we should drop this one entirely.

It's still there.  This originated from Octave computing its axis limits with a 
bit of round off.  Try

set xrange [0:1.99805]
set grid
plot sin(x)
set xrange [0:2]
replot
set xrange [0:1.99805]
replot

and look to the right edge of the plot.  Basically, it addresses this FIXME in 
the code:

/* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
* begging for rounding errors to strike us. */
/* HBB 20010410: ... and strike they did :-( */


>>[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
>>window
>>
>>Works as far as I know.
> 
> 
> Doesn't work here.  I'd like it if it *did* work, but it doesn't.
> My recollection is that it tripped over some contradictory requirements
> for window management by Tk/Tcl, GTK, etc.

I'll have another look and see if there are any problems.


>>[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
>>[ 1727198 ] Hidden lines: Degenerate polygons creating problems
>>[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure
> 
> 
> I'll leave these to Hans-Bernhard, since he's far more familiar
> with the code.  I will comment that gnuplat's hidden-line removal
> plots have very different properties than solid rendering.  When you
> render solids, omitting a facet is just about the worst thing you can do.
> The missing facet is far more jarring than a mis-aligned edge.
> But in the case of gnuplot, it is exactly the mis-aligned edges that
> are noticeable.  We don't care if a facet is dropped.  So although
> I have not delved into the code, I suspect that the most useful fix
> is simply to increase the slop margin, and deliberately omit any
> edges that are in the slop area.

Increasing the slop margin will probably make things worse.  There are two 
issues here that should be kept separate.  The alternate hidden3d issue (i.e., 
the bits and pieces) and the degenerate polygons.

The alternate hidden3d patch doesn't alter the EPSILON setting, and in fact, I 
avoid those EPSILON tests when they have no effect.  (I've noted in the code 
where they don't make a difference.)  Even the existing bug in the CVS code I 
doubt has anything to do with slop margin.  There appears to be a pattern 
whereby what bits and pieces (i.e., edge segments) that are left intersect 
precisely with one of the polygon vertices, but I'm not sure but I've offered a 
patch that works so I'm not inclined to figure it out.

The detailed explanation of the degenerate polygons is that sometimes the 4 
sided polygons turn out to be a triangle (or even share more similar vetices). 
In that case, some of the triangles making up that quadrangle are "degenerate", 
meaning that if v1, v2 and v3 are the triangles vertices, v1=v2 or v2=v3 or 
v3=v1.  But that is an infinitely thin slice and hence has no consequence if it 
is simply discarded.  However, if such a degenerate case is left, the existing 
code will try an create a plane equation describing the plane for such a 
degenerate triangle, but there is no unique, meaningful plane equation for two 
points.  Hence the orientation (probably random) incorrectly chooses the 
direction the plane faces and picks the wrong color for the line.  (The patches 
have some PNG examples attached.)


>>[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"
> 
> 
> Veto.
> There are more reasonable options.
> 1) Clean up your data files
> 2) Run it through general string handling:
>     filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
>     plot "foo" using 1:(filter($2))
> 3) Clean up your data files
> 
> Consider the case where you have multiple data files,
> each with its own idea of what is or is not a missing data flag.
> You want the fix to be per-file, not global.

I'm fine with only one missing symbol.  However, there is still the issue of 
defining exactly how these behave in the code.  I included some demo plots in 
the patch to illustrate behavior for the two classes of points.  I think 
originally behavior was sort of left to the wind.

Dan