- Pharo-dev - lists.pharo.org

IndexedSlots in combination with StatefulTraits
by Torsten Bergmann Aug. 31, 2018

Aug. 31, 2018

I guess I found a bug in accessing Slots using #slots in combination with IndexedSlots and traits. To reproduce use latest Pharo 7 (Build 1126) First create a class with a slot, note that the slot needs to be : Object subclass: #ClassA slots: { IndexedSlot named: #upper } classVariables: { } package: 'Slot-Bugs' As it is the first slot it internally receives an index 1 as you can check with "ClassA slots first". Now define a stateful trait with another indexed slot: Trait named: #StatefulTrait uses: {} slots: { IndexedSlot named: #slotFromTrait } category: 'Slot-Bugs' And create a new subclass using the new Trait ClassA subclass: #ClassB uses: StatefulTrait instanceVariableNames: '' classVariableNames: '' package: 'Slot-Bugs' 1. when you evaluate "ClassA slots" it returns {#FirstSlot => Slot} which is correct 2. when you evaluate "StatefulTrait slots" it returns {#slotFromTrait => Slot} which is correct 3. when you evaluate "ClassB allSlots" returns "an OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => InstanceVariableSlot)" which is OK but 4. when you evaluate "ClassB slots" it returns {#slotFromTrait => InstanceVariableSlot} which is NOT correct as class B does not define the slot, it is defined in the trait So I think 4. is wrong and reasons is the implementation of #slot: slots "I remove the slots comming from a traitComposition" ^ super slots reject:[ :e | self traitComposition slots includes:e ] If you debug you will notice that super slots returns our #slotFromTrait with an index of 2 while self traitComposition slots returns our #slotFromTrait with an index of 1 while which is the same #slotFromTrait but a different index - therefore it does not get removed. Dont know what is the best way to fix this without any side effects. Commenst and help appreciated. Thanks T.

5 8

[Pharo 7.0-dev] Build #1201: 22374 create button in debugger doesnt work for classes like it does for methods
by ci-pharo-ci-jenkins2＠inria.fr Aug. 31, 2018

Aug. 31, 2018

There is a new Pharo build available! The status of the build #1201 was: SUCCESS. The Pull Request #1726 was integrated: "22374 create button in debugger doesnt work for classes like it does for methods" Pull request url: https://github.com/pharo-project/pharo/pull/1726 Issue Url: https://pharo.fogbugz.com/f/cases/22374 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1200: 22377-simplify-NEContextcreateModel
by ci-pharo-ci-jenkins2＠inria.fr Aug. 31, 2018

Aug. 31, 2018

There is a new Pharo build available! The status of the build #1200 was: SUCCESS. The Pull Request #1728 was integrated: "22377-simplify-NEContextcreateModel" Pull request url: https://github.com/pharo-project/pharo/pull/1728 Issue Url: https://pharo.fogbugz.com/f/cases/22377 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1199: 22373-LinkedListreject-is-slow
by ci-pharo-ci-jenkins2＠inria.fr Aug. 30, 2018

Aug. 30, 2018

There is a new Pharo build available! The status of the build #1199 was: SUCCESS. The Pull Request #1725 was integrated: "22373-LinkedListreject-is-slow" Pull request url: https://github.com/pharo-project/pharo/pull/1725 Issue Url: https://pharo.fogbugz.com/f/cases/22373 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1198: 22366-TabMorph-should-use-displayScaleFactor
by ci-pharo-ci-jenkins2＠inria.fr Aug. 29, 2018

Aug. 29, 2018

There is a new Pharo build available! The status of the build #1198 was: SUCCESS. The Pull Request #1719 was integrated: "22366-TabMorph-should-use-displayScaleFactor" Pull request url: https://github.com/pharo-project/pharo/pull/1719 Issue Url: https://pharo.fogbugz.com/f/cases/22366 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1197: 21989-TPrintOnSequencedTesttestStoreOn-contains-commented-code
by ci-pharo-ci-jenkins2＠inria.fr Aug. 29, 2018

Aug. 29, 2018

