On 10/22/23 10:36, Bald Eagle wrote:
> I've experimented with tracking the nesting level of the SDL code in the 
> past, and maybe there's a way to make that visible to the SDL from 
> within source without slowing things down / adding too much overhead.

Unsure in total, what sort of tracking you mean, but...

I did take a run in povr at a debug option for the include files and it 
is still available via the environment variable: 
POV_PARSER_File_Text_INC_DEBUG, but with scenes making use of the 
parse_string / Parse_String macro for dynamic SDL code it's unusable as 
one drowns in debug output so it isn't today a run time povr option.

It's on my list to create a parse_string feature which doesn't use the 
include file mechanism, but some sort of 'memory file' instead.

> Also, I'm wondering if in your povr branch, you could try addressing the 
> highly ambiguous "#end" directive and switching over to #endif #endfor 
> etc. 

Yeah, I find myself typing #endif all the time when coding SDL! It's not 
all that easy to implement differing 'end tokens' unfortunately; So, 
it's not a near term povr work item.

> Since you're coding source (in C? c++?), it would be interesting to 
> hear your "ramblings" on the types of data structures and code-flow 
> directives we're currently missing in SDL that you think would be of 
> use. 

:-) Expect the list here goes on for a while and general 'list' (c++ 
vector) support one feature I'd like(*). I'll leave further rambling on 
this topic for another day.

(*) Some work has been done in this direction by jr and others with 
include files.

> Great work tracking down these parse errors. They can seriously 
> challenge one's sanity when trying to debug scenes in SDL.

Thanks & agree (my sanity is questionable as is).

Took a quick look at your reference to the kumiko triangles project and 
I realize I didn't test 'deprecated' or the 'global', 'local' pseudo 
dictionaries with tuple assignments. The combinations go on and on...

-----
With the pseudo dictionaries my current recommendation would be to use 
only in #macro 'local.' ones.

On writing that, I had the thought we can, I think, implement a 
trustworthy 'global.' test, at least, inside macros with something like:

#if ((!defined(local.V123)) & (defined(V123)))
...
#end

Pending fixes / changes, I'd say stay away 'global' altogether and use 
'local' only within macros for conditional tests or references. Further, 
don't do any assignment / redefinition / undef of identifiers via the 
'global' and 'local' dictionaries.

In povr, wondering if I can make 'global' pseudo dictionary use a parse 
error for now... I worry about where I have myself used it. I know it's 
there in povr's shipped munctions.inc and setidtypes.inc includes. 
Probably none of my 'global' use is absolutely necessary in those though.

What if, we change the expected and documented behavior from:

"Included are the two pseudo-dictionaries local and global they 
represent the most local and the least local or global identifiers 
respectively."

to be:

"Included are the two pseudo-dictionaries local and global, they 
represent the most local and the scene's top file's identifiers 
respectively."

???

The latter is closer to what we have today by implementation. Then we'd 
probably need a new way(s) to create / modify / undef identifiers which 
strictly works with the top file's identifiers. A #top V123 = 123; which 
would bypass any identifier name masking.

The 'least local' which are not today (always?) in the global dictionary 
could be isolated with the code posted above or

#if ((!defined(global.V123)) & (!defined(local.V123)) & (defined(V123)))
...
#end

depending on needs.

Hmm. Is that enough to handle aimed modifications. Maybe, yes, except 
where the #local masking is more than one instance deep(a), but we 
probably don't much need to whack the intermediate locals. They go away 
when we exit the macro or file context, so undef useless there really - 
and redefinition too seems unlikely excepting maybe as a way to 'return 
values' from a included file's context(a).

(a) - There is sort of a "most global, not top level" class of 
identifiers possible too I guess.

I don't know. Thinking aloud...

Might be simpler to fix the bug / match what is documented for behavior, 
but it leaves the pseudo dictionaries as less of a solution to 
identifier name masking than perhaps they could be.

Bill P.

Post a reply to this message