I hit the 'post' button too soon :-/

> And I would be happier if my silly string-literal example produced a fatal
> error! Otherwise, I can't imagine a scenario where a 'naked' string would even
> be used there.
>

Well, on 2nd thought, I do see at least one special-case string use: To try to
easily determine if a particular #include file is actually present in a scene.
Like:
              #ifdef("my sphere file.inc")
or maybe a no-string version:  #ifdef(my sphere file.inc)
                           or  #ifdef(my sphere file)

Nothing like this works in v3.8xx. Of course, #ifdef may not be the correct
thing to use, but it's the first idea that comes to mind. (I have a vague
memory-- possibly mistaken-- that I did use the string- construct version in the
*distant* past, and that it worked. Or maybe not.) But with the current behavior
of #ifdef("...string..."), it's of no use. And   (my sphere file.inc)   fails
outright because of the 'dot'; likewise   (my sphere file)  because of the
spaces.

There IS an obscure built-in identifier (or variable?) called
View_Include_Stack, that can be used to determine if any of POV-ray's *own*
specific include files are present-- ALL that are being used-- by putting the
following at the top of a scene, running it, then looking afterward in
'Messages' (in Windows GUI versions, that is):
                     #declare View_POV_Include_Stack = true;

I can't find it in the documentation; but take a look here...
https://news.povray.org/povray.general/thread/%3C5c0827cd%241%40news.povray.org%3E/

Unfortunately, it will not list any user-made #includes-- even if they are
placed in POV-ray's 'includes' folder; I just tested it. That seems strange.

(The link above actually discusses the topic of how to determine the presence of
such user-made files, but the various methods seem to require that code snippets
be added to each and every file first. A simpler #ifdef scheme would be much
easier!)

Post a reply to this message

On 3/20/23 23:31, Kenneth wrote:
> Well, on 2nd thought, I do see at least one special-case string use: To try to
> easily determine if a particular #include file is actually present in a scene.

I'm having a hard time seeing a good reason for the capability. If you 
are trying to do something like swap in simple stand in for a complex 
model while developing a scene, it seems like you should just set that 
up on a declared true false variable ahead of time.

Maybe you'd want to automatically use a simple stand end until the 
include of the complex model is created. Well then you could use 
file_exists() and the complex model will be included as soon as it exist 
somewhere POV-Ray can find it.

A failing include stops parsing.

Folks often include far more than they need (stnd.inc ?) for any given 
scene. While that slows down parsing, it usually isn't a fatal mistake.

Unfortunate undefs or re-declares to the same IDs do happen, and that is 
the one place where a user might want to throw an error if, say, he 
knows POV-Ray's color.inc has the potential to undo his flavor or Red. 
But, then maybe, MyBetterThanPOVRayRed is a better name... :-)

Not arguing you couldn't use the functionality, it's just hard for me to 
see the return on investment.

Aside: Even checking the name there is a search order for the file too 
and, if there are multiple files called color.inc available, the next 
feature request will be something about knowing which actual color.inc 
POV-Ray included.

---

I'm thinking, jr, about a keyword_exists() kind of feature.

---

Aside: I'm digging around more on the - since 2015 - ifdef(), ifndef() 
v3.71/v3.8/v4.0 behavior; I noticed when keywords are passed, Christoph 
made updates to some releases to kick out a warning:

Parse Warning:
Trying to test whether a reserved keyword is defined.
Test result may not be what you expect.

(or a similar message depending on releases)

I take it as evidence he was playing with looking at more than IDs - or 
perhaps he realized there was an unintended an unintended behavior he 
needed to back out (a part of it he did for v3.8). For povr I'll likely 
leave the message in place on restoring v3.7 and prior behavior; Users 
can get different results depending on what release code they run on 
testing keywords.

Yep, I need to look at how he made the inbuilt keyword determination for 
the message - there are hidden reserved words too which are not visible 
SDL 'keywords' / reserved words. Msg method might offer a way to an 
iskeyword().

Bill P.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> There IS an obscure built-in identifier (or variable?) called
> View_Include_Stack...

Well... In the light of a new day, I remembered that I had seen that
*somewhere*; it's not an "obscure built-in identifier" :-[  It's just 'a name'
or variable-- part of an #ifdef block at the top of every 'official' POV-ray
include file, with a simple #debug statement:

             #ifdef(View_POV_Include_Stack)
             #debug "including arrays.inc\n"
             #end

It's just a useful/descriptive phrase that someone came up with in the past.
Which explains why adding    #declare View_POV_Include_Stack = true;   at the
top of your main scene file results in a list of those #included files in
'messages'.  Duh. No special magic.

>
> I can't find it in the documentation...
>
...because it's, uh, not part of POV-ray.
>
> Unfortunately, it will not list any user-made #includes-- even if they are
> placed in POV-ray's 'includes' folder; I just tested it. That seems strange.

