On 3/25/23 07:38, Bald Eagle wrote:
> As for parse time, how much extra could there possibly be to check the include
> stack to see if the file has been included yet, or if the "view include stack"
> flag is set or not?

Mostly very little as you suggest.

Excepting where someone is using the Parse_String hack or similar and so 
doing potentially gazillions of small includes - as is happening in the 
animation code of jr's. The clean fix for that problem is to change that 
hack into some immediate, interpret this 'string' feature - but that's 
not all that easy to do.

In any case, I was thinking more of jr's general #pragma capability for 
turning off say 13 warnings, but not any of the other remaining 3,852 (I 
made that number up).

We introduced the possible errors category too as something I believe 
new to v3.7/v3.8/v4.0, but I didn't go check the v3.6 source.

Thinking aloud...

In compilers most all warnings are introduced with a general, less 
general and selective control capability(a), but also various categories 
of warnings. These are almost all on command line flags and often inline 
with code too. In code these optionally to some local region (like a 
file or particular functions) in the form of #pragma settings. That 
said, such message controls are not all that standardized between 
compilers. What you do for one compiler might or might not work for 
others. And sometimes there are conflicts between compilers.

POV-Ray is a little different from compilers in that we have a parse 
phase, which is compiler like is some respects, and then we have a 
render phase for both stills and animations. Those two modes differ in 
behavior and cost.

Aside: We have too a nascent RTR capability too not sharing much with 
the control structure of regular animations.

The issues start with the code base not having a generic set up for 
anything like an in code #pragma capability - which probably would apply 
to SDL only I'd say.

We have too what looks like common functionality in things like pow() 
that have multiple forms internally. One for the SDL and another for 
functions running on the vm at parse time or render time.

We have warnings and errors around both command line options and ini 
settings too. These perhaps more an issue for animations where you might 
get some warning for each frame.

The error messages don't all go through the same message systems or 
message handlers today. In povr, I use the fancier ones when they are 
there and ready to use, but when they are not, I don't!

I've made use of writing to stderr, for example, when it's the expedient 
thing to do to get messages about behavior where we are today just 
letting things go. Often things which were historically reported in 
earlier single thread versions of POV-Ray. Yes, this means sometimes 
each thread kicks out exception messages, but I feel getting the 
information is more important than not.

That's sort of the really rough lay of the land for info / warning / 
possible error / error / messages. The thinking aloud, I expect, more 
helpful to me than anyone else. :-)

All that said, adding a few select controls, #pragmas, not all that hard 
to do. Maybe we aim to control the most annoying (or most useful) 
messages first.

Where these might bleed over to render time functionality there is a 
significant cost to turning on or off checks when that 'control test' 
gets done millions (or billions) of times while rendering. Such testing 
costs less for animations where you might have only a thousand frames. 
For stills such control tests might cost little or be significant if 
happening inside a loop placing thousands of objects.

Yes, issuing and tracking information for the messages costs too. 
Sometimes we'll win when the messages are off - even if running the 
control test a great many times.

Sometimes messages are situation-ally useless as happens when users 
create isosurfaces with functions having a high gradients - well away 
from the all of the actual roots. In such cases the gradient warnings 
have no 'useful' meaning and in povr 'report false' turns them off by 
isosurface.

There are situations where better more controllable warnings absolutely 
helps limit warnings to those probably useful.

Bill P.

(a) - Aside. When I re-worked povr's gnu, autotools based build, I 
turned off all the compiler warnings by default. To me,  it didn't make 
sense for users grabbing the code to do a quick ./configure, make -j4, 
make check, make install; to see hundreds of warnings they aren't going 
to try and fix anyway.

Post a reply to this message