On 6/13/21 11:18 AM, clipka wrote:
> I think we should very much differentiate between:
> 
> - debugging features aimed at POV-Ray developers, to figure out where we 
> developers slipped up; and
> 
> - debugging features aimed at POV-Ray end users, to figure out where 
> they slipped up.
> 
> Both should be kept entirely separate.
> 
> Most notably, Should we ever want to provide end-users with alternative 
> binaries that they might use to debug their scenes, we MUST stil retain 
> the ability to debug either of those binaries, to diagnose issues that 
> users experience with only one of those.

I agree with the aim. As I implemented the POV_PARSER_SDL_DEBUG it can 
be used alone, with POV_DEBUG by default (because I think it will help 
developers and pseudo developers like me) - but the additional parser 
checking can be excluded for POV_DEBUG builds by setting 
POV_PARSER_SDL_DEBUG to 0 for a POV_DEBUG build.

---
Reality is less clean. I don't know the history, but take the 
#breakpoint parsing code enabled strictly with POV_DEBUG. It effectively 
changes the parser a little in enabling a new keyword for 'developers.'

Fresh in my mind because it's use shifts internal identifier enum values 
due being inserted as a new keyword for POV_DEBUG builds. I've been 
refining povr's new id_type() function and it's more or less the straw 
which prodded me to create a core shipped 'setidtypes.inc' include file 
when I'd intended to leave that job to users.

Also, without 'no lower case identifier checking' users can have an 
already defined 'breakpoint' in their SDL upon which the debug version 
of POV-Ray will now stop with a syntax error.

Wondering if it would be cleaner if #breakpoint was instead a function 
like pov_debug_global_counter() which was always compiled and available? 
Base it upon POV_ULONG instead of unsigned int and we'd have a counter a
step beyond what we can count with 'unsigned int' though still limited 
by the double return. Yeah, I too don't know where we'd need it, but if 
need be, it would be available already in as an SDL function. The 
feature over SDL is it would be a counter that could not be reset / 
mangled by SDL during parsing; It can only count upward and return that 
count.

Rambling: Thinking the passed argument would somehow trigger a developer 
debug counter. Maybe normally pass null/null string, but where a special 
"this_is_Christoph_Lipka" string is used ;-), it would trigger the use 
of a secondary developer 'breakpoint' counter. Don't know, thinking aloud...

Bill P.

Post a reply to this message