That's because my personal #include files don't have the added #ifdef block.
Until now, I never gave much thought as to why I should add that. NOW I see why.
It's a good way to see which files might be buried in a large scene with lots of
nested #includes.

I haven't yet tested it to see if it will flag *multiple* instances of the same
#include. That would be useful too.

Post a reply to this message

On 3/21/23 07:43, Kenneth wrote:
> Well... In the light of a new day, I remembered that I had seen that
> *somewhere*; it's not an "obscure built-in identifier" 😅  It's just 'a name'
> or variable-- part of an #ifdef block at the top of every 'official' POV-ray
> include file, with a simple #debug statement:
> 
>               #ifdef(View_POV_Include_Stack)
>               #debug "including arrays.inc\n"
>               #end
> 
> It's just a useful/descriptive phrase that someone came up with in the past.
> Which explains why adding    #declare View_POV_Include_Stack = true;   at the
> top of your main scene file results in a list of those #included files in
> 'messages'.  Duh. No special magic.

With my povr branch I have for a while been set up with two basic 
targeted compiles.

One is a debug option with a lot of extra checking and reporting 
enabled. The other is the day to day rendering version to be used when 
things are going well.

The idea is to use the faster one as a rule.

However, on seeing flaky behavior, or when just wanting to do more 
robust checking of your scene to find what evil is lurking - run the 
debug compile version.

On reading your post I had the thought, why not add some detailed 
include information to the targeted debug compile version of povr. I did 
- and the output currently looks like:

==== [Parsing...] ==============================================
Debug: #include "functions.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/transforms.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/math.inc"
Debug: #include "functions.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/setidtypes.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/vectors.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/vectors.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/math.inc"
Debug: #include "/tmp/otherInc/whackJob.inc"

This information which I'll find useful on occasion too! Oh, the scene 
has only these four includes:

#include "functions.inc"
#include "transforms.inc"
#include "math.inc"
#include "whackJob.inc"

So, the larger reported set is due some of those includes having 
includes too. With well formed include files, only the first in the 
debug output is really used.

On using: #declare View_POV_Include_Stack = 1; we see:

including function.inc
including transforms.inc
including math.inc
including setidtypes.inc
including vectors.inc

We don't see whackJob.inc just above because the guy who wrote it did 
not add the debug code that is in all core shipped include files.

Aside: There are exposures with the View_POV_Include_Stack method in 
that the name reported is whatever is in the debug statement and not 
really the name of the file included. They should align, but...

---

With regards to the #ifdef(), #ifndef(), the povr fork has been reverted 
to v3.7,v3.6 behavior in looking only for declared IDs. With the one 
exception that empty parenthesis now returns false or true, 
respectively, without introducing odd, hard to understand parsing fails 
as a rule.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Aside: There are exposures with the View_POV_Include_Stack method in
> that the name reported is whatever is in the debug statement and not
> really the name of the file included. They should align, but...
>

Yes! I was a 'victim' of that user error myself, while I was testing things :-[
A sloppy cut-and-paste job. I spent half an hour (!) tracking it down, ha.

This old method is certainly not an ideal way to report the presence of a user's
personal #includes. The special code block is 'one more thing' that has to be
added to a file. I probably have several hundred includes of different kinds
that I have written over the years, many written hastily (or even auto-generated
by POV-ray like mesh_2 files.)

Post a reply to this message

On 3/23/23 15:02, Kenneth wrote:
> This old method is certainly not an ideal way to report the presence of a user's
> personal #includes.

Found the new debug compile reporting all the include read attempts has 
an issue too.

Specifically where people use that Parse_String() macro hack. It works 
by creating and including a small include file of the same name, but 
with different contents.

In trying again to debug that flaky csv read file problem from early 
2022 of jr's, I was getting thousands of debug include messages per 
frame of a long animation! So, I commented out that nice debug code I 
just added.

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. :-)

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I was getting thousands of debug include messages ...
> I'm unsure what to do for anything shipped.

a '#pragma [no-]feature-warning;' would be real nice, to get rid (selectively)
of spline + rtr "experimental feature" warnings, for instance :-)


regards, jr.

Post a reply to this message

On 3/24/23 11:36, jr wrote:
> a '#pragma [no-]feature-warning;' would be real nice, to get rid (selectively)
> of spline + rtr "experimental feature" warnings, for instance 😄

Hmm. Yeah, maybe some more general mechanism to turn off messages would 
be helpful(a,b). Features like this will slow down the parser some though.

Bill P.

(a) - The was some support for warning levels for a time, but it's 
eroded on the implementation side over time - unsure if it still works 
at all in fact. Plus, I cannot remember how the level was specified at 
the moment.

(b) - Unrelated to parsing, but for the isosurface only I added a report 
<true/fase> option in povr for gradient messages. The 'report' keyword 
has always intended to be a more general thing which could be used with 
all the shape primitives. Something where, by shape, you can turn 
reporting on and off. I never seem to get back to working on the concept 
though...

Post a reply to this message

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