Yay! And CompilerTest>>testMaxLiteralsWithClassReferenceInClosure is
green now :)

Don't get me wrong, I really appreciated those #bogus flags. Seriously.
It was an excellent clue that I should stop random debugging and ask
for help from someone who might actually know what they were doing ;-)

Dave

On Wed, Apr 03, 2013 at 03:34:59PM -0700, Eliot Miranda wrote:
> OK, the #bogus flags are gone :)  Colin write the tests and I fixed the
> compiler.  I've also fixed the literal duplication issue (which indeed is a
> side-effect of introducing Environments).  But in doing so the Decompiler
> is broken for v := Binding := expr.  Kudos to anyone who can fix this (I'm
> busy fixing a horrible bug of my own).
> 
> On Tue, Apr 2, 2013 at 7:46 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > On Fri, Mar 29, 2013 at 11:21:00AM -0400, David T. Lewis wrote:
> > > On Fri, Mar 29, 2013 at 03:04:20PM +0000, Frank Shearar wrote:
> > > > On 29 March 2013 14:17, David T. Lewis <lewis at mail.msen.com> wrote:
> > > > >
> > > > > I moved these two new tests from Inbox to Trunk. One test fails on
> > recent
> > > > > trunk images. I do not know if this is a bug or a feature, but I
> > cannot
> > > > > explain the regression so I don't want to assume it's a feature.
> > > > >
> > > > > Dave
> > > >
> > > >
> > http://build.squeak.org/job/SqueakTrunk/237/testReport/junit/Tests.Compiler/CompilerTest/testMaxLiteralsWithClassReferenceInClosure/
> > > >
> > > > shows the test failure.
> > >
> > > The actual change to the image that causes this test failure occurred
> > between
> > > SqueakTrunk/212 and SqueakTrunk/213. In other words, if this test had
> > been
> > > part of the test suite all along, then you would have seen the failure
> > appear
> > > in 213.
> > >
> > > I suspect that this is a side effect of class lookups associated with
> > the Environments
> > > changes, but I cannot say if it is a bug or an explainable variation.
> > Either way
> > > it's good to note the change, and we can either fix the bug or fix the
> > test
> > > as needed.
> >
> > (self flag: #dubious and: [self flag: #bogus]) ifTrue: [self
> > askForGuidance]
> >
> > LiteralVariableNode>>sizeCodeForStore: is flagged thus, which I suspect
> > is somehow related to the apparently incorrect warning about too many
> > literals.
> >
> > Reducing to a smaller test case,  compiling 'Time now' yields a parse tree
> > with LiteralVariableNode {Time} that has code -4 which causes dual
> > reserving
> > in sizeCodeForValue: and this in turn leads to a mis-counting of literals
> > in the encoder.
> >
> > In an earlier version of trunk, the same LiteralVariableNode has a
> > non-negative
> > code value that does not produce the dual reserving in sizeCodeForValue:
> >
> > Dave
> >
> >
> >
> 
> 
> -- 
> best,
> Eliot

>