 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Dick Balaska <dic### [at] buckosoft com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
Preview of image 'qtpovraydebuggercameraattrs.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
