August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PositionableStream>>upTo: anObject

by Nicolas Cellier

2016-08-16 23:19 GMT+02:00 John Brant <brant(a)refactoryworkers.com>: > Iâm guessing that it is using the read before written tester from the > refactoring browser. It treats ifTrue:ifFalse:/ifFalse:ifTrue: blocks and > the receiver blocks of whileTrue/False: specially. All other blocks are > considered potentially not executed. Therefore, it says that the or: block > may not be executed so the âelementâ reference in the whileFalse: argument > block may be read without any assignment. > > Since or: and: are pretty much like ifTrue: ifFalse: they should better be treated as specially. > The RBâs read before written tester is different from the compilers. The > compilerâs version lets some things through that it shouldnât, and I think > the compiler should use the RB version instead. Hereâs an example where the > compiler generates incorrect code for the optimized âvâ variable in the > whileTrue: > > | stream count | > count := 0. > stream := ReadStream on: #(true true true false false). > [ stream next and: [ | v | stream next ifTrue: [ v := 1 ]. v notNil ] ] > whileTrue: [ count := count + 1 ]. > count = 1 > > This should answer true, but answers false. The compiler should see that > âvâ may potentially be read before written, and therefore assign it to nil > at the beginning of the or: block like would be done for an unoptimized > block temporary. If you perform the #whileTrue: instead (to get a real > block), you get the correct result: > > | stream count | > count := 0. > stream := ReadStream on: #(true true true false false). > [ stream next and: [ | v | stream next ifTrue: [ v := 1 ]. v notNil ] ] > perform: #whileTrue: with: [ count := count + 1 ]. > count = 1 > > > John Brant > > Yes, you're right, that's a Compiler bug. The result shall not change whether blocks are optimized or not. > > On Aug 16, 2016, at 3:23 PM, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > initialization of element is conditional (in the or: block). > > I'm amazed, that's a new behavior, is it a consequence of using AST? > > But a dumb compiler not knowing the semantic of or: (it is a message > like others) could conclude that element may be used uninitialized in the > whileFalse block... > > A compiler that is inlining or: with a well known semantic has no excuse > ;) > > > > 2016-08-16 22:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > > While browsing the system I saw that the following method raised a temp > read before written... > > > > It did not jump to my eyes. Working on something else.... > > > > > > PositionableStream>>upTo: anObject > > "Answer a subcollection from the current access position to the > > occurrence (if any, but not inclusive) of anObject in the receiver. > If > > anObject is not in the collection, answer the entire rest of the > receiver." > > | newStream element | > > newStream := (collection species new: 100) writeStream. > > [self atEnd or: [(element := self next) = anObject]] > > whileFalse: [newStream nextPut: element]. > > ^newStream contents > > > > > > > > >

Aug. 16, 2016

Re: [Pharo-dev] PositionableStream>>upTo: anObject

by John Brant

Iâm guessing that it is using the read before written tester from the refactoring browser. It treats ifTrue:ifFalse:/ifFalse:ifTrue: blocks and the receiver blocks of whileTrue/False: specially. All other blocks are considered potentially not executed. Therefore, it says that the or: block may not be executed so the âelementâ reference in the whileFalse: argument block may be read without any assignment. The RBâs read before written tester is different from the compilers. The compilerâs version lets some things through that it shouldnât, and I think the compiler should use the RB version instead. Hereâs an example where the compiler generates incorrect code for the optimized âvâ variable in the whileTrue: | stream count | count := 0. stream := ReadStream on: #(true true true false false). [ stream next and: [ | v | stream next ifTrue: [ v := 1 ]. v notNil ] ] whileTrue: [ count := count + 1 ]. count = 1 This should answer true, but answers false. The compiler should see that âvâ may potentially be read before written, and therefore assign it to nil at the beginning of the or: block like would be done for an unoptimized block temporary. If you perform the #whileTrue: instead (to get a real block), you get the correct result: | stream count | count := 0. stream := ReadStream on: #(true true true false false). [ stream next and: [ | v | stream next ifTrue: [ v := 1 ]. v notNil ] ] perform: #whileTrue: with: [ count := count + 1 ]. count = 1 John Brant > On Aug 16, 2016, at 3:23 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > initialization of element is conditional (in the or: block). > I'm amazed, that's a new behavior, is it a consequence of using AST? > But a dumb compiler not knowing the semantic of or: (it is a message like others) could conclude that element may be used uninitialized in the whileFalse block... > A compiler that is inlining or: with a well known semantic has no excuse ;) > > 2016-08-16 22:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > While browsing the system I saw that the following method raised a temp read before written... > > It did not jump to my eyes. Working on something else.... > > > PositionableStream>>upTo: anObject > "Answer a subcollection from the current access position to the > occurrence (if any, but not inclusive) of anObject in the receiver. If > anObject is not in the collection, answer the entire rest of the receiver." > | newStream element | > newStream := (collection species new: 100) writeStream. > [self atEnd or: [(element := self next) = anObject]] > whileFalse: [newStream nextPut: element]. > ^newStream contents > > >

