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