or am I just plain dense

Consider the following piece of code
Including a datafile in the main body works, but
including it inside a #macro results in an error
at random frames in the animation. It can be at
frame 10 or at frame 500.
Content of data.inc looks like this

#declare CFS[0] = <45.139115, 100.000000, 18.290612>;
.
.
#declare CFS[49] = <44.641327, 100.000000, 17.771019>;

// CODE

#version 3.7;

#declare CenterOfMass = yes;
#declare COMF = 50;
#declare StartLookAt = <0, 80, 0>;
#declare CFS = array[COMF];
#declare LookAt =  <500, 100, 0>;
#declare CenterOfMassLookAt =  <0, 0, 0>;


#macro WriteCOMFile()

  #fopen filehandle "data/data.inc" write
  #for(Count, 0, COMF-1, 1)
    #write(filehandle, "#declare CFS[",str(Count,0,0),"] = <", vstr(3, 
CFS[Count], ", ", -1,-1),">;\n")
  #end
  #fclose filehandle
#end

#macro InitCenterOfMass()
  #for(Count,0, COMF-1, 1)
    #declare CFS[Count] = StartLookAt;
  #end
  WriteCOMFile()
#end

#macro ParseCenterOfMass(NewCenter)

// Including the data file here works sometimes

//#include "data/data.inc"

  #for(Count, COMF-1, 1, -1)
    #declare CFS[Count] = CFS[Count-1];
  #end
  #declare CFS[0] = NewCenter;
  WriteCOMFile()
  #local COMLookAt = <0, 0, 0>;
  #declare Count = 0;
  #for(Count, 0, COMF-1, 1)
    #local COMLookAt = COMLookAt + CFS[Count];
  #end
  #local COMLookAt = COMLookAt / COMF;
  #declare CenterOfMassLookAt =  COMLookAt;
#end

#if(frame_number=0)
    InitCenterOfMass()
#end


#declare CameraLocation = < 900, 800,-2900>;
#declare Direction = 1;


// Including the data file here works all the time
#include "data/data.inc"



#if(frame_number=1)
  #declare LookAt =  ParseCenterOfMass(StartLookAt);
#else
  ParseCenterOfMass(LookAt)
  #declare LookAt = CenterOfMassLookAt;
#end
#declare Direction = vlength(CameraLocation-LookAt)/2000;

  camera {
    location CameraLocation
    look_at LookAt
    direction z * Direction
    right image_width / image_height * x
  }

-- 

Ger

Post a reply to this message

Am 17.01.2016 um 20:43 schrieb Ger:

> Consider the following piece of code
> Including a datafile in the main body works, but
> including it inside a #macro results in an error
> at random frames in the animation. It can be at
> frame 10 or at frame 500.

It certainly isn't intended behaviour, otherwise it would give you an
error all the time ;)

Can you be more specific about the error message you get? Version and
operating system might also play a role.

Post a reply to this message

clipka wrote:

> Am 17.01.2016 um 20:43 schrieb Ger:
> 
>> Consider the following piece of code
>> Including a datafile in the main body works, but
>> including it inside a #macro results in an error
>> at random frames in the animation. It can be at
>> frame 10 or at frame 500.
> 
> It certainly isn't intended behaviour, otherwise it would give you an
> error all the time ;)
> 
> Can you be more specific about the error message you get? Version and
> operating system might also play a role.

Povray V3.7 running on  Opensuse 13.2

Error message is all over the field and makes zero sense to me.
Error at line 249 (or any other bizarre line number, file only has 51 lines) 
in data.inc. Expected {fill in whatever }, found {fill in whatever} instead
Or it stops with a "mismatched #end"

I have ran it with array sizes from only 5 lines to 15K lines and that 
doesn't make a difference in either error message or frame number when it 
crashes.

-- 

Ger

Post a reply to this message

Am 17.01.2016 um 22:55 schrieb Ger:
> clipka wrote:
> 
>> Am 17.01.2016 um 20:43 schrieb Ger:
>>
>>> Consider the following piece of code
>>> Including a datafile in the main body works, but
>>> including it inside a #macro results in an error
>>> at random frames in the animation. It can be at
>>> frame 10 or at frame 500.
>>
>> It certainly isn't intended behaviour, otherwise it would give you an
>> error all the time ;)
>>
>> Can you be more specific about the error message you get? Version and
>> operating system might also play a role.
> 
> Povray V3.7 running on  Opensuse 13.2

