William F Pokorny <ano### [at] anonymousorg> wrote:

> The few 'keywords' I've tested these generate a warning in at least some
> versions of POV-Ray. But it's weird, keywords NOT returning immediate
> numbers or strings are also considered 'defined' in these versions
> though they are in fact arbitrary SDL keywords.

I think you're going to run into the same hamstringing that an over-concern
about backwards compatibility inevitably results in.  If any of this stuff is
going to be fixed, there needs to be a clean break, and a sane, logical,
rational, basis for moving forward.

> Even this worked in the pre-backed off v3.8 release parser:
> #ifdef(#declare V=99;#undef V)
> Though without some other mistake it would usually die with a later
> unmatched something parsing fail.

That looks fine - given someone may have some reason to do that.  Some sort of
quick bypass workaround.


> I will always die if somebody tries use the undef'd V.

Yes.  Because V is for Victory, and undefining it results in Failure.  :P

> So, much more was being supported as testing true in povr/v4.0, but
> still not some things like raw vectors. Though things like x,y,z are OK.

.....

> Further, the extra now being
> changed currently in the v3.8 code is not consistent with respect to
> things like pi - which to the parser is an immediate value of pi. And
> datetime would be an example of an immediate string which would test
> true, you'd think, if "string" does.
>
> What to do... I could spend a lot of time trying to figure out the
> history here, but I think the current state not completely tenable since
> 2015...
>
> We need functionality which deals only with IDs.
>
> We, perhaps, need some sort of what is in the parenthesis is 'defined'
> functionality too, but the generic sort being allowed or not seems
> questionable to me. Are people already using this functionality?

I use and abuse whatever I can find as a workaround for lack of functionality.
I absolutely don't mind rewriting code to perform with a new and better version.

Currently trying to implement some geometric testing code, it's becoming
increasingly clear that we have plenty of raytracing capability, and missing
programming code to make coding the scenes easier and more capable.

Example:
I'm testing for an intersection.  What do I do in SDL if there's a) none, or b)
more than 1?   Or if I'm looking at parallel or skew lines.  Or the user or the
circumstances require the endpoints of a line to be the same (a point)?

I'm dreaming up workarounds like mixed arrays with succeed/fail flags followed
by the variable number of results (line/line | line/circle | circle/circle).
For data type cast, I'm thinking I need a 2D mixed array with the [0] holding
the data type as a string, and the actual data in the 1[].

It would be so much easier to code these things (and faster) if we had some
tools to deal with variable results.

null, NaN, variable type detection, error trapping, etc.
It would make testing with #ifdef a little more sane if #ifdef (keyword)
returned a versatile value that I could make use of in a broad number of
circumstances.

First - I think POV-Ray needs to sort out keywords vs values, scalars vs
vectors, vs parse/render/function space variable names.  It's confusing, and is
contributing directly to the mess you're trying to sort out. You can't.  It's
all inextricably mixed.  clipka correctly pointed out that all of this stuff
needs to get disentangled in the parser.

So, I would say that "if" should return a value that denotes keyword,
whereas "pi" should return a value that denotes a reserved value.  "CONST", or
whatever that compiler one is.  "PRAGMA"

It's "nice" that I can swizzle things all over the place between vectors and
colors, etc.  But it makes for lazy / bad programming practices.  Better the
ability to recast a value from a scalar to a vector to a color, etc.

