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