Um... /what/ version of POV-Ray 3.7? 3.7.0 stable? 3.7.1-alpha.7678995?
3.7.1-alpha.8433080?

Did you build it yourself, or did you get it as binary via some package
manager?

> Error message is all over the field and makes zero sense to me.
> Error at line 249 (or any other bizarre line number, file only has 51 lines) 
> in data.inc. Expected {fill in whatever }, found {fill in whatever} instead
> Or it stops with a "mismatched #end"

That /certainly/ is a bug, though I have no initial idea what might be
going wrong there.

> I have ran it with array sizes from only 5 lines to 15K lines and that 
> doesn't make a difference in either error message or frame number when it 
> crashes.

Can you provide me with a complete scene file (attachment please;
pasting into a newsgroup post tends to break things due to line wrapping
and the like)?

Post a reply to this message

clipka wrote:

> Am 17.01.2016 um 22:55 schrieb Ger:
>> clipka wrote:
>> 
>>> Am 17.01.2016 um 20:43 schrieb Ger:
>>>
>>>> Consider the following piece of code
>>>> Including a datafile in the main body works, but
>>>> including it inside a #macro results in an error
>>>> at random frames in the animation. It can be at
>>>> frame 10 or at frame 500.
>>>
>>> It certainly isn't intended behaviour, otherwise it would give you an
>>> error all the time ;)
>>>
>>> Can you be more specific about the error message you get? Version and
>>> operating system might also play a role.
>> 
>> Povray V3.7 running on  Opensuse 13.2
> 
> Um... /what/ version of POV-Ray 3.7? 3.7.0 stable? 3.7.1-alpha.7678995?
> 3.7.1-alpha.8433080?
> 
> Did you build it yourself, or did you get it as binary via some package
> manager?
> 
>> Error message is all over the field and makes zero sense to me.
>> Error at line 249 (or any other bizarre line number, file only has 51
>> lines) in data.inc. Expected {fill in whatever }, found {fill in whatever}
>> instead Or it stops with a "mismatched #end"
> 
> That /certainly/ is a bug, though I have no initial idea what might be
> going wrong there.
> 
>> I have ran it with array sizes from only 5 lines to 15K lines and that
>> doesn't make a difference in either error message or frame number when it
>> crashes.
> 
> Can you provide me with a complete scene file (attachment please;
> pasting into a newsgroup post tends to break things due to line wrapping
> and the like)?
Persistence of Vision(tm) Ray Tracer Version 3.7.1-alpha.7695039.unofficial 
(g++
 4.8 @ x86_64-suse-linux-gnu)
This is an unofficial version compiled by:
 Pietje Puk <p.p### [at] gmailcom>
 The POV-Ray Team is not responsible for supporting this version.


Support libraries used by POV-Ray:
  ZLib 1.2.8, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
  LibPNG 1.6.13, Copyright 1998-2012 Glenn Randers-Pehrson
  LibJPEG 80, Copyright 1991-2013 Thomas G. Lane, Guido Vollbeding
  LibTIFF 4.0.4, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
  Boost 1.54, http://www.boost.org/
  OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.



2 files attached

As I was typing this reply the next error message come up

File 'data.inc' line 169: Parse Error: Expected 'object or directive', ] 
found
 instead
Fatal error in parser: Cannot parse input.
Render failed

There is no line 169
-- 

Ger

Post a reply to this message

Attachments:
Download 'us-ascii' (6 KB) Download 'us-ascii' (1 KB)

Am 17.01.2016 um 23:43 schrieb Ger:

> Persistence of Vision(tm) Ray Tracer Version 3.7.1-alpha.7695039.unofficial 

Uh... that's 17 months old. Ever thought of trying a newer version?

> (g++
>  4.8 @ x86_64-suse-linux-gnu)
> This is an unofficial version compiled by:
>  Pietje Puk <p.p### [at] gmailcom>
>  The POV-Ray Team is not responsible for supporting this version.

I take it "Pietje Puk" is not the real name of whoever built the binary
-- which in turn leads me to presume that you built it yourself.

Post a reply to this message

clipka wrote:

> Am 17.01.2016 um 23:43 schrieb Ger:
> 
>> Persistence of Vision(tm) Ray Tracer Version
>> 3.7.1-alpha.7695039.unofficial
> 
> Uh... that's 17 months old. Ever thought of trying a newer version?

I have thought of it, but somehow never got around to it.

