|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I will post this in bug-reports if it turns out to be a bug, but I often
miss obvious things when looking at my own code. Which is the case here?
The expected result of the following code (expected by me, at least) would
be:
2
2
2
Instead, the code returns
2
3
4
I send an identical array to the macro each time, but get a different
result.
???????????
#macro Persistence_Of_Dimension (ARRAY)
#local Array_Size = dimension_size (ARRAY, 1) + 1;
#local ARRAY = array[Array_Size]
#write (Test_Out, Array_Size, "\n")
#end // #macro Persistence_Of_Dimension (ARRAY)
#local Test_Array = array[1] {0}
#fopen Test_Out "Test_Out.inc" write
Persistence_Of_Dimension (Test_Array)
Persistence_Of_Dimension (Test_Array)
Persistence_Of_Dimension (Test_Array)
#fclose Test_Out
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Apr 2002 11:13:42 -0600, "Shay" <sah### [at] simcopartscom> wrote:
> I will post this in bug-reports if it turns out to be a bug, but I often
> miss obvious things when looking at my own code.
I was noticed similiar thing just yesterday and wondered what to do with that.
Looks like #local works as #declare for references (instead of value) as
parameter. For example
#macro Dec(A)
#local A=A-1;
#end
#local C=1;
Dec(C)
#warning str(C,0,-1)
Above outputs 0 while according to my interpretation of documentation should
output 1. In fact I think documentation is unprecise - it says about namespace
but not about 'referencespace'.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just tried another test and confirmed that changing the value of any
identifier within a macro changes the value of the identifier outside of the
macro as well, even if the identifiers are different.
In the following code, changing NUMBER within the macro also changes
Test_Number outside of the macro. Perhaps this is an intended feature.
#macro Persistence_Of_Identifiers (NUMBER)
#local NUMBER = NUMBER + 1;
#write (Test_Out, NUMBER, "\n") // writes 1
#end // #macro Persistence_Of_Dimension (ARRAY)
#fopen Test_Out "Test_Out.inc" write
#local Test_Number = 0;
Persistence_Of_Identifiers (Test_Number)
#write (Test_Out, Test_Number, "\n") // writes 1
#fclose Test_Out
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <sah### [at] simcopartscom> wrote in message
news:3cab3db0$1@news.povray.org...
>
> Perhaps this is an intended feature.
>
yep!
(docs) 6.2.8.5 Returning Values Via Parameters
Sorry for the waste of time.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Apr 2002 12:36:22 -0600, "Shay" <sah### [at] simcopartscom> wrote:
> > Perhaps this is an intended feature.
>
> yep!
> (docs) 6.2.8.5 Returning Values Via Parameters
> Sorry for the waste of time.
I'm not so sure it was wasting. Note 6.2.8.5 shows only #declare as example. In
6.2.2.2 there is a general rule described (or at least it is my interpretation)
that #local not influences identifiers outside of macro.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
wrote:
> I'm not so sure it was wasting. Note 6.2.8.5 shows only #declare as example. In
> 6.2.2.2 there is a general rule described (or at least it is my interpretation)
> that #local not influences identifiers outside of macro.
Moreover this identifier is a local becouse I can undefine it. Undefining causes
remove of value so why this value appear outside ?
#macro Do(A)
#local A=concat(A,"S");
#undef A
#end
#declare C="A";
Do(C)
#warning C
If such (imo strange) behaviour is part of design I think it should be better
documented.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <sah### [at] simcopartscom> wrote:
> #macro Persistence_Of_Dimension (ARRAY)
> #local Array_Size = dimension_size (ARRAY, 1) + 1;
> #local ARRAY = array[Array_Size]
> #write (Test_Out, Array_Size, "\n")
> #end // #macro Persistence_Of_Dimension (ARRAY)
You are modifyind the size of the array given as parameter.
That's the designed behaviour. (Note that I used the word "designed",
not "correct".)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm not so sure it was wasting. Note 6.2.8.5 shows only #declare as example. In
> 6.2.2.2 there is a general rule described (or at least it is my interpretation)
> that #local not influences identifiers outside of macro.
But you are modifying the external identifier with the #local command
because you are modifying the given parameter.
The paramters to a macro are passed by reference, not by value.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3 Apr 2002 14:32:40 -0500, Warp <war### [at] tagpovrayorg> wrote:
> The paramters to a macro are passed by reference, not by value.
I said it at first post in this thread. Hovewer this could be described somehow
in documentation.
ABX
--
disc{z,-z#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e,1))*.1-4#declare
e=e-1;#end#local e=26;5pigment{#local g=function(_){ceil(_)-_}function#local
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e)<O(),O()//35
>.01#end}}}}{k(g(atan2(x,y)),g(ln((y+x)^2+1e-5)),0)}}finish{ambient 1}}//ABX
Post a reply to this message
|
|
| |
| |
|
|
From: Tom Melly
Subject: Re: Is this a bug, or am I missing something?
Date: 4 Apr 2002 07:51:20
Message: <3cac4c48@news.povray.org>
|
|
|
| |
| |
|
|
news:uemmauca47t09qc6u28rjptcm9b745d84p@4ax.com...
> On 3 Apr 2002 14:32:40 -0500, Warp <war### [at] tagpovrayorg> wrote:
> > The paramters to a macro are passed by reference, not by value.
>
> I said it at first post in this thread. Hovewer this could be described
somehow
> in documentation.
>
Wow - I never knew that. Might explain a lot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |