[squeak-dev] Can we get Squeak green for the release?

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 8 21:02:45 UTC 2015


On Wed, Apr 8, 2015 at 11:54 AM, Tobias Pape <Das.Linux at gmx.de> wrote:

>
> On 08.04.2015, at 20:29, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > On Wed, Apr 8, 2015 at 11:11 AM, Eliot Miranda <eliot.miranda at gmail.com>
> > wrote:
> >
> > > On Tue, Apr 7, 2015 at 7:39 AM, Levente Uzonyi <leves at elte.hu> wrote:
> > >
> > >> The decompiler is not perfect, and IIRC someone stated that it will
> never
> > >> be. Most of these errors are "handled" by adding them as exceptions,
> so
> > >> they are not tested. Some of these issues are probably fixable, but
> not
> > >> many people are familiar with the decompiler.
> > >> See DecompilerTests >> #decompilerFailures for the list of currently
> > >> ignored methods.
> > >>
> > >> Levente
> > >>
> > >>
> > >> On Tue, 7 Apr 2015, Tobias Pape wrote:
> > >>
> > >>  Hi
> > >>>
> > >>>
> > >>> On 04.04.2015, at 16:59, Frank Shearar <frank.shearar at gmail.com>
> wrote:
> > >>>
> > >>>  On 3 April 2015 at 16:27, Tobias Pape <Das.Linux at gmx.de> wrote:
> > >>>>
> > >>>>> Hey
> > >>>>>
> > >>>>> I am watching the CI doing its work as changes and fixes
> > >>>>> chime in.
> > >>>>>  I noticed that there are still 13 test failing[1] and I'm
> > >>>>> not sure how all of them should be fixed :)
> > >>>>>  Let's make it green!
> > >>>>>
> > >>>>
> > >>>> I am _very very happy_ to see someone other than me harping on about
> > >>>> tests! Please carry on!
> > >>>>
> > >>>> This one ought to be easy to fix: it's a small breakage in the
> > >>>> modularity of the image; some methods need to be recategorised as
> not
> > >>>> being System:
> http://build.squeak.org/job/SqueakTrunk/1207/testReport/
> > >>>> Tests.Dependencies/PackageDependencyTest/testSystem/
> > >>>>
> > >>>> This one too:
> http://build.squeak.org/job/SqueakTrunk/1207/testReport/
> > >>>> Tests.Dependencies/PackageDependencyTest/testTools/
> > >>>> (Tools shouldn't depend on _ToolBuilder-Morphic_, even though it
> would
> > >>>> be OK to depend on ToolBuilder.)
> > >>>>
> > >>>> And I love that this one fails -
> > >>>> http://build.squeak.org/job/SqueakTrunk/1207/testReport/
> > >>>> Tests.Dependencies/PackageDependencyTest/testMultilingual/
> > >>>> - Multilingual no longer depends on TrueType, and our system just
> got
> > >>>> one dependency cleaner.
> > >>>>
> > >>>
> > >>> I did some things :)
> > >>>
> > >>> But I need help:
> > >>> There's a strange thing in the decompiler/compiler:
> > >>>
> > >>>
> http://build.squeak.org/job/SqueakTrunk/lastCompletedBuild/testReport/
> > >>> Tests.Compiler/DecompilerTests/testDecompilerInClassesBAtoBM/
> > >>>
> > >>> Somewhere in Behavior>>#toolIconSelector:,
> > >>> a sequence of 'push nil. pop' is generated that is decompiled as
> 'nil.'.
> > >>> This does not match the source and I don't know whether it's a bug in
> > >>> the Compiler emitting this or the Decompiler not recognizing the
> emitted
> > >>> pattern.
> > >>>
> > >>
> > > Ah, I see it.
> > >
> > > Look the end of this block:
> > > self methodDictionary at: aSymbol ifPresent: [ :method |
> > > ...
> > > method hasReportableSlip ifTrue: [^ #breakpoint]].
> > >
> > > The block (correctly) answers nil if method hasReportableSlip is false,
> > > and the bytecode contains a pushConstant: nil; blockReturn sequence to
> > > implement this.  So the problem is with the decompiler not eliminating
> the
> > > explicit nil node in this case where it should be implicit.
> > >
> >
> > Oops.  The pushConstant: nil; blockReturn sequence is at bytecpde pc 202
> > right? That's coming from
> >
> > (self isSelectorOverride: aSymbol)
> > ifTrue: [
> > (self isSelectorOverridden: aSymbol)
> > ifTrue: [ ^ #arrowUpAndDown ]
> > ifFalse: [ ^ #arrowUp ] ]
> > ifFalse: [
> > (self isSelectorOverridden: aSymbol)
> > ifTrue: [^ #arrowDown ]].
> >
>
> Yes, this is the place :)
>
> > I'll try and squash this in a principled way soon.  I've squashed the
> > former by using the attached:
> >
>
> Thanks for taking care.
> Best
>         -Tobias
>

Looks like a compiler bug to me. The push nil at 202 has no need to be
generated.   :-/

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150408/247e19db/attachment.htm


More information about the Squeak-dev mailing list