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

[pharo-project/pharo-core] abf56d: 60214

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: abf56d45d544570e65e29b9567b228be031f7ef8 https://github.com/pharo-project/pharo-core/commit/abf56d45d544570e65e29b95… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-13 (Tue, 13 Sep 2016) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60213.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60214.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60213.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60214.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/SmalltalkImage.class/instance/snapshot and quit/snapshot_andQuit_.st Log Message: ----------- 60214 19073 Image snapshot should be forcible executed un DefaultExecutionEnvironment https://pharo.fogbugz.com/f/cases/19073 http://files.pharo.org/image/60/60214.zip

Sept. 13, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] e2d5dd: 60213

by Marcus Denker

> > Log Message: > ----------- > 60213 > 19076 New assert extension to compare floats by closeTo > https://pharo.fogbugz.com/f/cases/19076 > > 19068 SUnit failed tests during command line or monkey run > https://pharo.fogbugz.com/f/cases/19068 > With these, we are down to 9 failing tests on the CI: SmalllintManifestCheckerTest.testCriticsOf SmalllintManifestCheckerTest.testToDoOf - tests need to be updated, will be fixed with next QA update SHParserST80Test.testNumberHierarchy - syntax errors in some methods. ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits - fixed upstream (yes, I need to start bugging people againâ¦ there is *nothing* to be gained from delaying integrating!) ReleaseTest.testMethodsWithUnboundGlobals - FFI package references a non existing class. We should really fix that... SystemAnnouncerLiveTest.testNoDeadSubscriptions Announcements.Tests.Core.Tests.WeakAnnouncerTest.testNoDeadWeakSubscriptions - no idea SystemVersionTest.testUpgrade The space in SystemVersion. makes *lots* of problems and has to be reverted. (e.g. âload code updateâ is broken due to that, too) ClassDescriptionTest.testClassDescriptionRespectsPolymorphismWithTraitDescription #iconNamed: in ClassDescription. Should it be there? Marcus

Sept. 13, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 13, 2016

[pharo-project/pharo-core] e2d5dd: 60213

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e2d5dd55203cd904e458f8c966dc4d09a40cc817 https://github.com/pharo-project/pharo-core/commit/e2d5dd55203cd904e458f8c9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-13 (Tue, 13 Sep 2016) Changed paths: M HudsonBuildTools20.package/HDTestReport.class/instance/running/runCase_.st A SUnit-Core.package/TAssertable.class/instance/asserting/assert_closeTo_.st M SUnit-UI.package/CommandLineTestRunner.class/instance/running/runCase_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60212.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60213.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60212.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60213.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60213 19076 New assert extension to compare floats by closeTo https://pharo.fogbugz.com/f/cases/19076 19068 SUnit failed tests during command line or monkey run https://pharo.fogbugz.com/f/cases/19068 http://files.pharo.org/image/60/60213.zip

Sept. 13, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 0e42ac: 60212

by Marcus Denker

> On 12 Sep 2016, at 20:11, stepharo <stepharo(a)free.fr> wrote: > > tx > > Should I reissue > > 19055 More iconNamed: cleaning > https://pharo.fogbugz.com/f/cases/19055 normally this should have been integrated. Marcus

Sept. 13, 2016

Re: [Pharo-dev] Integrations in Pharo for next generation VMs: FullBlockClosure, SistaV1 bytecode set and Read-only objects

by Tudor Girba

