Thomas de Groot <tho### [at] degrootorg> wrote:
> I am a famous re-inventor of wheels if not hopeless
> wanderer through a dark code wood. Still, I prevail in the end! ;-)

Haha, I too reinvent repeatedly. Sometimes I'm *certain* I've done something
before, but just can't remember which .pov file it was in or what it was called.
I've taken to ensuring all new tricks go into documented .inc files in my
include tree, that way I have somewhere to peruse when I'm half-remembering
something. At least once, I've used google on these forums because of something
I posted years ago :)

As to managing large POV-Ray projects - taking a modular approach is something I
favour. Parametrise everything, move blocks into macros, or declarations. If you
start getting too many nested blocks, declaring the inner workings to keep the
containers simple helps. Parsing speed might suffer in some cases, but you can
always optimise later if necessary.

When all else fails, as others have suggested, use the #debug stream to spot
where things start to go wrong. Sometimes I really miss a debugger (I guess one
could always debug the parsing code to see what the input file is doing!).

Bill

Post a reply to this message

Am 28.04.2018 um 12:04 schrieb Stephen:
> 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. :-(

Missing `}`, `#end` or even `)` in an include file are a PITA even from
the POV-Ray developer's point of view: The parser being the ugly mess it
is, it's virtually impossible to do the Pokemon on the various
variations of this theme. No way you can ever catch them all.

And, depending on the particular scenario, they do cause hard crashes.

Post a reply to this message

Same here - a debugger is really needed A LOT, that's how I feel. After
all, POV-Ray's language is to the widest part a programming language
(and yes, I LOVE that language!).

Line-By-Line
Up-To-LineNumber

These two are wildly, passionatly wanted! They will be sweeter than s..
I would say. ;-)

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

Post a reply to this message

Am 29.04.2018 um 03:18 schrieb Sven Littkowski:
> Same here - a debugger is really needed A LOT, that's how I feel. After
> all, POV-Ray's language is to the widest part a programming language
> (and yes, I LOVE that language!).
> 
> Line-By-Line
> Up-To-LineNumber

While I concede it's not as luxurious, we already have tools that can
provide you with that information:

    #debug "I'm here!\n"

and

    #error "Reached that line.\n"

You can even get the same information a call stack could give you:

    #debug "Entering macro FOOBAR\n"
    ...
    #debug "Leaving macro FOOBAR\n"

The /true/ benefit of IDEs is that they allow you to interactively
inspect (and often even modify) the current state of variables. Which
requires an interface to access that information at run-time. Which
requires programming effort. Which requires manpower. Of which
unfortunately we don't have as much as we'd like.

Rest assured however that your suggestion has been noted.

Post a reply to this message

Thanks. :-)

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

Post a reply to this message