Okay, got the latest? stable version
built it, and guess what. It doesn't accept the -CC option
Ran the render with the #include data.inc inside the macro  and it did the 
same thing.
Random errors on non-existing line numbers.
> 
>> (g++
>>  4.8 @ x86_64-suse-linux-gnu)
>> This is an unofficial version compiled by:
>>  Pietje Puk <p.p### [at] gmailcom>
>>  The POV-Ray Team is not responsible for supporting this version.
> 
> I take it "Pietje Puk" is not the real name of whoever built the binary
> -- which in turn leads me to presume that you built it yourself.

It's the first version with the -CC option (no povstatefile) that I 
requested.



-- 

Ger

Post a reply to this message

Ger wrote:

Forgot the version info

Persistence of Vision(tm) Ray Tracer Version 3.7.0.unofficial (g++ 4.8 @
 x86_64-unknown-linux-gnu)
This is an unofficial version compiled by:
 Pietje Puk <p.p### [at] gmailcom>
 The POV-Ray Team is not responsible for supporting this version.

Support libraries used by POV-Ray:
  ZLib 1.2.8, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
  LibPNG 1.6.13, Copyright 1998-2012 Glenn Randers-Pehrson
  LibJPEG 80, Copyright 1991-2013 Thomas G. Lane, Guido Vollbeding
  LibTIFF 4.0.4, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
  Boost 1.54, http://www.boost.org/
  OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.


Btw, Pietje Puk is my alter ego :)
-- 

Ger

Post a reply to this message

Ger wrote:

> Ger wrote:
> 
> Forgot the version info
> 
> Persistence of Vision(tm) Ray Tracer Version 3.7.0.unofficial (g++ 4.8 @
>  x86_64-unknown-linux-gnu)
> This is an unofficial version compiled by:
>  Pietje Puk <p.p### [at] gmailcom>
>  The POV-Ray Team is not responsible for supporting this version.
> 
> Support libraries used by POV-Ray:
>   ZLib 1.2.8, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
>   LibPNG 1.6.13, Copyright 1998-2012 Glenn Randers-Pehrson
>   LibJPEG 80, Copyright 1991-2013 Thomas G. Lane, Guido Vollbeding
>   LibTIFF 4.0.4, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
>   Boost 1.54, http://www.boost.org/
>   OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.
> 
> 
> Btw, Pietje Puk is my alter ego :)

Got the latest? Master
Persistence of Vision(tm) Ray Tracer Version 3.7.1-alpha.8431458.unofficial 
(g++
 4.8 @ x86_64-suse-linux-gnu)
This is an unofficial version compiled by:
 Pietje Puk <p.p### [at] gmailcom>
 The POV-Ray Team is not responsible for supporting this version.

Support libraries used by POV-Ray:
  ZLib 1.2.8, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
  LibPNG 1.6.13, Copyright 1998-2012 Glenn Randers-Pehrson
  LibJPEG 80, Copyright 1991-2013 Thomas G. Lane, Guido Vollbeding
  LibTIFF 4.0.4, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
  Boost 1.54, http://www.boost.org/
  OpenEXR 2.2.0 and IlmBase 2.2.0, Copyright (c) 2002-2011 Industrial Light &
 Magic.

Same deal, but this one does support -CC

-- 

Ger

Post a reply to this message

On 1/17/2016 5:43 PM, Ger wrote:

> As I was typing this reply the next error message come up
>
> File 'data.inc' line 169: Parse Error: Expected 'object or directive', ]
> found
>   instead
> Fatal error in parser: Cannot parse input.
> Render failed
>
> There is no line 169
>

I ran your render and only got to frame 21:

"data.inc" line 218: Parse Error: Illegal character in input file, value 
is 85.

(I had to change #if (frame_number=0) to =1 to seed data.inc)

It smells like a bizarre race condition to me.  How about trying 
separate data files per frame?
#include concat("data", str(frame_number,0,0), ".inc")

Post a reply to this message

dick balaska wrote:

> On 1/17/2016 5:43 PM, Ger wrote:
> 
>> As I was typing this reply the next error message come up
>>
>> File 'data.inc' line 169: Parse Error: Expected 'object or directive', ]
>> found
>>   instead
>> Fatal error in parser: Cannot parse input.
>> Render failed
>>
>> There is no line 169
>>
> 
> I ran your render and only got to frame 21:
> 
> "data.inc" line 218: Parse Error: Illegal character in input file, value
> is 85.
> 
> (I had to change #if (frame_number=0) to =1 to seed data.inc)
> 
> It smells like a bizarre race condition to me.  How about trying
> separate data files per frame?
> #include concat("data", str(frame_number,0,0), ".inc")

I had already tried that and it does exactly the same thing. Maybe with other 
frame numbers but the same error messages on the same non-existing line 
numbers.

-- 

Ger

Post a reply to this message

On 18-1-2016 8:08, Ger wrote:

> Btw, Pietje Puk is my alter ego :)
>