Aug. 16, 2016

readFrom: aStream radix: radix mispackaged

by stepharo

readFrom: aStream radix: radix should be packaged with self readFrom: aStream base: radix Right now readFrom: aStream base: is packaged in AST-core-parser and readFrom: aStream radix: in compatibility. Stef

Aug. 16, 2016

About Integer readFrom: '12xx' ifFail: [ false ]

by stepharo

Hi I would really have an exact match ie Integer readFrom: '12xx' ifFail: [ false ] returning false and not 12. Any idea? May be I should use PetitParser. Stef

Aug. 16, 2016

Re: [Pharo-dev] PositionableStream>>upTo: anObject

by Nicolas Cellier

initialization of element is conditional (in the or: block). I'm amazed, that's a new behavior, is it a consequence of using AST? But a dumb compiler not knowing the semantic of or: (it is a message like others) could conclude that element may be used uninitialized in the whileFalse block... A compiler that is inlining or: with a well known semantic has no excuse ;) 2016-08-16 22:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > While browsing the system I saw that the following method raised a temp > read before written... > > It did not jump to my eyes. Working on something else.... > > > PositionableStream>>upTo: anObject > "Answer a subcollection from the current access position to the > occurrence (if any, but not inclusive) of anObject in the receiver. If > anObject is not in the collection, answer the entire rest of the > receiver." > | newStream element | > newStream := (collection species new: 100) writeStream. > [self atEnd or: [(element := self next) = anObject]] > whileFalse: [newStream nextPut: element]. > ^newStream contents > > >

Aug. 16, 2016

PositionableStream>>upTo: anObject

by stepharo

While browsing the system I saw that the following method raised a temp read before written... It did not jump to my eyes. Working on something else.... PositionableStream>>upTo: anObject "Answer a subcollection from the current access position to the occurrence (if any, but not inclusive) of anObject in the receiver. If anObject is not in the collection, answer the entire rest of the receiver." | newStream element | newStream := (collection species new: 100) writeStream. [self atEnd or: [(element := self next) = anObject]] whileFalse: [newStream nextPut: element]. ^newStream contents

Aug. 16, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60184 Home: https://github.com/pharo-project/pharo-core

Aug. 16, 2016

[pharo-project/pharo-core] a12278: 60184

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: a122782b9bf78f8435476ed8f686a847f4990604 https://github.com/pharo-project/pharo-core/commit/a122782b9bf78f8435476ed8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-16 (Tue, 16 Aug 2016) Changed paths: A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/README.md A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/definition.st A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/instance/accessing/group.st A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/instance/accessing/name.st A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBMultiplePeriodsTerminatingStatementRule.class/instance/running/checkMethod_.st A Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testMultiplePeriodsTerminatingStatement.st A Refactoring-Tests-Critics.package/RBSmalllintTestObject.class/instance/methods/multiplePeriodsTerminatingAssignmentStatement.st A Refactoring-Tests-Critics.package/RBSmalllintTestObject.class/instance/methods/multiplePeriodsTerminatingStatement.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60183.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60184.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60183.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60184.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Sources.package/SourceFileArray.class/instance/public - file system operations/flushChangesFile.st M System-Sources.package/SourceFileArray.class/instance/public - string writing/deferFlushDuring_.st M Traits.package/TClass.class/instance/initialize-release/declareClassVariables_.st Log Message: ----------- 60184 18940 simplify deferFlushDuring: https://pharo.fogbugz.com/f/cases/18940 18942 workaround: fix adding ivars to classes with class vars https://pharo.fogbugz.com/f/cases/18942 18939 New critic for catching redundant periods after statements https://pharo.fogbugz.com/f/cases/18939 http://files.pharo.org/image/60/60184.zip

Aug. 16, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60183 Home: https://github.com/pharo-project/pharo-core

Aug. 16, 2016

[pharo-project/pharo-core] b77606: 60183

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b77606f40924d07c1a215f7200ee6c39f6e12c81 https://github.com/pharo-project/pharo-core/commit/b77606f40924d07c1a215f72… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-16 (Tue, 16 Aug 2016) Changed paths: A Collections-Strings.package/String.class/instance/testing/isValidGlobalName.st A Kernel.package/Character.class/class/queries/supportsNonASCII.st M Monticello.package/MCPackageLoader.class/instance/private/basicLoad.st R Monticello.package/MCPackageLoader.class/instance/private/handleLoadErrorsDuring_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60182.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60183.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60182.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60183.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/ClassBuilderWarning.class/instance/accessing/defaultAction.st M Slot.package/SlotClassBuilder.class/instance/private validating/validateClassName.st M Slot.package/SlotNotFound.class/definition.st M Traits.package/TClass.class/instance/private/isValidTraitName_.st Log Message: ----------- 60183 18917 simplify trait name validation for bootstrap https://pharo.fogbugz.com/f/cases/18917 18941 ClassBuilderWarning should not override defaultAction https://pharo.fogbugz.com/f/cases/18941 http://files.pharo.org/image/60/60183.zip

Aug. 16, 2016