- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

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

Sept. 12, 2016

[pharo-project/pharo-core] 0e42ac: 60212

by GitHub

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

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

by ClÃ©ment Bera

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] [ANN] Sparta v1.0

by Nicolai Hess

2016-09-05 11:50 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi > > I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6. > https://github.com/syrel/Sparta/tree/v1.0 > For a moment only Linux and Mac are supported. > > It can be bootstrapped with the following script: > > Metacello new > baseline: 'Sparta'; > repository: 'github://syrel/sparta:v1.0/src'; > load: #file:core > > > (on linux install 32bit libgtk-2, lingtk-3 and libstdc++) > (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH) > > Sparta is an almost stateless vector graphics API for Pharo that provides > bindings to the Moz2D rendering backend. Moz2D is the extracted graphical > engine from Mozilla Firefox compiled as standalone shared library together > with the extern C bindings required to call the engine from Pharo. > > - developed with the help of Iceberg > <https://github.com/npasserini/iceberg> (thanks!) on Github. > - integrated into travis-ci <https://travis-ci.org/syrel/Sparta> using > smalltalkCI <https://github.com/hpi-swa/smalltalkCI> (great job!). > - documented using Pillar <https://github.com/pillar-markup/pillar> (so > better!) syntax. > > I tried it on linux mint 18 (32 Bit) and executing any moz-example makes the image crashing. I will try to find out what exactly happens or do you have an idea what is missing? > Cheers, > Alex >

Sept. 12, 2016