On 01.03.12 23:09, Drakonis wrote:
> // Do the same thing, but this time use the inline array initializer syntax
> #local ColorMapArray2 = array[3]
> {

>   color_map
>   {
>   [ 0.0 color rgb 0 ]
>   [ 0.5 color rgb 1  ]
>   [ 1.0 color rgb 0  ]
>   },

>   localCM,

> // "Parse Error: Attempted to redefine colour map identifier as object
> identifier."
>   ColorMapMacro(<1,1,1>)
> }
>
> What part of the POV-Ray language syntax am I missing here?  Can't an array
> element be initialized from a macro?  Isn't it just magically injecting a
> color_map declaration there?
>
> I am poised with my hand hovering over my forehead, for the upcoming slap. :-)

Hello Eduard!

The error message is really funny, isn't it?  The reason is as trivial as 
the explanation Chris Young wrote for the docs: "POV-Ray macros are a 
strange mix of macros and functions." in 
<http://www.povray.org/documentation/view/3.6.1/243/#s02_02_02_08_03> .

And you happen to catch the macro in a case where the macros behaves like a 
function. It returns an object identifier of type "color_map", but too bad 
for you, it isn't a scene-level object, but one of those special cases that 
isn't really an object internally. As the docs (knowing this was written by 
Chris Young) say "When the body of a macro consists of statements that 
create an entire item such as an object, texture, etc. then the macro acts 
like a function which returns a single value." So when you try to assign it 
to the array, the code thinks you are assigning a (scene-level) object to 
the array of the special type of color_map" objects. It would need to do 
more inspection here, but that isn't happening.

Honestly, I didn't even know (!!!) it was possible to assign color_map 
objects to arrays before looking into the code, but it is also pretty clear 
that fixing the color_map assignment might not be trivial (though I haven't 
stepped through the code just yet). Especially given color_map code tends to 
leak so quickly and in so many unusual cases.

Of course, this does not solve the problem at hand, but: You might try to 
declare the return value of the macro locally, and then return that value. 
This might work...

As for fixing this in 3.7, it probably isn't a good idea to mess with the 
parser at this stage and on this level. But filing a bug report might be a 
good idea ;-)

Thorsten

Post a reply to this message