Sometimes, when the scene files have become insanely large, and there is
somewhere a logical error in it, it is very hard to find - especially
when having to look at thousands of code lines.

I want to propose a new feature that is standard with most software
compilers: to parse a scene up to a certain selected line (number) only,
or to parse a scene line-by-line.

This way, it would be much easier to locate logical errors.

In my case, I am getting a problem with a macro texture (inside an INC
file) when calling it from my main scene file, but I don't get that
error inside that INC file when using it with a test scene file. Thus,
there must be somewhere an error within the main scene file. It has
thousands of code lines...

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Right - "stepping" through.

As I think has been mentioned before, the editor isn't really part of POV-Ray,
it's a 3rd party windows thing.

Maybe there's some other editor that would allow you to do that, I dunno.

What you can likely do is insert #error directives in your code, wrapped with an
#if

Then you can declare a variable at the top of the scene, and do something like:

#if (Step = 1)
     // some #debug stuff to let you know what's going on.
     // probably best to write a macro to output the desired info
     #error
#end

....
....
....
....

#if (Step = 2)
     ReportMacro()
     #error
#end


Perhaps this is an indication that now is a good place to slow down, and think
through what your code does, and where the problem could be.
What's different about the test scene and the real scene?
Can your real scene code be structured better to make errors more obvious?
Can you send information to the #debug stream to narrow things down?
Are you using a beta version or a stable version?

Make a new scene, and start adding in copy-pasted bits until you experience the
error.   Or comment out sections until the error goes away.

Stepping through the code likely won't help you depending on what the problem
is.

Welcome to debugging.   ;)

Post a reply to this message

On 04/21/2018 08:12 PM, Sven Littkowski wrote:
> Thus,
> there must be somewhere an error within the main scene file. It has
> thousands of code lines...
> 

Thousands of lines in one file is really not a best practice. Surely, 
there must be a way you can break that up. Put objects and/or textures 
in their own files, etc.


(
My movie is 80,000 lines of hand crafted SDL [1] (plus god knows how 
much java-generated foo [2]).  I have 270 files with an average of 309 
lines of code per file.

Plus, to take that a step further, I organize subprojects by directory.
ttlo - the launch scene
ttvo - the cave scene
ttCommon - globals

My main scene file contains just the directives to get things started.
Now I'm working on my space scene, ttso.
   #declare TTSODIR="./";
   #declare TTLODIR="../ttlo";
   #declare TTCOMMONDIR="../ttCommon/";


Those are specific for rendering from *that* directory.
Then I have a pile of includes

   #include concat(TTCOMMONDIR, "ttGlobals.inc") // global positions
   #include concat(TTSODIR, "direct.inc")     // timings for this scene
   #include concat(TTLODIR, "spaceLoco.inc")  // I built him over there
   #include concat(TTSODIR, "world.inc")      // put objects in the scene

This list of includes can be pasted anywhere because I've abstracted out 
the actual directory.

I can comment out spaceLoco.inc and it still renders because in 
world.inc is this construct:

   #ifdef (SpaceLoco)
     object {
       SpaceLoco
       rotate    SpaceLocoRot
       translate SpaceLocoVec
     }
   #end

With 1000s of lines, you *will* get lost, and it helps immensely to have 
some organization.

Another trick I do is, near the top of each object include I have
   #ifndef (HausDoorOpen)
     #declare HausDoorOpen=0;  // normally closed
   #end

Then if I don't bother to define a needed symbol, the object takes care 
of that himself.

*Plus* :)  HausDoorOpen runs from 0 to 1. All of my public symbols do.
Then, in the object file I deal with it as needed.
   #local doorClosed =  90;
   #local doorOpen   = 210;
   #local doorRot = HausDoorOpen*(doorOpen-doorClosed)+doorClosed;
   rotate y*doorRot

Then if I decide doorOpen looks better at 200, I don't have to change 
everybody that uses it. I only have to change it in that one place. 
Everybody else just cares that it's open or not.

)

[1] http://git.buckosoft.com/gitstats/tteoac/files.html
[2] ex: 
http://www.buckosoft.com/tteoac/tteoac/service?scene=ttlo!fps=23.976!type=Thrust!frame=346
-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Thanks for the suggestions, they are justified, I agree.

But even so, it would be useful to have such a step-parser feature.

In regards to my problem, I came already to the same conclusion and
stored the main text amount in a new file, copied only piece by piece
into the original file, and found finally the error. Still not sure how
to fix it. I will create a new thread in this sub group about it, so
look out. It will be named "Macro Problem".

