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
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...
Post a reply to this message