It would probably take me a month, tops, to adapt to the new requirements, and
I'd be able to write better, shorter, more easily understood and maintained
code.  Further, if there were sufficient programmatic capability, "fixes" for
old scenes could be coded, much like TOK and I code custom functions and macros
to handle pow (0, 0), factorial, N choose M, mod () crossing the origin, etc.
Just change the keyword in the old scene to a capitalized version ("We love you,
jr!") and boom - you have a macro that could possibly handle a lot of the
backward compatibility with a simple find/replace on the old scene file.

The first rule of holes is: when you find yourself in one, stop digging.
The second is: climb out.

I'd rather suffer now, and profit later.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>

Thanks for doing such a detailed series of tests and an examination of the
various code versions! I can imagine that it was a lot of drudgery.

> I think we need to start with the fact #ifdef, #ifndef and #undef have
> ALWAYS been #ifIdDefined, #ifIdNotDefined and #undefineId. Going back to
> the v3.6 documentation we have:
> [clip]
>
> We need functionality which deals only with IDs.
>
> ...but the generic sort being allowed or not seems
> questionable to me.

I agree; IMO, #ifdef etc. should adhere to the much more strict behavior
described in the docs. Admittedly, I am not as sophisticated a user of these
functions as some others are, but the current behavior seems quite lax and could
lead to unintended scene errors or coding 'mysteries'.

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.

I also think that using an *actual* zero or a float (while having some meaning
as boolean values) does not really represent a 'valid ID' as per docs, and so
should fail outright as well. My opinion ;-) HOWEVER... I can see a scenario
where 0 or 1 could be used simply to test whether a scene's specific #ifdef
construct is working properly or not-- in other words, without relying on an
actually-defined identifier for the test. On the other hand...it would be a
simple matter to pre-define a temp dummy identifier for the same use.

> Christoph went on to add a bunch of inbuilt keywords to be considered
> 'defined' sometime after late November 2018 - which makes me begin to
> think he too might have been considering these *def keywords in the
> c/c++ coding, macro test sense.

Actually, it's not clear to me why any keywords at all would or should be valid
'parameters' for an #ifdef comparison-- but I'm rather naive at present about
what might be such a useful coding scenario. For example, my own rather
meaningless(?) test of
               #ifdef(true)
appears to be a flat-out mistaken use of the function, since the comparison will
(or rather, *should*) always invoke the first clause, never the #else. In other
words, this construct should use #if or #while or #switch or etc, not #ifdef.

I am obviously not seeing why a keyword could be meaningfully used there.


----------
In general, I think that most of not all of the non-fatal error messages re:
#ifdef should be changed to fatal-- if only as a guard against using entities
that don't belong there and need changing. Personally, I'm lazy about taking
note of non-fatal messages.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Actually, it's not clear to me why any keywords at all would or should be valid
> 'parameters' for an #ifdef comparison ...

one use I see, though I have never tried/used it, is determining whether a given
keyword (already) exists in the POV-Ray version doing the parsing; if it worked
for, eg, 'tau'.  also, fwiw, agree that parsing (generally) should be "strict".


regards, jr.

Post a reply to this message

Le 2023-03-19 à 10:41, Bald Eagle a écrit :
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>> Given the current mix of flaws, the use of a string literal still has me
>> scratching my head...
>>          #ifdef("...string...")
>>
>> Alain's and JR's explanation of the expected behavior seems valid; but with a
>> properly-working #ifdef, should the comparison fail outright (fatal error)? Or
>> should it still be seen as defined? I'm mostly just curious ;-)
> 
> One might suggest:
> "Expected variable name, literal value found instead."
> 
> -or- "It is what is is." ;)
> 
> 
> 
> 
> The correct answer for me has always been OPTIONS.
> 
> When everything gets locked into a one-right-answer only format, it usually just
> creates new problems in the process of "solving" the old.
> 
> I was just reading some old threads concerning this type of thing, and the
> degenerate triangle warning vs 0-length fatal error for cylinders was brought
> up.
> 
> For some scenes it could be a critical thing to stop the render.   For others,
> you might want to just ignore them all.  Usually these things are addressed by
> the users with workarounds, but why not have a configuration file that states
> how to handle these cases, an additional argument for the object instantiation
> that provides for individual control, or an error-trapping mechanism (with error
> code) that allows the user to write their own programmatic/logical solution
> based on further testing and flow control, and allows the user to issue better
> warnings that the cryptic ones currently hard-coded in source?
> 
> 
> 

Or even a global_settings entry, such as :
Ignore_degenerate true|false //default to false

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > Actually, it's not clear to me why any keywords at all would or should
> > be valid 'parameters' for an #ifdef comparison ...
>
> one use I see, though I have never tried/used it, is determining whether a given
> keyword (already) exists in the POV-Ray version doing the parsing; if it worked
> for, eg, 'tau'.
>

Ah! Yes, I see the usefulness of that. Thanks. That totally escaped me. My
#ifdef(true) example was a bad choice to illustrate the situation.

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

Post a reply to this message

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