Hoping for the step-parser.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Le 18-04-21 à 22:19, dick balaska a écrit :
> On 04/21/2018 08:12 PM, Sven Littkowski wrote:
>> Thus,
>> there must be somewhere an error within the main scene file. It has
>> thousands of code lines...
>>
> 
> Thousands of lines in one file is really not a best practice. Surely, 
> there must be a way you can break that up. Put objects and/or textures 
> in their own files, etc.
> 
> 
> (
> My movie is 80,000 lines of hand crafted SDL [1] (plus god knows how 
> much java-generated foo [2]).  I have 270 files with an average of 309 
> lines of code per file.
> 
> Plus, to take that a step further, I organize subprojects by directory.
> ttlo - the launch scene
> ttvo - the cave scene
> ttCommon - globals
> 
> My main scene file contains just the directives to get things started.
> Now I'm working on my space scene, ttso.
>    #declare TTSODIR="./";
>    #declare TTLODIR="../ttlo";
>    #declare TTCOMMONDIR="../ttCommon/";
> 
> 
> Those are specific for rendering from *that* directory.
> Then I have a pile of includes
> 
>    #include concat(TTCOMMONDIR, "ttGlobals.inc") // global positions
>    #include concat(TTSODIR, "direct.inc")     // timings for this scene
>    #include concat(TTLODIR, "spaceLoco.inc")  // I built him over there
>    #include concat(TTSODIR, "world.inc")      // put objects in the scene
> 
> This list of includes can be pasted anywhere because I've abstracted out 
> the actual directory.
> 
> I can comment out spaceLoco.inc and it still renders because in 
> world.inc is this construct:
> 
>    #ifdef (SpaceLoco)
>      object {
>        SpaceLoco
>        rotate    SpaceLocoRot
>        translate SpaceLocoVec
>      }
>    #end
> 
> With 1000s of lines, you *will* get lost, and it helps immensely to have 
> some organization.
> 
> Another trick I do is, near the top of each object include I have
>    #ifndef (HausDoorOpen)
>      #declare HausDoorOpen=0;  // normally closed
>    #end
> 
> Then if I don't bother to define a needed symbol, the object takes care 
> of that himself.
> 
> *Plus* :)  HausDoorOpen runs from 0 to 1. All of my public symbols do.
> Then, in the object file I deal with it as needed.
>    #local doorClosed =  90;
>    #local doorOpen   = 210;
>    #local doorRot = HausDoorOpen*(doorOpen-doorClosed)+doorClosed;
>    rotate y*doorRot
> 
> Then if I decide doorOpen looks better at 200, I don't have to change 
> everybody that uses it. I only have to change it in that one place. 
> Everybody else just cares that it's open or not.
> 
> )
> 
> [1] http://git.buckosoft.com/gitstats/tteoac/files.html
> [2] ex: 
>
http://www.buckosoft.com/tteoac/tteoac/service?scene=ttlo!fps=23.976!type=Thrust!frame=346

> 

What if you get an error in file 153 that is caused by a flaw in file 73?
Having smaller files won't help in this case, and it's a case that can 
happen very easily.

Post a reply to this message

On 04/26/2018 02:13 PM, Alain wrote:
> 
> What if you get an error in file 153 that is caused by a flaw in file 73?
> Having smaller files won't help in this case, and it's a case that can 
> happen very easily.

It's actually a case that happens a lot. Usually when I forget an #end.
In this case, I figure file 153 hasn't changed in years, and file 73 is 
what I'm working on, so start there.  Sometimes I have to git diff for a 
good visual clue where the missing #end is.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:

> It's actually a case that happens a lot.

Yeah, I've run into this issue with closing curly braces }

That's why I really double-down on structuring my code with noticeable
indentations, comments on closing braces and #ends, and embedding #debug code
blocks into the various sections.

Embedding "opening" and "closing" #debug messages for macros and include files,
writing values of arguments passed to these to the #debug stream, and the
results of critical intermediate and final calculations can be a huge help in
tracking down what went wrong, where, and why.

Don't start writing your cvode assuming it's going to work - write it assuming
it's going to go horribly wrong, and 3 weeks from now when you can't even
recognize it as your own code or remember what you did or why --- you're going
to be SO thankful for those comments and helpful debugging features.  :)

Post a reply to this message

I like that philosophy: assume your code goes horribly wrong.

But my suggestion for a Line-By-Line step parsing and for a
Until-Line-Number step parsing remains. Needed. And such a feature would
give much more convenience and support to the user.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

On 27-4-2018 13:57, Bald Eagle wrote:
> dick balaska <dic### [at] buckosoftcom> wrote:
> 
>> It's actually a case that happens a lot.
> 
> Yeah, I've run into this issue with closing curly braces }

Don't get me started!

> 
> That's why I really double-down on structuring my code with noticeable
> indentations, comments on closing braces and #ends, and embedding #debug code
> blocks into the various sections.
> 
> Embedding "opening" and "closing" #debug messages for macros and include files,
> writing values of arguments passed to these to the #debug stream, and the
> results of critical intermediate and final calculations can be a huge help in
> tracking down what went wrong, where, and why.
> 
> Don't start writing your cvode assuming it's going to work - write it assuming
> it's going to go horribly wrong, and 3 weeks from now when you can't even
> recognize it as your own code or remember what you did or why --- you're going
> to be SO thankful for those comments and helpful debugging features.  :)

Oh Boy! Each time I swear to do that and, of course, forget during the 
next project. I am a famous re-inventor of wheels if not hopeless 
wanderer through a dark code wood. Still, I prevail in the end! ;-)

But, seriously, yes. The best advice to anybody indeed. I am now, when I 
revisit an older scene, checking the state of the comments and add them 
lavishly when necessary; taking out well-documented code snippets for 
later use, etc.

The best checker is yourself.

-- 
Thomas

Post a reply to this message

On 28/04/2018 07:56, Thomas de Groot wrote:
> On 27-4-2018 13:57, Bald Eagle wrote:
>> dick balaska <dic### [at] buckosoftcom> wrote:
>>
>>> It's actually a case that happens a lot.
>>
>> Yeah, I've run into this issue with closing curly braces }
> 
> Don't get me started!

#end for me atm. :-(


-- 

Regards
     Stephen

Post a reply to this message