Re: Velocity Macro Improvement - GSCO
Hi, I think changing the macro syntax is bit tricky. So I'd like to go with maximum recursive depths. Supun. I think I'm getting little bit confused here. On 5/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Oh, definitely, we should target our next release, version 1.6. And we should aim for JDK 1.4 compile-time / JDK 1.3 run-time compatibility. No reason to change that. Is there a need to change the macro definition syntax? The other issues seem more urgent. (and all backwards compatible). I think Henning was referring to the *use* of the macros, not the definition (is that right?). And we added commas as a delimiter for 1.5. WILL On 5/29/07, Claude Brisson [EMAIL PROTECTED] wrote: Le mardi 29 mai 2007 à 06:52 -0700, Will Glass-Husain a écrit : Actually, that's already implemented in Velocity 1.5 #somemacro (arg1, arg2, arg3) I wasn't speaking about argument separators but about the definition syntax : #macro somemacro($arg) vs. #macro (somemacro, $arg) Both should be supported while only the latter works today. But that is maybe more difficult to implement than the two others, so it's probably not a priority. Speaking about Spun's work, did we state the target release? Some changes are BC, others not. So the way to go IMO would be to create the 2.0 branch (and if possible to commit some BC changes back to the trunk). Ah, and - that is not strictly related but could be of some interest for Supun: What is the target Java VM for the 1.6 engine? I'd propose Java 1.5, I don't remember at all if we stated somehting about this. Claude works fine. It used to be that spaces were required but no more. https://issues.apache.org/jira/browse/VELOCITY-430 How about limiting the maximum recursion of macros? VELOCITY-297? Alternately, if you want to tinker with the parser, try letting the macro arguments be expressions instead of a single argument, e.g. #somemacro (10 + 10) should work. I think these two ideas would be good starting places. (both feasible to solve in a short period and useful). WILL On 5/29/07, Claude Brisson [EMAIL PROTECTED] wrote: There is also an implicit syntaxic change in Henning's code example: he uses #macro myNamedMacro($arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end which is quite natural but AFAIK not supported since the valid syntax is: #macro (myNamedMacro, $arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end Supporting the former syntax would be great. Claude Le mardi 29 mai 2007 à 18:28 +0530, Supun Kamburugamuva a écrit : Hi, I have gone through most of the stuff pointed by Henning and now I think I'm ready to start the real work. So I thought I should start with a simple thing at the beginning. So I choose the 4th suggestion (blank as argument delimiter') from Hennings list (I don't think this will take much time). At the moment I'm working on it and trying to figure out how it should be done. Regards, Supun.. On 5/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: Hi Supun, I would like to start working on the macro issues as soon as possible. I know the code writing officially starts on 28th May. But I thought starting early would be better. I added a page to the Wiki about this (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also some suggestions. Please do not be afraid about my + - scale, I might be terribly off. Also bear with my syntax typos, it's already late here. If we can get one or two ++ items resolved or even one item, I would be very happy with the GSOC project. I have gone through the macro code and still I don't have a clear picture of how the macro stuff is working. What I have done up to now is setting up debug points where I feel important and debugging the code. Welcome to our world. :-) Here is the whirlwind tour. Let's see how much I still remember off the top of my head and how much I must look up in the code base: In the depths of the parser, there is Macro.processAndRegister. This is where a macro is registered with the engine. This in turn calls addVelocimacro on the passed RuntimeServices object (which is the actual instance of the engine). This is where the Velocimacro Factory comes in, because this call is just a facade before the call in the factory. The factory and the VelocimacroManager (which is inside the factory) are what keeps the macros inside the engine. The factory manages the macros and the manager the namespaces (yes, we do have such an underdocumented feature). The macros themselves are
Re: Velocity Macro Improvement - GSCO
Le mardi 29 mai 2007 à 12:16 -0700, Will Glass-Husain a écrit : Hi, Oh, definitely, we should target our next release, version 1.6. And we should aim for JDK 1.4 compile-time / JDK 1.3 run-time compatibility. No reason to change that. There could some reasons to require java 1.5, like the java.lang.Iterable interface for instance, which would greatly ease the process of making a custom class ready for the #foreach directive (only one method to implement against more than a dozen today to comply to the Collection interface). One good compromise would be to have the uberspector only search for an iterator() method, without caring about interfaces. Otherwise there is no real urgency to require 1.5, I agree. Is there a need to change the macro definition syntax? The other issues seem more urgent. (and all backwards compatible). Backward compatible, yes, but only by means of configuration flags like 'velocimacro.blankSeparators=false'. But since this flag changes the behaviour of the parser, the way to go IMO would be to make the parser pluggable (Henning already talked also about this). Doing this would also allow us to integrate other non-BC changes like disallowing the minus character in reference names (see https://issues.apache.org/jira/browse/VELOCITY-542 ), or allowing expressions as macro arguments, in the same new parser, and to reduce the control of all those new features to only one runtime flag. I think Henning was referring to the *use* of the macros, not the definition (is that right?). And we added commas as a delimiter for 1.5. Maybe Henning didn't intend it but it wasn't my point :-) If this new syntax is not too hard to implement in the parser we should IMHO go for it as it is the most natural. Urgency or priority wasn't my point, I should have started a new thread. So what I'd like is to include this feature (support both creation syntaxes) in the roadmap (maybe targetted for 1.6 with a new plugable parser, for 2.0 otherwise), as the new syntax clearly responds to the principle of least surprise (velocity is the only language I know that uses the old syntax). Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Macro Improvement - GSCO
Yes, Claude is right. This was unintended (though it would be cool). :-) Supun, if you want to start here, please go in slow steps first. Don't try to tackle all problems at once. First getting the , to work is great (as shown in Claude's example). Best regards Henning On Tue, 2007-05-29 at 15:12 +0200, Claude Brisson wrote: There is also an implicit syntaxic change in Henning's code example: he uses #macro myNamedMacro($arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end which is quite natural but AFAIK not supported since the valid syntax is: #macro (myNamedMacro, $arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end Supporting the former syntax would be great. Claude Le mardi 29 mai 2007 à 18:28 +0530, Supun Kamburugamuva a écrit : Hi, I have gone through most of the stuff pointed by Henning and now I think I'm ready to start the real work. So I thought I should start with a simple thing at the beginning. So I choose the 4th suggestion (blank as argument delimiter') from Hennings list (I don't think this will take much time). At the moment I'm working on it and trying to figure out how it should be done. Regards, Supun.. On 5/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: Hi Supun, I would like to start working on the macro issues as soon as possible. I know the code writing officially starts on 28th May. But I thought starting early would be better. I added a page to the Wiki about this (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also some suggestions. Please do not be afraid about my + - scale, I might be terribly off. Also bear with my syntax typos, it's already late here. If we can get one or two ++ items resolved or even one item, I would be very happy with the GSOC project. I have gone through the macro code and still I don't have a clear picture of how the macro stuff is working. What I have done up to now is setting up debug points where I feel important and debugging the code. Welcome to our world. :-) Here is the whirlwind tour. Let's see how much I still remember off the top of my head and how much I must look up in the code base: In the depths of the parser, there is Macro.processAndRegister. This is where a macro is registered with the engine. This in turn calls addVelocimacro on the passed RuntimeServices object (which is the actual instance of the engine). This is where the Velocimacro Factory comes in, because this call is just a facade before the call in the factory. The factory and the VelocimacroManager (which is inside the factory) are what keeps the macros inside the engine. The factory manages the macros and the manager the namespaces (yes, we do have such an underdocumented feature). The macros themselves are invoked when the AST is parsed, through a lookup in the ASTDirective class. This represents a directive on the AST, either one of the defined (#if, #set etc) through parser.isDirective() or a macro (which is similar, e.g. #foo, #bar) through rsvc.isVelocimacro()). I'd suggest that you check out src/parser/Parser.jjt which gets compiled by JJTree/JavaCC into the parser-related classes. The most interesting breakpoints are probably the following method entry points: RuntimeInstance: * addVelocimacro * getVelocimacro VelociMacroManager: * addNamespace * getNamespace (multiple) VelociMacroManager.MacroEntry: * C'tor * getNodeTree * createVelocimacro * parseTree * setup VelocimacroFactory: * getVelocimacro (do not remove the synchronized block!) * initVelocimacro * addVelocimacro This is hopefully enough to get you going. Write a small harness to test your code (load a template, parse it, render it) and test a few very simple templates under the debugger. This should give you an idea how inline macros work. Try again with a macro library (configured in properties) to understand the difference. Look at the setFromLibrary() methods in the MacroEntry class. Find out, what the Twonk is good for. ;-) Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the
Re: Velocity Macro Improvement - GSCO
On 5/30/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Yes, Claude is right. This was unintended (though it would be cool). :-) Supun, if you want to start here, please go in slow steps first. Don't try to tackle all problems at once. First getting the , to work is great (as shown in Claude's example). Sorry, I'm little bit confised here. What is it exactly mean by , to work? Regards, Supun. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Macro Improvement - GSCO
Hi Supun, My suggestion is to run with the macro max recursion depth issue while we argue this out. We've previously changed the syntax to allow commas in the macro parameters when *calling* a macro. I think Claude and Henning are recommending we do the same thing when *defining* a macro. This is an open item and would be a good one to resolve. Not hard to do either. (not yet in JIRA) Henning or Claude, perhaps you could give an example of proposed old and new syntax here? Re: the other discussion. Just rehashing our basic versioning position. All code should compile in JDK 1.4, run in JDK 1.3. (There's a few exceptions where we add extra behavior via reflection that runs in JDK 1.4, but this is rare). WILL On 5/30/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: On 5/30/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Yes, Claude is right. This was unintended (though it would be cool). :-) Supun, if you want to start here, please go in slow steps first. Don't try to tackle all problems at once. First getting the , to work is great (as shown in Claude's example). Sorry, I'm little bit confised here. What is it exactly mean by , to work? Regards, Supun. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
Re: Velocity Macro Improvement - GSCO
Hi, I have gone through most of the stuff pointed by Henning and now I think I'm ready to start the real work. So I thought I should start with a simple thing at the beginning. So I choose the 4th suggestion (blank as argument delimiter') from Hennings list (I don't think this will take much time). At the moment I'm working on it and trying to figure out how it should be done. Regards, Supun.. On 5/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: Hi Supun, I would like to start working on the macro issues as soon as possible. I know the code writing officially starts on 28th May. But I thought starting early would be better. I added a page to the Wiki about this (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also some suggestions. Please do not be afraid about my + - scale, I might be terribly off. Also bear with my syntax typos, it's already late here. If we can get one or two ++ items resolved or even one item, I would be very happy with the GSOC project. I have gone through the macro code and still I don't have a clear picture of how the macro stuff is working. What I have done up to now is setting up debug points where I feel important and debugging the code. Welcome to our world. :-) Here is the whirlwind tour. Let's see how much I still remember off the top of my head and how much I must look up in the code base: In the depths of the parser, there is Macro.processAndRegister. This is where a macro is registered with the engine. This in turn calls addVelocimacro on the passed RuntimeServices object (which is the actual instance of the engine). This is where the Velocimacro Factory comes in, because this call is just a facade before the call in the factory. The factory and the VelocimacroManager (which is inside the factory) are what keeps the macros inside the engine. The factory manages the macros and the manager the namespaces (yes, we do have such an underdocumented feature). The macros themselves are invoked when the AST is parsed, through a lookup in the ASTDirective class. This represents a directive on the AST, either one of the defined (#if, #set etc) through parser.isDirective() or a macro (which is similar, e.g. #foo, #bar) through rsvc.isVelocimacro()). I'd suggest that you check out src/parser/Parser.jjt which gets compiled by JJTree/JavaCC into the parser-related classes. The most interesting breakpoints are probably the following method entry points: RuntimeInstance: * addVelocimacro * getVelocimacro VelociMacroManager: * addNamespace * getNamespace (multiple) VelociMacroManager.MacroEntry: * C'tor * getNodeTree * createVelocimacro * parseTree * setup VelocimacroFactory: * getVelocimacro (do not remove the synchronized block!) * initVelocimacro * addVelocimacro This is hopefully enough to get you going. Write a small harness to test your code (load a template, parse it, render it) and test a few very simple templates under the debugger. This should give you an idea how inline macros work. Try again with a macro library (configured in properties) to understand the difference. Look at the setFromLibrary() methods in the MacroEntry class. Find out, what the Twonk is good for. ;-) Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - 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]
Re: Velocity Macro Improvement - GSCO
There is also an implicit syntaxic change in Henning's code example: he uses #macro myNamedMacro($arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end which is quite natural but AFAIK not supported since the valid syntax is: #macro (myNamedMacro, $arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end Supporting the former syntax would be great. Claude Le mardi 29 mai 2007 à 18:28 +0530, Supun Kamburugamuva a écrit : Hi, I have gone through most of the stuff pointed by Henning and now I think I'm ready to start the real work. So I thought I should start with a simple thing at the beginning. So I choose the 4th suggestion (blank as argument delimiter') from Hennings list (I don't think this will take much time). At the moment I'm working on it and trying to figure out how it should be done. Regards, Supun.. On 5/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: Hi Supun, I would like to start working on the macro issues as soon as possible. I know the code writing officially starts on 28th May. But I thought starting early would be better. I added a page to the Wiki about this (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also some suggestions. Please do not be afraid about my + - scale, I might be terribly off. Also bear with my syntax typos, it's already late here. If we can get one or two ++ items resolved or even one item, I would be very happy with the GSOC project. I have gone through the macro code and still I don't have a clear picture of how the macro stuff is working. What I have done up to now is setting up debug points where I feel important and debugging the code. Welcome to our world. :-) Here is the whirlwind tour. Let's see how much I still remember off the top of my head and how much I must look up in the code base: In the depths of the parser, there is Macro.processAndRegister. This is where a macro is registered with the engine. This in turn calls addVelocimacro on the passed RuntimeServices object (which is the actual instance of the engine). This is where the Velocimacro Factory comes in, because this call is just a facade before the call in the factory. The factory and the VelocimacroManager (which is inside the factory) are what keeps the macros inside the engine. The factory manages the macros and the manager the namespaces (yes, we do have such an underdocumented feature). The macros themselves are invoked when the AST is parsed, through a lookup in the ASTDirective class. This represents a directive on the AST, either one of the defined (#if, #set etc) through parser.isDirective() or a macro (which is similar, e.g. #foo, #bar) through rsvc.isVelocimacro()). I'd suggest that you check out src/parser/Parser.jjt which gets compiled by JJTree/JavaCC into the parser-related classes. The most interesting breakpoints are probably the following method entry points: RuntimeInstance: * addVelocimacro * getVelocimacro VelociMacroManager: * addNamespace * getNamespace (multiple) VelociMacroManager.MacroEntry: * C'tor * getNodeTree * createVelocimacro * parseTree * setup VelocimacroFactory: * getVelocimacro (do not remove the synchronized block!) * initVelocimacro * addVelocimacro This is hopefully enough to get you going. Write a small harness to test your code (load a template, parse it, render it) and test a few very simple templates under the debugger. This should give you an idea how inline macros work. Try again with a macro library (configured in properties) to understand the difference. Look at the setFromLibrary() methods in the MacroEntry class. Find out, what the Twonk is good for. ;-) Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: Velocity Macro Improvement - GSCO
Actually, that's already implemented in Velocity 1.5 #somemacro (arg1, arg2, arg3) works fine. It used to be that spaces were required but no more. https://issues.apache.org/jira/browse/VELOCITY-430 How about limiting the maximum recursion of macros? VELOCITY-297? Alternately, if you want to tinker with the parser, try letting the macro arguments be expressions instead of a single argument, e.g. #somemacro (10 + 10) should work. I think these two ideas would be good starting places. (both feasible to solve in a short period and useful). WILL On 5/29/07, Claude Brisson [EMAIL PROTECTED] wrote: There is also an implicit syntaxic change in Henning's code example: he uses #macro myNamedMacro($arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end which is quite natural but AFAIK not supported since the valid syntax is: #macro (myNamedMacro, $arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end Supporting the former syntax would be great. Claude Le mardi 29 mai 2007 à 18:28 +0530, Supun Kamburugamuva a écrit : Hi, I have gone through most of the stuff pointed by Henning and now I think I'm ready to start the real work. So I thought I should start with a simple thing at the beginning. So I choose the 4th suggestion (blank as argument delimiter') from Hennings list (I don't think this will take much time). At the moment I'm working on it and trying to figure out how it should be done. Regards, Supun.. On 5/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: Hi Supun, I would like to start working on the macro issues as soon as possible. I know the code writing officially starts on 28th May. But I thought starting early would be better. I added a page to the Wiki about this (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also some suggestions. Please do not be afraid about my + - scale, I might be terribly off. Also bear with my syntax typos, it's already late here. If we can get one or two ++ items resolved or even one item, I would be very happy with the GSOC project. I have gone through the macro code and still I don't have a clear picture of how the macro stuff is working. What I have done up to now is setting up debug points where I feel important and debugging the code. Welcome to our world. :-) Here is the whirlwind tour. Let's see how much I still remember off the top of my head and how much I must look up in the code base: In the depths of the parser, there is Macro.processAndRegister. This is where a macro is registered with the engine. This in turn calls addVelocimacro on the passed RuntimeServices object (which is the actual instance of the engine). This is where the Velocimacro Factory comes in, because this call is just a facade before the call in the factory. The factory and the VelocimacroManager (which is inside the factory) are what keeps the macros inside the engine. The factory manages the macros and the manager the namespaces (yes, we do have such an underdocumented feature). The macros themselves are invoked when the AST is parsed, through a lookup in the ASTDirective class. This represents a directive on the AST, either one of the defined (#if, #set etc) through parser.isDirective() or a macro (which is similar, e.g. #foo, #bar) through rsvc.isVelocimacro()). I'd suggest that you check out src/parser/Parser.jjt which gets compiled by JJTree/JavaCC into the parser-related classes. The most interesting breakpoints are probably the following method entry points: RuntimeInstance: * addVelocimacro * getVelocimacro VelociMacroManager: * addNamespace * getNamespace (multiple) VelociMacroManager.MacroEntry: * C'tor * getNodeTree * createVelocimacro * parseTree * setup VelocimacroFactory: * getVelocimacro (do not remove the synchronized block!) * initVelocimacro * addVelocimacro This is hopefully enough to get you going. Write a small harness to test your code (load a template, parse it, render it) and test a few very simple templates under the debugger. This should give you an idea how inline macros work. Try again with a macro library (configured in properties) to understand the difference. Look at the setFromLibrary() methods in the MacroEntry class. Find out, what the Twonk is good for. ;-) Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der
Re: Velocity Macro Improvement - GSCO
Hi, Oh, definitely, we should target our next release, version 1.6. And we should aim for JDK 1.4 compile-time / JDK 1.3 run-time compatibility. No reason to change that. Is there a need to change the macro definition syntax? The other issues seem more urgent. (and all backwards compatible). I think Henning was referring to the *use* of the macros, not the definition (is that right?). And we added commas as a delimiter for 1.5. WILL On 5/29/07, Claude Brisson [EMAIL PROTECTED] wrote: Le mardi 29 mai 2007 à 06:52 -0700, Will Glass-Husain a écrit : Actually, that's already implemented in Velocity 1.5 #somemacro (arg1, arg2, arg3) I wasn't speaking about argument separators but about the definition syntax : #macro somemacro($arg) vs. #macro (somemacro, $arg) Both should be supported while only the latter works today. But that is maybe more difficult to implement than the two others, so it's probably not a priority. Speaking about Spun's work, did we state the target release? Some changes are BC, others not. So the way to go IMO would be to create the 2.0 branch (and if possible to commit some BC changes back to the trunk). Ah, and - that is not strictly related but could be of some interest for Supun: What is the target Java VM for the 1.6 engine? I'd propose Java 1.5, I don't remember at all if we stated somehting about this. Claude works fine. It used to be that spaces were required but no more. https://issues.apache.org/jira/browse/VELOCITY-430 How about limiting the maximum recursion of macros? VELOCITY-297? Alternately, if you want to tinker with the parser, try letting the macro arguments be expressions instead of a single argument, e.g. #somemacro (10 + 10) should work. I think these two ideas would be good starting places. (both feasible to solve in a short period and useful). WILL On 5/29/07, Claude Brisson [EMAIL PROTECTED] wrote: There is also an implicit syntaxic change in Henning's code example: he uses #macro myNamedMacro($arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end which is quite natural but AFAIK not supported since the valid syntax is: #macro (myNamedMacro, $arg1, $arg2, $arg3) ... do something with $arg1, $arg2, $arg3 #end Supporting the former syntax would be great. Claude Le mardi 29 mai 2007 à 18:28 +0530, Supun Kamburugamuva a écrit : Hi, I have gone through most of the stuff pointed by Henning and now I think I'm ready to start the real work. So I thought I should start with a simple thing at the beginning. So I choose the 4th suggestion (blank as argument delimiter') from Hennings list (I don't think this will take much time). At the moment I'm working on it and trying to figure out how it should be done. Regards, Supun.. On 5/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: Hi Supun, I would like to start working on the macro issues as soon as possible. I know the code writing officially starts on 28th May. But I thought starting early would be better. I added a page to the Wiki about this (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also some suggestions. Please do not be afraid about my + - scale, I might be terribly off. Also bear with my syntax typos, it's already late here. If we can get one or two ++ items resolved or even one item, I would be very happy with the GSOC project. I have gone through the macro code and still I don't have a clear picture of how the macro stuff is working. What I have done up to now is setting up debug points where I feel important and debugging the code. Welcome to our world. :-) Here is the whirlwind tour. Let's see how much I still remember off the top of my head and how much I must look up in the code base: In the depths of the parser, there is Macro.processAndRegister. This is where a macro is registered with the engine. This in turn calls addVelocimacro on the passed RuntimeServices object (which is the actual instance of the engine). This is where the Velocimacro Factory comes in, because this call is just a facade before the call in the factory. The factory and the VelocimacroManager (which is inside the factory) are what keeps the macros inside the engine. The factory manages the macros and the manager the namespaces (yes, we do have such an underdocumented feature). The macros themselves are invoked when the AST is parsed, through a lookup in the ASTDirective class. This represents a directive on the AST, either one of the defined (#if, #set etc) through parser.isDirective() or a macro (which is similar, e.g. #foo, #bar) through rsvc.isVelocimacro()). I'd suggest that you check out src/parser/Parser.jjt