LOL (strictly for Dutch)

-- 
Thomas

Post a reply to this message

Ger <No.### [at] ThankYou> wrote:
> clipka wrote:
>
> > Am 17.01.2016 um 23:43 schrieb Ger:
> >
> >> Persistence of Vision(tm) Ray Tracer Version
> >> 3.7.1-alpha.7695039.unofficial
> >
> > Uh... that's 17 months old. Ever thought of trying a newer version?
>
> I have thought of it, but somehow never got around to it.
>
> Okay, got the latest? stable version
> built it, and guess what. It doesn't accept the -CC option
....

> It's the first version with the -CC option (no povstatefile) that I
> requested.

Dang, I was just about to ask what the "-CC" option is... do remember now.
Send a few round tuits my way and I'll have a look at both issues.

Post a reply to this message

Ger <No.### [at] ThankYou> wrote:
> Ger wrote:
>
> Forgot the version info
>
> Persistence of Vision(tm) Ray Tracer Version 3.7.0.unofficial (g++ 4.8 @

Ah, okay... THAT is NOT the lastest version, so no surprise about the "-CC"
option.

You want the "master" branch, not anything else. Looks like you downloaded the
"stable" branch, or the only official release. Which boils down to the same.

Post a reply to this message

El 17/01/16 a las 23:43, Ger escribió:
> There is no line 169

   I guessed it doesn't means line 169 on data.inc, but on test.pov... 
that is, on the ParseCenterOfMass macro.

   After some tests making changes to that macro, the errors seemed to 
suggest that sometimes data.inc was not fully written when it was 
included in that macro.

   So I tried moving the call to include data.inc outside the macro, and 
worked just fine. BTW, judging by the line 162 seems you already tried that?

--
jaime

Post a reply to this message

El 18/01/16 a las 13:26, Jaime Vives Piqueres escribió:
>    So I tried moving the call to include data.inc outside the macro, and
> worked just fine. BTW, judging by the line 162 seems you already tried
> that?

   Sorry, I see now that indeed you tried, and that was the original 
question: why it works outside the macro but not inside.

   Anyhow, I did a test putting the macro in a separate include file, 
and now at least the error message isn't random anymore: it's always 
"Attempt to access uninitialized array element" on this line:

   #declare CFS[Count] = CFS[Count-1];

   But as data.inc is included and has valid #declares, that cannot be 
the real reason...

   ????

--
jaime

Post a reply to this message

Jaime Vives Piqueres wrote:

>    Sorry, I see now that indeed you tried, and that was the original
> question: why it works outside the macro but not inside.

Correct.
> 
>    Anyhow, I did a test putting the macro in a separate include file,
> and now at least the error message isn't random anymore: it's always
> "Attempt to access uninitialized array element" on this line:

That's the error I started out with.

> 
>    #declare CFS[Count] = CFS[Count-1];
> 
>    But as data.inc is included and has valid #declares, that cannot be
> the real reason...
> 
That's how I started out. I like certain things kept together in separate 
include files, and since I don't always use the CenterOfMass calculations 
it's a perfect candidate for the #if(CenterOfMass) clause.
> 
> --
> jaime

-- 

Ger

Post a reply to this message

clipka wrote:

>> It's the first version with the -CC option (no povstatefile) that I
>> requested.
> 
> Dang, I was just about to ask what the "-CC" option is... do remember now.
> Send a few round tuits my way and I'll have a look at both issues.

A whole bag of tuits is on the way, but you don't need them for the -CC 
option thingy. Only for the #include thingy. So you may have some spare left 
over that you can use for other stuff.

-- 

Ger

Post a reply to this message

Thomas de Groot wrote:

> On 18-1-2016 8:08, Ger wrote:
> 
>> Btw, Pietje Puk is my alter ego :)
>>
> 
> LOL (strictly for Dutch)
> 
What can I say? :)
-- 

Ger

Post a reply to this message

