gnuplot-beta

Re: More fallout from TBOOLEAN change - hidden3d broken

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

On Mon, 29 Mar 2004, Ethan Merritt wrote:

> Is there a tool (or gcc compile option) that will
> double check for illegal operations on our TBOOLEANs? 

"Splint" comes to mind.  OTOH, we currently have O(1000) splint warnings
in gnuplot, so that may not be a particularly easy thing to check.

> made the problem go away, so this was another
> bit of fallout from the TBOOLEAN change.
> 
> hidden3d.c line 817:
>         casenumber = (plist[new_poly].frontfacing != 0)
>             + 2 * (plist[old_poly].frontfacing != 0);

Guilty as charged --- hidden3d is fully my own responsibility ;-( I'll
double-check the fixes.

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

Re: More fallout from TBOOLEAN change - hidden3d broken

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

On Mon, 29 Mar 2004, Per Persson wrote:


> That change to TBOOLEAN was for the benefit of Mac OS X if I understand 
> correctly.

Yes.  The Mac OS X build seemed to be pulling in an override definition of
type "bool" from some system header file, long *after* syscfg.h had 
already defined it.  That broke the compilation.

> Just so everybody knows what options we have, that change is *not*
> necessary anymore, with the new aquaterm.trm.

I.e. if you had come out of the bush a week or two earlier, none of this
would have been discovered before 4.0.  I'll leave it to everyone's own
deliberation whether this is a good thing or a bad.

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

Re: More fallout from TBOOLEAN change - hidden3d broken

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

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

> That fixes things and is fine.  However, v1_inside_p and v2_inside_p do 
> have the feel of Boolean variables.  

They're not, at least not really.  classification[i] is a two-bit
variable, by design, and thus v1_inside_p is, too.  It's used mostly like
a boolean later on, but that's a different story.

> probably shouldn't be.  Also, doing the bit shift on the variable is 
> extraneous.  

It may be now, but I don't think it was when I introduced it.  This
hidden3d stuff is seriously tricky, and it developed incrementally, so not
all of the stuff you see in there right now may make complete sense.

As a matter of fact, the entire statement sequence involving v?_inside_p
can be simplified to:

	    if (! (classification[0]
		   | classification[1]
		   | classification[2])) {

I'm checking in a modification along those lines.  It'll also unify some
cases where convenience copies of TBOOLEAN pm3d_color_from_column were
kept in ints.

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

Re: More fallout from TBOOLEAN change - hidden3d broken

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

Hans-Bernhard Broeker wrote:

>On Mon, 29 Mar 2004, Daniel J Sebald wrote:
>
>  
>
>>That fixes things and is fine.  However, v1_inside_p and v2_inside_p do 
>>have the feel of Boolean variables.  
>>    
>>
>
>They're not, at least not really.  classification[i] is a two-bit
>variable, by design, and thus v1_inside_p is, too.  It's used mostly like
>a boolean later on, but that's a different story.
>

Right.  But "v1 inside p", that's a yes or no question.  No?  In other 
words a Boolean.

Dan