There is a new Pharo build available! The status of the build #1197 was: SUCCESS. The Pull Request #1724 was integrated: "21989-TPrintOnSequencedTesttestStoreOn-contains-commented-code" Pull request url: https://github.com/pharo-project/pharo/pull/1724 Issue Url: https://pharo.fogbugz.com/f/cases/21989 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1196: 22370-RF-tests-related-to-level
by ci-pharo-ci-jenkins2＠inria.fr Aug. 29, 2018

Aug. 29, 2018

There is a new Pharo build available! The status of the build #1196 was: SUCCESS. The Pull Request #1723 was integrated: "22370-RF-tests-related-to-level" Pull request url: https://github.com/pharo-project/pharo/pull/1723 Issue Url: https://pharo.fogbugz.com/f/cases/22370 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1195: 21504-StringromanNumber-should-be-symmetric-to-IntegerprintStringRoman
by ci-pharo-ci-jenkins2＠inria.fr Aug. 29, 2018

Aug. 29, 2018

There is a new Pharo build available! The status of the build #1195 was: SUCCESS. The Pull Request #1619 was integrated: "21504-StringromanNumber-should-be-symmetric-to-IntegerprintStringRoman" Pull request url: https://github.com/pharo-project/pharo/pull/1619 Issue Url: https://pharo.fogbugz.com/f/cases/21504 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

ZnCharacterEncoder default instances
by Alistair Grant Aug. 28, 2018

Aug. 28, 2018

Hi Sven and Everyone, Instantiation of character encoders is relatively expensive, as can be seen by the following code snippet: | count str ba enc new old | count := 10000. str := 'test-Ã¤Ã¶Ã¼'. new := [ count timesRepeat: [ (ZnCharacterEncoder newForEncoding: 'utf8') encodeString: str ] ] timeToRunWithoutGC. enc := ZnCharacterEncoder newForEncoding: 'utf8'. old := [ count timesRepeat: [ enc encodeString: str ] ] timeToRunWithoutGC. { old. new. } " #(14 122)" What do you think of the idea of caching default instances of encoders? My idea was to have a dictionary in ZnCharacterEncoder and add a class method #forEncoding:. This would lazily create an instance, store it in the dictionary, and then re-use the instance whenever that encoder is requested. If people really want their own instance (not sure why, there aren't any instance variables, and so there's no state), they can use the existing #newForEncoding:. For example, sending #exists to a file reference currently instantiates two encoders. This was actually previously fixed by #20273[1], but seems to have been lost with the refactoring of FilePluginPrims to File. From memory, Cyril's application saved 12 seconds by caching the encoder. But in that case the instance was private to the file plugin primitives. This would be a more general solution. [1] https://pharo.fogbugz.com/f/cases/20273/FilePluginPrims-could-save-an-encod… Thanks, Alistair

2 3

Debugging FFI Calls
by Eliot Miranda Aug. 27, 2018

Aug. 27, 2018

Hi All, the latest VMs support a new facility which catches and reports exceptions during FFI calls as primitive failures. That means that if you have the relevant support code loaded (described below) and depending on dialect, you write your FFI interface method to contain an error code, or you're using the UnifiedFFI which uses invokeWithArguments:, then any exception that occurs during the FFI call will be caught and reported to use with the error code bound to an instance of ExceptionInFFICall, which contains a platform-specific error code and the pc at which it occurred. To use this facility you'll need to download a VM built yesterday or later (it should be derived from VMMaker.oscog-eem.2435 or later), or build your own from the tip of the Cog branch in opensmalltalk/vm. You'll then need to update the image code to install ExceptionInFFICall appropriately: in Pharo6 load SLICE 22367 in Squeak load the latest FFI code from source.squeak.org/FFI and update your image from trunk in Cuis, you'll need to adapt these changes to Cuis (sorry!!) There are two command-line flags to override the default behavior. [-]-failonffiexception causes the handling to be applied to all FFI calls, so if a method doesn't contain an error, you'll just see a primitive failure, and if ExceptionInFFICall is not installed you'll see only an error number in the call's error code. [-]-nofailonffiexception ignores exceptions during FFI calls, hence defaulting to the old behavior of crashing the VM (which may be useful if one is using a low-level debugger to debug the VM and/or external code). HTH _,,,^..^,,,_ best, Eliot

1 0