Christoph Hormann wrote:
> 
> [...]
> #macro IC_Merge4(fn_A, fn_B, fn_C, fn_D)
>   function {
>     min(fn_A(x, y, z),
>         fn_B(x, y, z),
>         fn_C(x, y, z),
>         fn_D(x, y, z))
>   }
> #end
> 
> [...]
> #declare fn_A= IC_Merge4(IC_Arr[0], IC_Arr[1], IC_Arr[2], IC_Arr[3])
> 

This seems to be a problem related to the duplicated name 'fn_A', when
using different identifiers inside and outside the macro it works.

I have no idea about the reason for the other problem, but it could be
some function size limit, the resulting function is fairly long and the
crash does not occur when only merging 8 functions.

Both problems already occur in beta 15 BTW.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 18 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> 
> [...]
> 
> Both problems already occur in beta 15 BTW.
> 

And still in RC1.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 14 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3CB1B39A.3F70A85A@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> 1) The following code generates an error about recursive function calls
> (in both versions for '#declare fn_A...'):

Yes, because the detection of recursive calls has to rely on the function
name.  Due to the way declares are parsed other information to handle scope
better is not available.  Consequently this will not be fixed in 3.5 as it
requires a redesign of the POV-Ray parser (or some really ugly hacks in 3.5).
The solution for this particular bug is to not insert functions with the same
name in a function that is being declared also those are accepted by the
parser.

> 2) The following code crashes Povray during render (requires iso_csg 0.3)
> I tried to simplify this, but came across the problem mentioned above and
> therefore had difficulties making a simple example.

Where can I get "iso_csg 0.3"?

As far as the problem is concerned (which I could not verify due to the
missing file), as mentioned above the name check is not really perfect and
with some skill one can probably create a recursive function call using macros
and by exploiting various parser loopholes.  Your problem may or may not be
related to this.  I can say more once I can parse the scene...

    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:
> 
> [...]
> 
> Where can I get "iso_csg 0.3"?
> 
> As far as the problem is concerned (which I could not verify due to the
> missing file), as mentioned above the name check is not really perfect and
> with some skill one can probably create a recursive function call using macros
> and by exploiting various parser loopholes.  Your problem may or may not be
> related to this.  I can say more once I can parse the scene...

http://www-public.tu-bs.de:8080/~y0013390/pov/ic/index.html

(current version already includes the IC_Merge_Array() macro )

To me it seems this problem is related to the length of the function (or
to the depth of nested declarations).

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 16 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Thu, 18 Apr 2002 22:17:19 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:

>In article <3CB1B39A.3F70A85A@gmx.de> , Christoph Hormann 
><chr### [at] gmxde>  wrote:
>
> > 1) The following code generates an error about recursive function calls
> > (in both versions for '#declare fn_A...'):
>
> Yes, because the detection of recursive calls has to rely on the function
> name.

I'm not sure it can be considered as hole in this checking system but if not
then I have simple workaround for our iso_csg library. It is possible now to
redeclare passed functions as array and array not checks recursive calls.

#declare IC_Arr=array[4]
#declare a=array[4]

#macro IC_Merge4(fn_A, fn_B, fn_C, fn_D)
  #local a=array[4]{fn_A,fn_B,fn_C,fn_D};
  function {  
    min(a[0](x, y, z),
        a[1](x, y, z),
        a[2](x, y, z),
        a[3](x, y, z))      
  }
#end 

#declare IC_Arr[0]=function(x, y, z) { x }  
#declare IC_Arr[1]=function(x, y, z) { y }  
#declare IC_Arr[2]=function(x, y, z) { z }    
#declare IC_Arr[3]=function(x, y, z) { x+y }  

#declare a[0]= IC_Merge4(function { IC_Arr[0](x, y, z) }, function {
IC_Arr[1](x, y, z) }, function { IC_Arr[2](x, y, z) }, function {
IC_Arr[3](x, y, z) }) 

ABX

Post a reply to this message

> 
> I'm not sure it can be considered as hole in this checking system but if not
> then I have simple workaround for our iso_csg library. It is possible now to
> redeclare passed functions as array and array not checks recursive calls.
> 

Have you checked this for possible performance eating side effects?  If
there aren't any this could be a possible solution although it would
probably be sufficient to use rare identifiers for the parameters.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 22 Apr 2002 17:53:40 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> "W?odzimierz ABX Skiba" wrote:
> > 
> > I'm not sure it can be considered as hole in this checking system but if not
> > then I have simple workaround for our iso_csg library. It is possible now to
> > redeclare passed functions as array and array not checks recursive calls. 
>
> Have you checked this for possible performance eating side effects?

I asked some day in p.a-u what happen when something like
    #local f_a=function(m){ f_b(m) }
is invoked. As answer I recived change 1502 in RC1 :-)

ABX

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> I asked some day in p.a-u what happen when something like
>     #local f_a=function(m){ f_b(m) }
> is invoked. As answer I recived change 1502 in RC1 :-)

Either you misunderstood my very short change note or I am not remembering
correctly what you asked about the above statement...

    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

Skiba <abx### [at] babilonorg>  wrote:

> I'm not sure it can be considered as hole in this checking system but if not
> then I have simple workaround for our iso_csg library. It is possible now to
> redeclare passed functions as array and array not checks recursive calls.

The checking is still done but in a different way.  However, for performance I
strongly recommend not to use an array but unusual variable names, i.e.
__IC_Merge4_fn_A, etc would unlikely be not unique...

    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, 22 Apr 2002 19:52:50 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > I asked some day in p.a-u what happen when something like
> >     #local f_a=function(m){ f_b(m) }
> > is invoked. As answer I recived change 1502 in RC1 :-)
>
> Either you misunderstood my very short change note or I am not remembering
> correctly what you asked about the above statement...

It was a joke that it was answer for my question. You can find my question in
http://news.povray.org/pcojau0tsr5hk9nprsrf38s3t5ae1ht9ro%404ax.com

ABX

Post a reply to this message