Well... I'm puzzled. After some more tests, my only conclusion is that 
the #include inside the macro sometimes fails to load correctly the 
included file contents, leaving there "unparseable" code.

--
jaime

Post a reply to this message

Jaime Vives Piqueres wrote:

> Well... I'm puzzled. After some more tests, my only conclusion is that
> the #include inside the macro sometimes fails to load correctly the
> included file contents, leaving there "unparseable" code.
> 
> --
> jaime

I have tried it in every possible way I can come up with and what I have 
found is that povray sometimes chokes on reading data while inside a #macro.
Which indicates to me that povray does not handle #macros correctly. Another 
indicator to that is that shortly before it crashes the memory usage goes up 
strongly.

-- 

Ger

Post a reply to this message

On 1/18/2016 7:59 PM, Ger wrote:
> Another
> indicator to that is that shortly before it crashes the memory usage goes up
> strongly.

That *could* just be an artifact.  It's parsing crap, who knows what 
objects it thinks it's creating.

Post a reply to this message

dick balaska wrote:

> On 1/18/2016 7:59 PM, Ger wrote:
>> Another
>> indicator to that is that shortly before it crashes the memory usage goes
>> up strongly.
> 
> That *could* just be an artifact.  It's parsing crap, who knows what
> objects it thinks it's creating.

Indeed, that is always a possibility, but I had a test render running this 
evening and when I came back to check on it, it was using ~30GB of memory to 
process ~28K spheres. And that's a wee bit too much.
After I stopped it and let the computer settle down a bit, I restarted it 
where it left off and memory usage was up to 2GB within minutes.
-- 

Ger

Post a reply to this message

El 19/01/16 a las 01:59, Ger escribió:
> I have tried it in every possible way I can come up with and what I
> have found is that povray sometimes chokes on reading data while
> inside a #macro. Which indicates to me that povray does not handle
> #macros correctly. Another indicator to that is that shortly before
> it crashes the memory usage goes up strongly.

   Well, thanks to a recent question by Thomas about Parse_String(), if
you absolutely need to include code on a macro, there is a workaround
using that function from strings.inc:

   Write the include file like this:

#write(filehandle, "\"#declare CFS[",str(Count,0,0),"] = <", vstr(3,
CFS[Count], ", ", -1,-1),">;\",\n")

   Then, instead using #include "data.inc", use a call to this macro:

#macro ParseInclude(IncludeFile)
   #fopen filehandle IncludeFile read
   #while (defined(filehandle))
     #read (filehandle,IncludeLine)
     #debug IncludeLine
     #debug "\n"
     Parse_String(IncludeLine)
   #end
   #fclose filehandle
#end

   like this:

ParseInclude("data.inc")


   Hope this helps...

--
jaime

Post a reply to this message

Jaime Vives Piqueres wrote:

>    Well, thanks to a recent question by Thomas about Parse_String(), if
> you absolutely need to include code on a macro, there is a workaround
> using that function from strings.inc:
> 
>    Write the include file like this:
> 
> #write(filehandle, "\"#declare CFS[",str(Count,0,0),"] = <", vstr(3,
> CFS[Count], ", ", -1,-1),">;\",\n")
> 
>    Then, instead using #include "data.inc", use a call to this macro:
> 
> #macro ParseInclude(IncludeFile)
>    #fopen filehandle IncludeFile read
>    #while (defined(filehandle))
>      #read (filehandle,IncludeLine)
>      #debug IncludeLine
>      #debug "\n"
>      Parse_String(IncludeLine)
>    #end
>    #fclose filehandle
> #end
> 
>    like this:
> 
> ParseInclude("data.inc")
> 
> 
>    Hope this helps...
> 
> --
> jaime

It's an interesting technique to say the least, and I must say that it works 
all be it slow (I did implement it in this little animation). But the whole 
point is that an #include should work inside a #macro. 
The simplest workaround for me would be to put the #include in the main body 
of the scene. I've done it and it works fine.
So it's not like "It doesn't work" but more like "It doesn't work the way it 
should"

-- 

Ger

Post a reply to this message

El 19/01/16 a las 10:24, Ger escribió:
> It's an interesting technique to say the least, and I must say that
> it works all be it slow (I did implement it in this little
> animation).

   Yes, it was just an interesting exercise...

> The simplest workaround for me would be to put the #include in the
> main body

   As I said, the workaround is only useful if you absolutely need to use
the include inside the macro, for whatever reason.

