POV-Ray : Newsgroups : povray.unofficial.patches : SDL debugging Server Time: 28 Feb 2020 01:56:42 GMT
  SDL debugging (Message 1 to 7 of 7)  
From: Dick Balaska
Subject: SDL debugging
Date: 16 Jan 2020 05:58:04
Message: <5e1ffb6c$1@news.povray.org>
I have written an SDL debugger for qtpovray.

It is still young, but I can set and stop at breakpoints and display the 
values of floats and vectors.

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


Post a reply to this message


Attachments:
Download 'qtpovraydebugging.png' (151 KB)

Preview of image 'qtpovraydebugging.png'
qtpovraydebugging.png


 

From: jr
Subject: Re: SDL debugging
Date: 16 Jan 2020 08:55:00
Message: <web.5e20248b5a35afe68c662f470@news.povray.org>
hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> I have written an SDL debugger for qtpovray.
> It is still young, but I can set and stop at breakpoints and display the
> values of floats and vectors.

v cool[*].

what plans do you have for dealing with objects and/or object identifiers?


regards, jr.


[*] and a bit envious.  :-)  I shelved some project because I couldn't stomach
the mesh/mesh2 parsing it would need.


Post a reply to this message

From: Dick Balaska
Subject: Re: SDL debugging
Date: 17 Jan 2020 00:19:06
Message: <5e20fd7a$1@news.povray.org>
Am 1/16/20 3:53 AM, also sprach jr:

> 
> what plans do you have for dealing with objects and/or object identifiers?

All identifiers are easy.  After I posted, I wished I'd added "White" to 
my Symbol list, which shows its Type as "colour" and Value as 
"<unhandled type>".  POV-Ray has text-name mappings for all types for 
error handling. ("Expected float identifier, found colour indentifier")

For objects,
the QTableWidget I used is the simplest way to display tabular data and 
is just a PoC here.  During my Minecraft wanderings, I wrote Yet Another 
Minecraft Editor.  Minecraft data is not unlike POV-Ray data, a tree of 
random binary types.
http://www.buckosoft.com/yamce/g/resourceTop.png
The point there being, I have a nice tree-table widget.  It is a bear to 
be wrestled with sooner than later.

One major difference, in Minecraft data, each node is named, and carries 
its type so there is no need to know what the object is.  In that 
example, I can change the color of that map banner from orange to red 
without knowing I'm looking at a map banner.  POV-Ray requires intimate 
knowledge of the structure of each of the main objects to display it in 
a tree.  I don't see me wanting to spend the time decoding how to 
display a RAINBOW_TOKEN.

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


Post a reply to this message

From: Dick Balaska
Subject: Re: SDL debugging
Date: 11 Feb 2020 17:10:41
Message: <5e42e011@news.povray.org>
Am 1/16/20 12:58 AM, also sprach Dick Balaska:
> I have written an SDL debugger for qtpovray.
> 

Phase 2, in which Doris gets her oats.

I had fun recursively evaluating arrays of arrays. It was a nice 
challenge.  :)

I can evaluate a camera, but man, evaluating a CSG object is not going 
well. :(

All that wasted space in the lower left. I don't know what to do with 
that.  Originally I had thought a debugger console (a la gdb) but I 
don't need that.

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


Post a reply to this message


Attachments:
Download 'qtpovraydebuggerarrayofarrays.png' (234 KB)
Download 'qtpovraydebuggercameraattrs.png' (19 KB)

Preview of image 'qtpovraydebuggerarrayofarrays.png'
qtpovraydebuggerarrayofarrays.png

Preview of image 'qtpovraydebuggercameraattrs.png'
qtpovraydebuggercameraattrs.png


 

From: Bald Eagle
Subject: Re: SDL debugging
Date: 11 Feb 2020 19:50:06
Message: <web.5e43050e5a35afe64eec112d0@news.povray.org>
Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 1/16/20 12:58 AM, also sprach Dick Balaska:
> > I have written an SDL debugger for qtpovray.

At some point, I'm going to model and render a shrine to you.   :)

> I had fun recursively evaluating arrays of arrays. It was a nice
> challenge.  :)

Have you tried skipping elements and leaving some undefined?

> I can evaluate a camera, but man, evaluating a CSG object is not going
> well. :(

I can see CSG getting very complicated, very quickly.


> All that wasted space in the lower left. I don't know what to do with
> that.

1. I would LOVE to have a basic sanity check.  Is there a light source?  Is
there even a camera?   Are there any objects in the camera view?  Are there any
outside the camera view?
2. globally declared constants, variables, etc.
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?
Are there objects that get declared and then not instantiated?
4. are you using the best/latest version? Are you using something that is slow
or inaccurate when you could be using something that works better/faster?
5. check for coincident or nearly coincident surfaces.
6. some sort of "nesting" indicator for showing "where" in the code things went
haywire.  Are we in a loop, include file, something else?
7. Maybe some kind of magic talisman to ward off infinite loops...  :O

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?

You get the idea...


Post a reply to this message

From: jr
Subject: Re: SDL debugging
Date: 12 Feb 2020 14:15:00
Message: <web.5e4408305a35afe6451952ca0@news.povray.org>
hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 1/16/20 12:58 AM, also sprach Dick Balaska:
> > I have written an SDL debugger for qtpovray.
>
> Phase 2, in which Doris gets her oats.  ...
>
> All that wasted space in the lower left. I don't know what to do with
> that.  ...

a view of the bounding boxes of the scene?  rotatable.  :-)

+1 for BE's point re basic sanity checking.


regards, jr.


Post a reply to this message

From: Dick Balaska
Subject: Re: SDL debugging
Date: 25 Feb 2020 04: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-2008 Persistence of Vision Raytracer Pty. Ltd.