POV-Ray : Newsgroups : povray.unofficial.patches : SDL debugging : Re: SDL debugging Server Time
2 Dec 2022 22:20:41 EST (-0500)
  Re: SDL debugging  
From: Dick Balaska
Date: 24 Feb 2020 23:53:57
Message: <5e54a865$1@news.povray.org>
Am 2/11/20 2:48 PM, also sprach Bald Eagle:

> 
> 1. I would LOVE to have a basic sanity check.  Is there a light source?  Is
> there even a camera?

I can do those, but it seems they should be POV-Ray warnings.

>   Are there any objects in the camera view?  Are there any
> outside the camera view?

That's raytracing. :)  I'm just doing the SDL parser.
You currently get the
"Ray->Shape Intersection          Tests       Succeeded  Percentage"
table.

> 2. globally declared constants, variables, etc.
Yes, it does that.

> 3. Let's suppose you write a bunch of code, or include some files --- do they
> get used?  Is there any way to check for superfluousness?

A list of files that were included is interesting.
They "get used" by virtue of being included.
"superfluousness"? Dude...

> Are there objects that get declared and then not instantiated?

I maybe could do this.  A couple of things.
0) I would have to track the objects, modify the POV-Ray code.
    I am loathe to do that.  Currently I have a one line change
    to all of POV-Ray parser proper: the parser calls
    checkForBreakpoint() after each token. [*1]
1) This would be super messy.  It would require a beefy filter system.
    You really don't want a report that you didn't use DimGrey
    or DimGray or 400 other colors, and woods, etc.
2) What about objects in a macro that gets used multiple times?  Messy.
3) My user base is like 5.  This is a ton of work with not much payback.

*1 And a path through the message system, which was several changes...

> 4. are you using the best/latest version? 

version of what?

> Are you using something that is slow
> or inaccurate when you could be using something that works better/faster?

"something"?

> 5. check for coincident or nearly coincident surfaces.

That's raytracing.

> 6. some sort of "nesting" indicator for showing "where" in the code things went
> haywire.  Are we in a loop, include file, something else?

Define haywire.

> 7. Maybe some kind of magic talisman to ward off infinite loops...  :O

Currently, you can break inside an infinite loop and with the power of 
stepping to the next executed line and watching variables, see what's 
wrong with your loop.

> 
> I'd say that if you're writing a "debugger" - then #1 on my list would be - what
> do people waste hundreds of threads rehashing, and what are the top 20 things
> that people mess up.   The error messages are garbage for the most part.
> "cannot pass uninitialized Lvalue to..."   OK, so WHICH "Lvalue" is
> uninitialized?

I don't get why name, file, line, col isn't part of a lot of error
messages.  Same thing with
'Parse Warning: Should have at least 2 objects in csg.'
Clearly, you have some idea of where you're looking, Mr. Computer.

On the flip side of that, there is now a lot of garbage error messages 
that are not errors.  I get ~50 'Possible Parse Error: Text may not be 
displayed as expected'.  It's so bad I had to turn off errors in 
qtpovray. This messes up my work flow now because "nothing happened. Did 
I press render?  Yes.  [ pause a beat ] Oh, I turned off errors. Turn 
them back on..."

I am very tempted to fix these in POV-Ray.  But then I deviate from 
POV-Ray proper and the odds of getting these fixes into the main tree is 
pretty much 0.

> 
> You get the idea...
> 
> 



-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)


Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.