William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/23/23 15:02, Kenneth wrote:
> >
> > This old method [of 'View_POV-Include_Stack'] is certainly not an ideal
> > way to report the presence of a user's personal #includes.
>
> I'm unsure what to do for anything shipped. We'd need a custom
> configuration option or a new run time flag/option - neither of which is
> attractive.
>
> It's hard to get simple, clean, code wins. :-)
>

I was thinking the same thing: something built-in. HOW to do it-- and how
difficult it would be to code without introducing other problems-- are the
bigger questions, of course ;-)

I'm rather surprised that, in all the years of POV-ray's code development, some
kind of internal mechanism was not introduced to do this... because knowing
automatically which #includes are actually being used in a scene would be a
useful bit of info, IMO.

In the 'official' Windows versions, the GUI uses something called CODEMAX, as
far as I understand. Perhaps the lack of such an #includes feature is a
limitation of the POV-ray/CODEMAX interaction? I do remember Clipka and other
developers mentioning 'difficulties' or restrictions between the two.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> I was thinking the same thing: something built-in. HOW to do it-- and how
> difficult it would be to code without introducing other problems-- are the
> bigger questions, of course ;-)

Seems to me (a non-source-code-programmer) that it would work as part of the
#include directive itself, and we already have internal things like recursion
stacks, etc.  So it wouldn't really be a problem to prevent multiple parsing of
includes, etc.
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?

But perhaps for some reason it's non-trivial.

- BW

Post a reply to this message

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

My my, you _have_ been busy   :O


Is there a way to identify and collect all of the places in source where errors
get raised, and group them by parse / render/ etc?

That might help folks get a better idea about how much there is an how often
some warnings might need to test conditions and fork flow control.

While working on the lemon, I also stumbled upon a dev manual in the 3.8 github
stuff - haven't had a chance to dig through it - might any of that already be in
there?

- BW

Post a reply to this message

On 3/26/23 07:50, Bald Eagle wrote:
> Is there a way to identify and collect all of the places in source where errors
> get raised, and group them by parse / render/ etc?
> 

:-) Hmm. Asking questions to which to which the only strict answer is 
yes.

If you mean quickly, you can grep strings like Warning, PossibleError, 
Error and see quite a bit of text fly by. When and whether you actually 
get any particular ones depends on more. Some too get formed indirectly 
where a function like Not_WithPattern() might be what is actually 
getting called and it will assemble some final Error or Warning.

The parsing related stuff these days is mostly in the source/parser 
directory. Just counting lines with those strings in povr, Warning 171,
PossibleError 32, Error 609.

> 
> While working on the lemon, I also stumbled upon a dev manual in the 3.8 github
> stuff - haven't had a chance to dig through it - might any of that already be in
> there?

Assume you are talking about the contents of source-doc directory.

Many years ago I did read through those files. I don't recall much of it 
truth be told and a lot of it was 15 years old already when I read it. I 
see a povms.md file. It would have stuff on the threaded messaging 
system - one of several ways messages get generated - so yep some in 
there. :-)

Bill P.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> (v3.8.0 beta 1 in Windows 10)
>
> I was playing around with #ifdef recently; just experimenting.
>
Here's another example of an #ifdef feature that would be useful, IMO. I
recently had a need for it:
     #ifdef(AA & BB)

Apparently, it doe not (yet) work with 'tuples' like the newer v3.8 #declare
does, for example. Nor with boolean operators, so it seems.

I tried several workarounds for this, in various syntax forms. My first attempt
was with nested #ifdef's, possibly using an #elseif somewhere-- but I am not
very familiar with the #elseif construct and could not come up with a code
block that seemed 'reliable' or logically consistent:

#declare AA=3;
#declare BB=7;

#ifdef(AA)
     #ifdef(BB)
     ... do this...
    (or  #elseif   ...do this... ?)
#else (?)
... do that...
#end

My 2nd attempt was with an enclosing #if, again in various syntax forms-- but
this causes fatal errors, and I'm not sure that I understand why:

#if(#ifdef(AA) & #ifdef(BB)) // this line does not work, even though an #if can
                             // itself use boolean operators
...do this...
#else
...do that...
#end

For the first line, a simpler  #if(#ifdef(AA)) does not work either, nor does
#if(#ifdef(AA)=true))

Any suggestions or comments? It seems to me that at least one of these schemes
*should* work, unless I'm making a basic error or wrong assumption somewhere.

The current v3.8 operation of #ifdef is...ill-defined... so maybe that's part of
the problem(?)

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > (v3.8.0 beta 1 in Windows 10)
> >
> > I was playing around with #ifdef recently; just experimenting.
> > ...
> For the first line, a simpler  #if(#ifdef(AA)) does not work either, nor does
> #if(#ifdef(AA)=true))
>
> Any suggestions or comments?

suggestion.  write '#if(defined(AA) & defined(BB))'  (ie both exist)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> >  ...
> > For the first line, a simpler  #if(#ifdef(AA)) does not work either, nor does
> > #if(#ifdef(AA)=true))
> >
> > Any suggestions or comments?
>
> suggestion.  write '#if(defined(AA) & defined(BB))'  (ie both exist)
>

Yes, that's a great workaround! Thanks. I had forgotten about the  'defined'
function, as I don't use it very often.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> I recently had a need for it:
>      #ifdef(AA & BB)
>
> Apparently, it doe not (yet) work with 'tuples' like the newer v3.8 #declare
> does, for example. Nor with boolean operators, so it seems.

> Any suggestions or comments? It seems to me that at least one of these schemes
> *should* work, unless I'm making a basic error or wrong assumption somewhere.


Depending on how many variables you need to test, you lump them all together
into an array and cycle through them, using the product of the result as a sort
of Boolean AND result.

Not sure I knew about "defined" - that's a handy keyword.

#declare AA = 1;
#declare BB = 3;

#declare Variables = array {AA, BB}


#macro And (_Array)
 #declare Elements = dimension_size (_Array, 1)-1;
 #declare AndResult = 1;
 #for (Index, 0, Elements)
  #declare AndResult = AndResult * defined (_Array[Index]);
 #end

 AndResult
#end


#if (And (Variables))
 #debug "All variables are defined. \n"
#end

#error "No objects in scene"d

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> >   #ifdef(AA & BB)
> > Any suggestions or comments?
>
> Depending on how many variables you need to test, you lump them all together
> into an array and cycle through them, using the product of the result
> as a sort of Boolean AND result.
>
>
> #declare AA = 1;
> #declare BB = 3;
>
> #declare Variables = array {AA, BB}
>
> #macro And (_Array)
>  #declare Elements = dimension_size (_Array, 1)-1;
>  #declare AndResult = 1;
>  #for (Index, 0, Elements)
>   #declare AndResult = AndResult * defined (_Array[Index]);
>  #end
>  AndResult
> #end
>
>
> #if (And (Variables))
>  #debug "All variables are defined. \n"
> #end
>

I had to think about this one (and had to take a temporary break because of all
of the new Spring pollen in the air, here in the South. Sneezing uncontrollably!
Me no likey!)

This is an interesting way of attacking the problem, and works fine as-is. But
if I add an UN-declared variable to the array (i.e., wondering if I had
previously declared it or not), this line fails:
           #declare Variables = array {AA, BB, CC}

"Cannot pass uninitialized identifier to non-optional array initializer."
(What a mouthful!)

But I'm probably going outside the scope of my simpler  #ifdef(AA & BB)
question. JR's #if/#else code allows a more graceful exit though: I could add a
#debug like, "One or more of your variables is undefined."

Post a reply to this message