|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> This isn't legal syntax and POV-Ray cannot currently detect this properly.
Isn't there a possibility to prevent the crash?
> To do what you want, use #declare instead of #local like this:
>
> #macro F_Plane ()
> #undef fn_p
> #declare fn_p=function (x,y,z) { y };
> fn_p
> #end
Note this is an undocumented feature. In fact function declarations are
not listed in the #declare documentation at all:
DECLARATION:
#declare IDENTIFIER = RVALUE |
#local IDENTIFIER = RVALUE
RVALUE:
FLOAT; | VECTOR; | COLOR; | STRING | OBJECT | TEXTURE |
PIGMENT | NORMAL | FINISH | INTERIOR | MEDIA | DENSITY |
COLOR_MAP | PIGMENT_MAP | SLOPE_MAP | NORMAL_MAP |
DENSITY_MAP | CAMERA | LIGHT_SOURCE | FOG | RAINBOW |
SKY_SPHERE | TRANSFORM
Function documentation only lists the full declarations:
FUNCTION_IDENTIFIER:
#local FUNCTION_IDENTIFIER = function { FLOAT } |
#declare FUNCTION_IDENTIFIER = function { FLOAT } |
#local FUNCTION_IDENTIFIER = function(IDENT_LIST) { FLOAT } |
#declare FUNCTION_IDENTIFIER = function(IDENT_LIST) { FLOAT } |
#local FUNCTION_IDENTIFIER = function{SPECIAL_FLOAT_FUNCTION} |
#local VECTOR_IDENTIFIER = function{SPECIAL_VECTOR_FUNCTION} |
#local COLOR_IDENTIFIER = function { SPECIAL_COLOR_FUNCTION } |
Calls to user defined functions are missing in the 'Float Expressions'
as well.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <edn### [at] tritonimagicode> , Christoph Hormann
<chr### [at] gmxde> wrote:
>> This isn't legal syntax and POV-Ray cannot currently detect this properly.
>
> Isn't there a possibility to prevent the crash?
Not without making macros aware of what they are returning.
Actually, thinking about this again, I think the following should work as
well (sorry, I cannot test it right now):
#macro F_Plane ()
#local fn_p=function (x,y,z) { y };
fn_p;
#end
The reason I suspect this might work is because it practically completes the
copy assignment prior to leaving the macro. Thus, the parser is no longer
waiting to be able to figure out if the above is a copy or a evaluation.
>> To do what you want, use #declare instead of #local like this:
>>
>> #macro F_Plane ()
>> #undef fn_p
>> #declare fn_p=function (x,y,z) { y };
>> fn_p
>> #end
>
> Note this is an undocumented feature. In fact function declarations are
> not listed in the #declare documentation at all:
True. And it shouldn't be documented for now as I am not sure if it should
be allowed or not. Macros should only return "complete" unambiguous
statements. The workaround only works because a #declared function isn't
destroyed after leaving the macro like a #local function. The parser cannot
detect either case, but as it doesn't destroy the #declared function when
leaving the macro, the code works as expected. I suppose even doing
#local F1= F_Plane()(1,2,3);
would work in this case. I really don't want to endorse this syntax, and I
won't promise future versions of POV-Ray will still allow it. So if my
suggestion with the semicolon does work, that would be the recommended way
of handling this.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>>Isn't there a possibility to prevent the crash?
>
>
> Not without making macros aware of what they are returning.
>
> Actually, thinking about this again, I think the following should work as
> well (sorry, I cannot test it right now):
>
> #macro F_Plane ()
> #local fn_p=function (x,y,z) { y };
> fn_p;
> #end
It works.
>>>To do what you want, use #declare instead of #local like this:
>>>
>>>#macro F_Plane ()
>>> #undef fn_p
>>> #declare fn_p=function (x,y,z) { y };
>>> fn_p
>>>#end
>>
>>Note this is an undocumented feature. In fact function declarations are
>>not listed in the #declare documentation at all:
>
>
> True. And it shouldn't be documented for now as I am not sure if it should
> be allowed or not. Macros should only return "complete" unambiguous
> statements. The workaround only works because a #declared function isn't
> destroyed after leaving the macro like a #local function. The parser cannot
> detect either case, but as it doesn't destroy the #declared function when
> leaving the macro, the code works as expected. I suppose even doing
> #local F1= F_Plane()(1,2,3);
> would work in this case. I really don't want to endorse this syntax, and I
> won't promise future versions of POV-Ray will still allow it. So if my
> suggestion with the semicolon does work, that would be the recommended way
> of handling this.
I was not referring to macros at all, the fact that
#declare fn_p=function (x,y,z) { y };
#declare fn_q=fn_p;
does work is not documented, the fn_p declaration only in the function
chapter, not in the #declare chapter. This should be changed IMO, as
well as adding user defined function evaluations to possible float
expressions.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4vo### [at] tritonimagicode> , Christoph Hormann
<chr### [at] gmxde> wrote:
> I was not referring to macros at all, the fact that
>
> #declare fn_p=function (x,y,z) { y };
>
> #declare fn_q=fn_p;
>
> does work is not documented, the fn_p declaration only in the function
> chapter, not in the #declare chapter. This should be changed IMO, as
> well as adding user defined function evaluations to possible float
> expressions.
As, I see, and agree.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Nov 2003 20:30:57 +0100 JC (Exether) wrote:
>I tried to post this message three times in P.bugreports and it didn't
>work, sorry if I'm multiposting.
JC, thank you for reporting it here. Please read "bug reporting" in
the povray.announce.frequently-asked-questions group. I would have
directed you to that article upon receiving your first report but you
gave no valid e-mail address.
--
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|