> So it's not like "It doesn't work" but more like "It doesn't work the
> way it should"

   I noticed that file size seems to affect it... I mean, when you run
the animation and get the error at some frame, rendering it again with
the "faulty" include will fail again and again. But if you add/remove a
single character from any file (data.inc or test.pov), then magically it
will be parseable (but not if you change the content without changing
file size).

--
jaime

Post a reply to this message

Am 19.01.2016 um 09:58 schrieb Jaime Vives Piqueres:

>   Well, thanks to a recent question by Thomas about Parse_String(), if
> you absolutely need to include code on a macro, there is a workaround
> using that function from strings.inc:

Fun fact to know, especially in this context:

Parse_String itself is nothing more than a macro that writes a temporary
file and then includes it.

So I wouldn't consider it a perfect cure for the symptoms.

Post a reply to this message

El 19/01/16 a las 18:26, clipka escribió:
> Fun fact to know, especially in this context:
>
> Parse_String itself is nothing more than a macro that writes a temporary
> file and then includes it.
>
> So I wouldn't consider it a perfect cure for the symptoms.

   The thing is that it works without any problem... maybe it has to do 
with the fact that it only includes one line at a time?

--
jaime

Post a reply to this message

Jaime Vives Piqueres wrote:

> El 19/01/16 a las 18:26, clipka escribió:
>> Fun fact to know, especially in this context:
>>
>> Parse_String itself is nothing more than a macro that writes a temporary
>> file and then includes it.
>>
>> So I wouldn't consider it a perfect cure for the symptoms.
> 
>    The thing is that it works without any problem... maybe it has to do
> with the fact that it only includes one line at a time?
> 
> --
> jaime

Sounds kinda ridiculous and that's why I tried and it works. It runs with 50 
lines/files and even with 50K lines/files. I let it run until I had >1K 
frames.
-- 

Ger

Post a reply to this message

Am 19.01.2016 um 19:57 schrieb Jaime Vives Piqueres:
> El 19/01/16 a las 18:26, clipka escribió:
>> Fun fact to know, especially in this context:
>>
>> Parse_String itself is nothing more than a macro that writes a temporary
>> file and then includes it.
>>
>> So I wouldn't consider it a perfect cure for the symptoms.
> 
>   The thing is that it works without any problem... maybe it has to do
> with the fact that it only includes one line at a time?

I'm more inclined to suspect that it's because generation and inclusion
of the file are done in one and the same macro.

Post a reply to this message

Am 17.01.2016 um 20:43 schrieb Ger:

> Including a datafile in the main body works, but
> including it inside a #macro results in an error
> at random frames in the animation. It can be at
> frame 10 or at frame 500.

*HA!*
Got that son of a bitch!

Quick workaround: Add /anything/ anywhere before the "#end" statement of
ParseCenterOfMass(); even somewhere before the macro will do. But no
more than about 50 characters.

"WTF?!" you might ask.


Well, here's what happens in a nutshell:

- For each macro defined, POV-Ray stores some information like what file
it resides in, where it starts and, most importantly in this context,
where it ends. More specifically, it stores the position of the "#end"
that ends the macro.

- While executing a macro, to determine whether it has reached the end,
POV-Ray keeps its eyes peeled for any "#" at the position it has stored
as the macro's end.

- In your example, the 10th (give or take 1) "#declare" in "data.inc"
happens to be at the very same position as the "#end" of
ParseCenterOfMass() in your main file.


Do I need to say more? They say never to spoil a joke by explaining its
punchline, but yeah: When looking out for the end of the macro, POV-Ray
does indeed /not/ bother to test whether it is even in the right file.

*Facepalm!*

Post a reply to this message

Am 20.01.2016 um 20:31 schrieb clipka:

> - In your example, the 10th (give or take 1) "#declare" in "data.inc"
> happens to be at the very same position as the "#end" of
> ParseCenterOfMass() in your main file.

Slight flaw in my analysis there: I was under the impression "data.inc"
would grow with another line every frame.

Truth is, there is /some/ "#declare" that /sometimes/ coincides in file
position, depending on the values written. That's the case in frame 10,
but not earlier.

Post a reply to this message

Am 20.01.2016 um 20:31 schrieb clipka:
> Am 17.01.2016 um 20:43 schrieb Ger:
> 
>> Including a datafile in the main body works, but
>> including it inside a #macro results in an error
>> at random frames in the animation. It can be at
>> frame 10 or at frame 500.
> 
> *HA!*
> Got that son of a bitch!

