 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c93b4d6$1@news.povray.org>, jan### [at] lzer net says...
> and even if recursion-depth will be 2^32 .... it WILL terminate ...
But that's only relevant in theory because you won't wait that long
anyway.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
> but it happens at parse-stage ... there's no image rendered yet, and you can debug
it by using the debug-stream ...
You can do the same thing with functions.
> functions can get evaluated at rendertime ...
> you can't debug them by writing some intermediate-values to some stream ...
Yes, you can.
> you see my prob ?
No.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c93bfd9$1@news.povray.org>, "Jan Walzer" <jan### [at] lzernet>
wrote:
> but it happens at parse-stage ... there's no image rendered yet, and you can
> debug it by using the debug-stream ...
>
> functions can get evaluated at rendertime ...
> you can't debug them by writing some intermediate-values to some stream ...
Why not? Just make an equivalent to #debug that operates at function
evaluation time, whether while parsing or rendering.
If you set an arbitrary limit, it will either be too low and get in
people's way (like the recursion limit for macros), or be too high and
not be useful. Why bother?
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What you want is simple: Support for defining variables inside
functions.
Hmm, I suppose you're right. Is that difficult? I'd think you'd only need
some sort of array attached to the function internally, holding all the
values and their respective variable names.
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 16 Mar 2002 20:49:23 -0600, Christopher James Huff
<chr### [at] maccom> wrote:
>If you set an arbitrary limit, it will either be too low and get in
>people's way (like the recursion limit for macros), or be too high and
>not be useful. Why bother?
Only if you make it built-in. If you can change it in the scene or in
the ini file, there will not be such a problem.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag news:3c93f560@news.povray.org...
> Jan Walzer <jan### [at] lzernet> wrote:
> > but it happens at parse-stage ... there's no image rendered yet, and you can debug
it by using the debug-stream ...
>
> You can do the same thing with functions.
No ... I can't
> > functions can get evaluated at rendertime ...
> > you can't debug them by writing some intermediate-values to some stream ...
>
> Yes, you can.
Can I ? ... How ?
> > you see my prob ?
>
> No.
You mean, I should better read the doc ? There is a way ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c94681e@news.povray.org>, "Jan Walzer" <jan### [at] lzernet>
wrote:
> You mean, I should better read the doc ? There is a way ?
Are you just trying to be annoying?
Your argument: if flow control structures are added, it would be
possible to end up with endlessly iterating structures with no way to
output debug values.
There is currently no way to do it, but there currently aren't flow
control structures either. There is no reason a debug command couldn't
be added to functions, making your argument invalid.
I really don't think it is a problem anyway...you can make infinite
loops now, or do other things that take extremely long times to render.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
>> Yes, you can.
> Can I ? ... How ?
#debug concat(str(MyFunction(1,2,3),0,-1), "\n")
It doesn't matter if 'MyFunction' is a macro or a function. If it hangs,
it will hang at parse time.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] vipbg> wrote:
>>If you set an arbitrary limit, it will either be too low and get in
>>people's way (like the recursion limit for macros), or be too high and
>>not be useful. Why bother?
> Only if you make it built-in. If you can change it in the scene or in
> the ini file, there will not be such a problem.
So let's put a limit to the number of times a #while can execute. Right?
I really don't see the problem here. If someone wants to make an infinite
loop, then let them make one. It's not your headache.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote:
> Jan Walzer <jan### [at] lzernet> wrote:
> >> Yes, you can.
> > Can I ? ... How ?
>
> #debug concat(str(MyFunction(1,2,3),0,-1), "\n")
>
> It doesn't matter if 'MyFunction' is a macro or a function. If it hangs,
> it will hang at parse time.
not for every case/function ...
What I meant, is that you can hardly compute/debug any values a function can
give while tracing (imagine, you have it as a imagemap)...
I think Christopher is right, when he means taht we shouldn't dispute about
issues, that are currently no problems at all ...
so propably I can say a EOT here ?
let me just say, that I think it would be great idea, to have recursive
funtions with definable variables, yes ... but leave this issue until 3.5 is
out ... OK ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