Thanks a lot, Clement! This is amazing work (and I only understand a fraction of it). Cheers, Doru > On Sep 12, 2016, at 7:57 PM, stepharo <stepharo(a)free.fr> wrote: > > Clement > Many thanks for your dedication. Your work open many nice paths for the future. > Stef > > Le 12/9/16 Ã 13:00, ClÃ©ment Bera a Ã©crit : >> Hi everyone, >> >> With the help of multiple people (Marcus Denker, Eliot Miranda and some more), I introduced over the past year multiple changes in the Pharo image to support the next generation VMs. It's still a work in progress, but once issue 19083 will be introduced the bulk of the changes will be in the Pharo image. >> >> These changes have no impact on developers only reading/writing source code and analysing/working with the ASTs, but may have impact with people working with Opal's IR, the bytecode or directly with the BlockClosure and CompiledMethod instances (People building frameworks like Reflectivity, using OpalCompiler extensions or people working on object serializers). >> >> Three main changes were introduced: >> - Secondary bytecode set support >> - Read-only objects >> - FullBlockClosure >> >> The secondary bytecode set support allows the image to run on a VM supporting 2 bytecode sets. Each compiled method has a flag precising which set it uses. This change allows the image to convert all the methods from one bytecode set to another one without any bootstrap (only in-image do-its). The SistaV1 bytecode set was introduced as the second bytecode set. This bytecode set removes many encoding limitations of the existing bytecode set, simplifies bytecode decoding and features new instructions (such as full block closure instructions). >> >> Read-only objects allows one to mark any object as read-only. Any attempt to mutate a read-only object (primitive operations, instance variable store) fails, and the programmer can handle the failures with Smalltalk code. This feature is present with less than 1% overhead in all of our benchmark suite. In the near future, we plan to have all literals read-only to allow more aggressive compiler optimizations and avoid literal mutation inconsistency bugs. This feature can also be used to build efficient object modification trackers and could be used to improve the performance of part of the Reflectivity framework. It may break your code if you mutate literals (Normally you don't). >> >> FullBlockClosures are a new implementation of BlockClosures. They allow efficient implementation of Blocks, with the Copying block and Clean block optimizations present in other Smalltalks. They simplify part of the VM, making Blocks more similar to methods. They also remove many dependencies between BlockClosure, compiled method and contexts, which will allow us to implement more aggressive optimizations in the VM in the future. With FullBlockClosures, the closure's bytecode is present in a separate object (an instance of compiled block) instead of being inlined in the enclosing method. This is still confusing some tools. The debugging support of FullBlockClosure seems however to be complete. >> >> With the issue 19083 integrated and the latest VM compiled with different settings than the current Pharo VM (MULTIPLEBYTECODESETS true bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresAndSistaV1 -DIMMUTABILITY 1), all these features seems to be working in the Pharo image. The goal is to get all of these features used by default before the Pharo 6 feature freeze in November. Alternatively I will need to wait many more months (or Pharo will get unstable and Esteban will scream at me 'No do not integrate that'). >> >> If you worry how any of these changes can impact your frameworks, please answer this thread so we can analyse the potential problems. >> >> Regards, > -- www.tudorgirba.com www.feenk.com "No matter how many recipes we know, we still value a chef."

Sept. 12, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 0e42ac: 60212

by stepharo

tx Should I reissue 19055 More iconNamed: cleaning https://pharo.fogbugz.com/f/cases/19055 Stef Le 12/9/16 Ã 13:17, Marcus Denker a Ã©crit : > This should hopefully fix running the test on the slices for the CI (aka âthe monkeyâ). > > Marcus > >> On 12 Sep 2016, at 13:14, GitHub <noreply(a)github.com> wrote: >> >> Branch: refs/heads/6.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: 0e42ac3a57d6f06df9b018af0d536ab362fa703e >> https://github.com/pharo-project/pharo-core/commit/0e42ac3a57d6f06df9b018af… >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2016-09-12 (Mon, 12 Sep 2016) >> >> Changed paths: >> A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/accessing/uniqueIdentifierName.st >> R Refactoring-Critics.package/RBPharoBootstrapRule.class/class/as yet unclassified/isVisible.st >> A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/testing/isVisible.st >> A Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/accessing/uniqueIdentifierName.st >> M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/instance creation/new_.st >> M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/instance/adding/addSearchStringFrom_in_.st >> R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testOnlyReadOrWrittenTemporary.st >> R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testTemporaryVariableCapitalization.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60211.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60212.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60211.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60212.st >> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> >> Log Message: >> ----------- >> 60212 >> 19075 SmallLint tests failing after update >> https://pharo.fogbugz.com/f/cases/19075 >> >> http://files.pharo.org/image/60/60212.zip >> >> > >

Sept. 12, 2016

Re: [Pharo-dev] Integrations in Pharo for next generation VMs: FullBlockClosure, SistaV1 bytecode set and Read-only objects

by stepharo

Clement Many thanks for your dedication. Your work open many nice paths for the future. Stef Le 12/9/16 Ã 13:00, ClÃ©ment Bera a Ã©crit : > Hi everyone, > > With the help of multiple people (Marcus Denker, Eliot Miranda and > some more), I introduced over the past year multiple changes in the > Pharo image to support the next generation VMs. It's still a work in > progress, but once issue 19083 will be introduced the bulk of the > changes will be in the Pharo image. > > These changes have no impact on developers only reading/writing source > code and analysing/working with the ASTs, but may have impact with > people working with Opal's IR, the bytecode or directly with the > BlockClosure and CompiledMethod instances (People building frameworks > like Reflectivity, using OpalCompiler extensions or people working on > object serializers). > > Three main changes were introduced: > - Secondary bytecode set support > - Read-only objects > - FullBlockClosure > > The secondary bytecode set support allows the image to run on a VM > supporting 2 bytecode sets. Each compiled method has a flag precising > which set it uses. This change allows the image to convert all the > methods from one bytecode set to another one without any bootstrap > (only in-image do-its). The SistaV1 bytecode set was introduced as the > second bytecode set. This bytecode set removes many encoding > limitations of the existing bytecode set, simplifies bytecode decoding > and features new instructions (such as full block closure instructions). > > Read-only objects allows one to mark any object as read-only. Any > attempt to mutate a read-only object (primitive operations, instance > variable store) fails, and the programmer can handle the failures with > Smalltalk code. This feature is present with less than 1% overhead in > all of our benchmark suite. In the near future, we plan to have all > literals read-only to allow more aggressive compiler optimizations and > avoid literal mutation inconsistency bugs. This feature can also be > used to build efficient object modification trackers and could be used > to improve the performance of part of the Reflectivity framework. It > may break your code if you mutate literals (Normally you don't). > > FullBlockClosures are a new implementation of BlockClosures. They > allow efficient implementation of Blocks, with the Copying block and > Clean block optimizations present in other Smalltalks. They simplify > part of the VM, making Blocks more similar to methods. They also > remove many dependencies between BlockClosure, compiled method and > contexts, which will allow us to implement more aggressive > optimizations in the VM in the future. With FullBlockClosures, the > closure's bytecode is present in a separate object (an instance of > compiled block) instead of being inlined in the enclosing method. This > is still confusing some tools. The debugging support of > FullBlockClosure seems however to be complete. > > With the issue 19083 integrated and the latest VM compiled with > different settings than the current Pharo VM (MULTIPLEBYTECODESETS > true bytecodeTableInitializer > initializeBytecodeTableForSqueakV3PlusClosuresAndSistaV1 > -DIMMUTABILITY 1), all these features seems to be working in the Pharo > image. The goal is to get all of these features used by default before > the Pharo 6 feature freeze in November. Alternatively I will need to > wait many more months (or Pharo will get unstable and Esteban will > scream at me 'No do not integrate that'). > > If you worry how any of these changes can impact your frameworks, > please answer this thread so we can analyse the potential problems. > > Regards,

Sept. 12, 2016

Re: [Pharo-dev] Integrations in Pharo for next generation VMs: FullBlockClosure, SistaV1 bytecode set and Read-only objects

by Ben Coman

On Mon, Sep 12, 2016 at 7:00 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi everyone, > > With the help of multiple people (Marcus Denker, Eliot Miranda and some > more), I introduced over the past year multiple changes in the Pharo image > to support the next generation VMs. It's still a work in progress, but once > issue 19083 will be introduced the bulk of the changes will be in the Pharo > image. > > These changes have no impact on developers only reading/writing source > code and analysing/working with the ASTs, but may have impact with people > working with Opal's IR, the bytecode or directly with the BlockClosure and > CompiledMethod instances (People building frameworks like Reflectivity, > using OpalCompiler extensions or people working on object serializers). > > Three main changes were introduced: > - Secondary bytecode set support > - Read-only objects > - FullBlockClosure > > The secondary bytecode set support allows the image to run on a VM > supporting 2 bytecode sets. Each compiled method has a flag precising which > set it uses. This change allows the image to convert all the methods from > one bytecode set to another one without any bootstrap (only in-image > do-its). The SistaV1 bytecode set was introduced as the second bytecode > set. This bytecode set removes many encoding limitations of the existing > bytecode set, simplifies bytecode decoding and features new instructions > (such as full block closure instructions). > > Read-only objects allows one to mark any object as read-only. Any attempt > to mutate a read-only object (primitive operations, instance variable > store) fails, and the programmer can handle the failures with Smalltalk > code. This feature is present with less than 1% overhead in all of our > benchmark suite. In the near future, we plan to have all literals read-only > to allow more aggressive compiler optimizations and avoid literal mutation > inconsistency bugs. This feature can also be used to build efficient object > modification trackers and could be used to improve the performance of part > of the Reflectivity framework. It may break your code if you mutate > literals (Normally you don't). > > FullBlockClosures are a new implementation of BlockClosures. They allow > efficient implementation of Blocks, with the Copying block and Clean block > optimizations present in other Smalltalks. They simplify part of the VM, > making Blocks more similar to methods. They also remove many dependencies > between BlockClosure, compiled method and contexts, which will allow us to > implement more aggressive optimizations in the VM in the future. With > FullBlockClosures, the closure's bytecode is present in a separate object > (an instance of compiled block) instead of being inlined in the enclosing > method. This is still confusing some tools. The debugging support of > FullBlockClosure seems however to be complete. > > With the issue 19083 integrated and the latest VM compiled with different > settings than the current Pharo VM (MULTIPLEBYTECODESETS true > bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresAndSistaV1 > -DIMMUTABILITY 1), all these features seems to be working in the Pharo > image. The goal is to get all of these features used by default before the > Pharo 6 feature freeze in November. Alternatively I will need to wait many > more months (or Pharo will get unstable and Esteban will scream at me 'No > do not integrate that'). > > If you worry how any of these changes can impact your frameworks, please > answer this thread so we can analyse the potential problems. > > Cool news. But I bet VM upgrades in not something that happens often. Maybe an in-Image prompt would be useful to encourage people to upgrade. How would people feel about in fresh Images having a Playground open that asks "To help prove stability of Sista for the next Release, please upgrade to a Sista compatible VM as soon as practical. Evaluate the following to check VM status..." cheers -ben

Sept. 12, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 0e42ac: 60212

by Marcus Denker

This should hopefully fix running the test on the slices for the CI (aka âthe monkeyâ). Marcus > On 12 Sep 2016, at 13:14, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/6.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 0e42ac3a57d6f06df9b018af0d536ab362fa703e > https://github.com/pharo-project/pharo-core/commit/0e42ac3a57d6f06df9b018af… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-09-12 (Mon, 12 Sep 2016) > > Changed paths: > A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/accessing/uniqueIdentifierName.st > R Refactoring-Critics.package/RBPharoBootstrapRule.class/class/as yet unclassified/isVisible.st > A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/testing/isVisible.st > A Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/accessing/uniqueIdentifierName.st > M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/instance creation/new_.st > M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/instance/adding/addSearchStringFrom_in_.st > R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testOnlyReadOrWrittenTemporary.st > R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testTemporaryVariableCapitalization.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60211.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60212.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60211.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60212.st > M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 60212 > 19075 SmallLint tests failing after update > https://pharo.fogbugz.com/f/cases/19075 > > http://files.pharo.org/image/60/60212.zip > >

Sept. 12, 2016