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! Best -Tobias [1] http://build.squeak.org/job/SqueakTrunk/lastCompletedBuild/testReport/ |
On 3 April 2015 at 16:27, Tobias Pape <[hidden email]> 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. frank > Best > -Tobias > > > [1] http://build.squeak.org/job/SqueakTrunk/lastCompletedBuild/testReport/ > |
Hi
On 04.04.2015, at 16:59, Frank Shearar <[hidden email]> wrote: > On 3 April 2015 at 16:27, Tobias Pape <[hidden email]> 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. Best -Tobias |
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 <[hidden email]> wrote: > >> On 3 April 2015 at 16:27, Tobias Pape <[hidden email]> 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. > > Best > -Tobias > > > |
In reply to this post by Tobias Pape
Hi Tobias,
On Tue, Apr 7, 2015 at 5:30 AM, Tobias Pape <[hidden email]> wrote: Hi Can you mail the symbolic output that shows the bytecode please? SOmetimes the COmpiler is changed but the system is not recompiled, and hence bytecode can be obsolete. I don't think we should bother to fix the decompiler for these cases. But we should remember to do a recompile all at some stage, either before a release or whenever a change to the compiler is made that would change generated code. This does not match the source and I don't know whether it's a bug in So what happens if you recompile the method? Is the push nil, pop sequence still there?
best,
Eliot |
In reply to this post by Levente Uzonyi-2
On Tue, Apr 7, 2015 at 7:39 AM, Levente Uzonyi <[hidden email]> 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. 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. HTH best,
Eliot |
On Wed, Apr 8, 2015 at 11:11 AM, Eliot Miranda <[hidden email]> wrote:
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 ]]. I'll try and squash this in a principled way soon. I've squashed the former by using the attached: best,
Eliot Decompiler-blockTo.st (996 bytes) Download Attachment |
On 08.04.2015, at 20:29, Eliot Miranda <[hidden email]> wrote: > On Wed, Apr 8, 2015 at 11:11 AM, Eliot Miranda <[hidden email]> > wrote: > > > On Tue, Apr 7, 2015 at 7:39 AM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote: > >>> > >>> On 3 April 2015 at 16:27, Tobias Pape <[hidden email]> 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 > > > -- > best, > Eliot |
On Wed, Apr 8, 2015 at 11:54 AM, Tobias Pape <[hidden email]> wrote: --
Looks like a compiler bug to me. The push nil at 202 has no need to be generated. :-/ best,
Eliot |
Free forum by Nabble | Edit this page |