A fix is available now at https://github.com/POV-Ray/povray (source
code) and https://github.com/c-lipka/povray/releases (semi-official
Windows build).

Post a reply to this message

clipka wrote:

> Am 20.01.2016 um 20:31 schrieb clipka:
>> Am 17.01.2016 um 20:43 schrieb Ger:
>> 
>>> Including a datafile in the main body works, but
>>> including it inside a #macro results in an error
>>> at random frames in the animation. It can be at
>>> frame 10 or at frame 500.
>> 
>> *HA!*
>> Got that son of a bitch!
> 
> A fix is available now at https://github.com/POV-Ray/povray (source
> code) and https://github.com/c-lipka/povray/releases (semi-official
> Windows build).


Compile fails
-- 

Ger

Post a reply to this message

On 1/20/2016 7:30 PM, Ger wrote:
> clipka wrote:
>
>> Am 20.01.2016 um 20:31 schrieb clipka:
>>> Am 17.01.2016 um 20:43 schrieb Ger:
>>>
>>>> Including a datafile in the main body works, but
>>>> including it inside a #macro results in an error
>>>> at random frames in the animation. It can be at
>>>> frame 10 or at frame 500.
>>>
>>> *HA!*
>>> Got that son of a bitch!
>>
>> A fix is available now at https://github.com/POV-Ray/povray (source
>> code) and https://github.com/c-lipka/povray/releases (semi-official
>> Windows build).
>
>
> Compile fails
>
difficult to diagnose. "Compile fails" doesn't grep out of the source code.

Post a reply to this message

dick balaska wrote:

> On 1/20/2016 7:30 PM, Ger wrote:
>> clipka wrote:
>>
>>> Am 20.01.2016 um 20:31 schrieb clipka:
>>>> Am 17.01.2016 um 20:43 schrieb Ger:
>>>>
>>>>> Including a datafile in the main body works, but
>>>>> including it inside a #macro results in an error
>>>>> at random frames in the animation. It can be at
>>>>> frame 10 or at frame 500.
>>>>
>>>> *HA!*
>>>> Got that son of a bitch!
>>>
>>> A fix is available now at https://github.com/POV-Ray/povray (source
>>> code) and https://github.com/c-lipka/povray/releases (semi-official
>>> Windows build).
>>
>>
>> Compile fails
>>
> difficult to diagnose. "Compile fails" doesn't grep out of the source code.


:) Yeah, I know. I was still digging at it.
It was just meant as an early shout that something is out of line.
-- 

Ger

Post a reply to this message

Ger wrote:

> dick balaska wrote:
> 
>> On 1/20/2016 7:30 PM, Ger wrote:
>>> clipka wrote:
>>>
>>>> Am 20.01.2016 um 20:31 schrieb clipka:
>>>>> Am 17.01.2016 um 20:43 schrieb Ger:
>>>>>
>>>>>> Including a datafile in the main body works, but
>>>>>> including it inside a #macro results in an error
>>>>>> at random frames in the animation. It can be at
>>>>>> frame 10 or at frame 500.
>>>>>
>>>>> *HA!*
>>>>> Got that son of a bitch!
>>>>
>>>> A fix is available now at https://github.com/POV-Ray/povray (source
>>>> code) and https://github.com/c-lipka/povray/releases (semi-official
>>>> Windows build).
>>>
>>>
>>> Compile fails
>>>
>> difficult to diagnose. "Compile fails" doesn't grep out of the source
>> code.
> 
> 
> :) Yeah, I know. I was still digging at it.
> It was just meant as an early shout that something is out of line.

Fails at

