I haven't looked at the code, or run any tests... But from your explanation it would seem to me that whether it was defined before or not, this should be invalid: Path=Path + "/some other path"
As when it goes to resolve it substitutes it in over and over, eg: Path=Path + "/some other path" Path=Path + "/some other path" + "/some other path" Path=Path + "/some other path" + "/some other path" + "/some other path" etc Arieh. On Sep 29, 1:25 am, Jeremy Lew <[email protected]> wrote: > I wrote nearly all of the preprocessor code, which explains my > familiarity with its nasty failure modes ;) > > I think I've convinced myself that your scenario ought to be possible, > and I'll see if I can make it happen in 1.6. > > The prepreprocessor tries to be as lazy as possible with symbolic > evaluations: You can define a symbol in terms of another symbol that > does not yet exist, and it won't care as long as the complete > definition exists by the time the symbol is evaluated: > > (pseudo-code) > > a:= b + 1 /* b does not yet exist, no problem until we try to evaluate > a */ > b : = 3 > print(a) /* prints "4" */ > > The cycle detection is meant to prevent you from a mutually-recursive > definition: > > a := b + 1 > b: = a + 1 > print(b) /* infinite loop evaluating b */ > > In your case, Benjamin, you do not have a mutually-recursive > definition, you have something like this, which redefines a symbol > using its previous binding as part of its value: > Path="some path" > { > Path=Path + "/some other path" > print(Path) /* Should print "some path/some other path" */ > > } > > So, the preprocessor code that does nested symbol evaluation is not > being smart about separate definitions of the same name at different > points in the call stack. I think I can fix this > > -Jeremy > > On Sep 28, 10:47 am, Benjamin Baumann <[email protected]> wrote: > > > Your analysis seems pretty sharp. > > The process do exit with a StackOverflowException. > > > 2010/9/28 Jeremy Lew <[email protected]> > > > > cb:scope is analogous to using curly braces in C# to explicitly scope > > > some code block: > > > { > > > } > > > > There are several constructs in the preprocessor which create implicit > > > scopes as well, including a named block expansion (like <cb:Full- > > > Deploy-Block Path="..."/>), which is roughly equivalent to a method > > > call in C#, and needs a new stack frame (scope) for arguments and > > > local variable definitions, so that they supersede any previous > > > definitions of the same-named symbols. > > > > That said, the 1.6 preprocessor detects Benjamin's example as a > > > cyclical definition (of Path) and throws an exception. I think 1.5 > > > lacks cycle detection and will eventually cause a stack overflow if > > > you define a variable in terms of itself. The stack overflow would > > > cause the "hard crash" he described. I'll have to think about it some > > > more, but I believe that the rules governing symbol evaluation will > > > prevent this from ever working the way he intends, though at least in > > > 1.6 it now throws a proper exception. > > > > On Sep 28, 3:48 am, OBones <[email protected]> wrote: > > > > AFAIK, it does not create a new scope unless cb:InnerBlock starts with > > > > a cb:scope element > > > > > On 27 sep, 23:52, Jeremy Lew <[email protected]> wrote: > > > > > > That seems like a bug. Invoking cb:Inner-Block creates a new scope, > > > > > which should allow redefinition of symbols defined in the outer > > > > > scope. What version of CCNET are you using? > > > > > > On Sep 27, 11:59 am, Benjamin Baumann <[email protected]> wrote: > > > > > > > My Bad. > > > > > > I didn't understand the value was passed by default. > > > > > > > There still is a little problem with the following code : > > > > > > > <cb:define name="Full-Deploy-Block "> > > > > > > <project name="MyProject"> > > > > > > <workingDirectory>..\branches\$(Path)\...</workingDirectory> > > > > > > <cb:svn-block svnpath="business/branches/$(Path)"/> > > > > > > <cb:Inner-Block Path="branches\$(Path)" /> > > > > > > </project> > > > > > > </cb:define> > > > > > > > <cb:Full-Deploy-Block Path="iphone" /> > > > > > > > It does not let me redefine Path in the InnerBlock (if I rename Path > > > it is > > > > > > OK). Have I forgotten something? By the way, the CC.net crash is > > > quite > > > > > > violent here : no warn, no error but a good old pop-up with Service > > > Closed. > > > > > > > Thanks for your help OBones. > > > > > > Benjamin Baumann > > > > > > > 2010/9/24 OBones <[email protected]> > > > > > > > > Ok. > > > > > > > > But why do you want to specify Target again. > > > > > > > Once it is defined for Full-Deploy-Block, it is defined for > > > anything > > > > > > > inside and after it. Notice the "after" because you did not define > > > > > > > your Full-Deploy-Block to be a scope. > > > > > > > > On 24 sep, 14:47, Benjamin Baumann <[email protected]> wrote: > > > > > > > > No they are in the reverse order in the config file. I reverse > > > > > > > > it > > > to be > > > > > > > more > > > > > > > > readable in the email. > > > > > > > > > 2010/9/24 OBones <[email protected]> > > > > > > > > > > Are they in this order in your config file? > > > > > > > > > > I would have thought you have to define the block before using > > > it for > > > > > > > > > this to work... > > > > > > > > > > On 23 sep, 11:40, Benjamin Baumann <[email protected]> > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > > I found an annoying bug/problem. I am using ccnet last > > > > > > > > > > stable > > > release > > > > > > > > > (1.5. > > > > > > > > > > > Here is the case : > > > > > > > > > > > <cb:Full-Deploy-Block Target="DEV" InnerPath="trunk" /> > > > > > > > > > > > <cb:define name="Full-Deploy-Block"> > > > > > > > > > > <project name="Projet - $(Target)" > > > > > > > > > > > <workingDirectory>xxx</workingDirectory> > > > > > > > > > > > > > > > > > > > > <webURL>xxx/$(Target)/ViewProjectReport.aspx</webURL> > > > > > > > > > > <cb:Inner-Block Target="$(Target)" /> > > > > > > > > > > </project> > > > > > > > > > > </cb:define> > > > > > > > > > > > With this conf, the Inner-Block is given '$(Target)' instead > > > of DEV. > > > > > > > I > > > > > > > > > find > > > > > > > > > > a work around in renaming Target variable in Environment for > > > the > > > > > > > > > > Full-Deploy-Block but it's quite annoying. Am I doing > > > something wrong > > > > > > > or > > > > > > > > > is > > > > > > > > > > this a bug? > > > > > > > > > > > With kind rewards, > > > > > > > > > > Benjamin Baumann- Hide quoted text - > > > > > > > - Show quoted text -
