I agree with Claude.  It seems there are two approaches

--> track max recursion: for each macro call in a sequence, track the number
of times you call it.  (basically, maintain a map of macros with a counter
for each)

--> track embedded macro calls: track a single number of the macro call
depth (forget recursion, just track macro calls within macro calls)

I'd be happy with the latter item.  If this is set to a sufficiently high
number (20?) this prevents runaway macros yet will not limit typical use.

WILL


On 6/1/07, Claude Brisson <[EMAIL PROTECTED]> wrote:

If it's easier to implement, it may be pertinent to just implement a
"max macro stack depth".

  Claude

Le vendredi 01 juin 2007 à 09:21 -0700, Supun Kamburugamuva a écrit :
> I think the first challenge is to discover recursion. I was thinking
> about discovering recursion when a macro call is being executed.
>
> When the node tree is rendered lets say at some point it reaches a
> macro. At this point, if I can keep track of whether children of this
> node calls the same macro again before the original call finishes, I
> will be able to discover recursion.
>
> I have tried this method in several places i.e. ASTDirectve.render and
> VelocimacroProxy.render by keeping track of the state in ASTDirective
> class and VelocimacroProxy class. First time render method is called
> by a Macro invocation I kept the status in a private variable and when
> the next call occurs I checked this variable to see weather the
> previous macro call is completed. But then I realized that objects
> from these classes are created every time a call occurs to a macro. So
> I cannot keep track of the macro calling state in these classes.
>
> Supun.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Forio Business Simulations

Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com

Reply via email to