make[1]: Entering directory '/home/ger/Downloads/povray-master/source'
depbase=`echo backend/interior/interior.o | sed 's|[^/]*$|.deps/&|;s|
\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I..  -I../unix/povconfig -I.. -I../unix -I../vfe -
I../vfe/unix -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -
I/usr/include/OpenEXR  -pthread -I/usr/include  -I/usr/include  -pipe -Wno-
multichar -Wno-write-strings -fno-enforce-eh-specs -Wno-non-template-friend -
s -O3 -ffast-math -march=native -pthread -MT backend/interior/interior.o -MD 
-MP -MF $depbase.Tpo -c -o backend/interior/interior.o 
backend/interior/interior.cpp &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ./backend/render/trace.h:44:0,
                 from ./backend/interior/media.h:39,
                 from ./backend/interior/interior.h:37,
                 from backend/interior/interior.cpp:36:
./backend/bounding/bbox.h:59:7: error: redefinition of ‘class pov::Rayinfo’
 class Rayinfo
       ^

-- 

Ger

Post a reply to this message

Am 21.01.2016 um 02:49 schrieb Ger:

>>>>> A fix is available now at https://github.com/POV-Ray/povray (source
>>>>> code) and https://github.com/c-lipka/povray/releases (semi-official
>>>>> Windows build).
...
> Fails at
> 
> make[1]: Entering directory '/home/ger/Downloads/povray-master/source'
> depbase=`echo backend/interior/interior.o | sed 's|[^/]*$|.deps/&|;s|
> \.o$||'`;\
> g++ -DHAVE_CONFIG_H -I. -I..  -I../unix/povconfig -I.. -I../unix -I../vfe -
> I../vfe/unix -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -
> I/usr/include/OpenEXR  -pthread -I/usr/include  -I/usr/include  -pipe -Wno-
> multichar -Wno-write-strings -fno-enforce-eh-specs -Wno-non-template-friend -
> s -O3 -ffast-math -march=native -pthread -MT backend/interior/interior.o -MD 
> -MP -MF $depbase.Tpo -c -o backend/interior/interior.o 
> backend/interior/interior.cpp &&\
> mv -f $depbase.Tpo $depbase.Po
> In file included from ./backend/render/trace.h:44:0,
>                  from ./backend/interior/media.h:39,
>                  from ./backend/interior/interior.h:37,
>                  from backend/interior/interior.cpp:36:
> ../backend/bounding/bbox.h:59:7: error: redefinition of ‘class pov::Rayinfo’
>  class Rayinfo
>        ^

I have no idea what source code you are compiling there -- it is
definitely /not/ what the doctor prescribed, because all the files
"interior.cpp", "interior.h", "media.h" and "trace.h" and "bbox.h" no
longer reside in the "backend" directory sub-tree.

Let me reiterate: You do /not/ want the "stable" branch. You want "master".

Also, make sure you don't have any zombie source files from the "stable"
branch (or any other older version for that matter) lying around when
building.


The source code in question demonstrably builds fine with both g++ 4.6.3
on Ubuntu 12.04 and with g++ 4.8 on Ubuntu 14.04.

Post a reply to this message

clipka wrote:

> I have no idea what source code you are compiling there -- it is
> definitely /not/ what the doctor prescribed, because all the files
> "interior.cpp", "interior.h", "media.h" and "trace.h" and "bbox.h" no
> longer reside in the "backend" directory sub-tree.
> 
> Let me reiterate: You do /not/ want the "stable" branch. You want "master".
> 
> Also, make sure you don't have any zombie source files from the "stable"
> branch (or any other older version for that matter) lying around when
> building.
> 
> 
> The source code in question demonstrably builds fine with both g++ 4.6.3
> on Ubuntu 12.04 and with g++ 4.8 on Ubuntu 14.04.

You're right, my bad, sorry for that.

I had some old master zip thingy stuck under the keyboard or to the back of 
the monitor and mistakenly unpacked that one.

It compiled just fine on a clean installed opensuse tumbleweed. I'll try and 
let you know tomorrow about the macro bug story.

-- 

Ger

Post a reply to this message

Ger wrote:

> 
> You're right, my bad, sorry for that.
> 
> I had some old master zip thingy stuck under the keyboard or to the back of
> the monitor and mistakenly unpacked that one.
> 
> It compiled just fine on a clean installed opensuse tumbleweed. I'll try
> and let you know tomorrow about the macro bug story.
> 
This the correct version?

Persistence of Vision(tm) Ray Tracer Version 3.7.1-alpha.8443996.unofficial 
(g++
 5 @ x86_64-suse-linux-gnu)
This is an unofficial version compiled by:

-- 

Ger

Post a reply to this message

Ger <No.### [at] ThankYou> wrote:
> Ger wrote:
>
> >
> > You're right, my bad, sorry for that.
> >
> > I had some old master zip thingy stuck under the keyboard or to the back of
> > the monitor and mistakenly unpacked that one.
> >
> > It compiled just fine on a clean installed opensuse tumbleweed. I'll try
> > and let you know tomorrow about the macro bug story.
> >
> This the correct version?
>
> Persistence of Vision(tm) Ray Tracer Version 3.7.1-alpha.8443996.unofficial

The 3996 looks familiar.

Post a reply to this message