That is in fact what is happening in 1.5 (causing the eventual stack
overflow) because I didn't account for that situation in the code that
evaluates symbols. But I don't see any reason it can't be made to
work. Many languages allow you to bind the same symbol to different
definitions in multiple scopes, and use the previous definition as
part of the next definition.
Path = "hello" /* outer scope */
{ /* inner scope */
Path = Path + " there" /* "Path" on the right-hand-side refers
to the outer-scoped Path symbol */
print(Path)
}
I got this to work in 1.6, but I'm not yet absolutely certain this
won't lead to undesirable side-effects.
On Sep 28, 8:52 pm, Arieh Schneier <[email protected]> wrote:
> 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 -
