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

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by tesonep＠gmail.com

Sorry, I have missed them. That is why it is better to create a PR. I will check it. Cheers, On Thu, Aug 30, 2018 at 10:38 AM Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Pablo, > > were you able to have a look at my changeset with the fix provided in July > already: > > > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272614… > > I would like to get > https://pharo.fogbugz.com/f/cases/22271/Fix-IndexedSlots-in-combination-wit… > fixed. > > Thanks > T. > > *Gesendet:* Dienstag, 17. Juli 2018 um 12:51 Uhr > *Von:* "Torsten Bergmann" <astares(a)gmx.de> > *An:* pharo-dev(a)lists.pharo.org > *Cc:* Pharo-dev <pharo-dev(a)lists.pharo.org> > *Betreff:* Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits > Hi Pablo, > > thanks for the quick answer. The attached CS would fix it ... can you have > a review so we can open a bug and do a PR? > > Then at least this could be integrated independent from when the tools and > traits are cleaned up. > > Thanks > T. > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 31, 2018

[Pharo 7.0-dev] Build #1199: 22373-LinkedListreject-is-slow

by ci-pharo-ci-jenkins2＠inria.fr

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…

Aug. 30, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Torsten Bergmann

Aug. 30, 2018

Promote new Pharo 7 VM (d952580)

by Alistair Grant

Hi Esteban and Everyone, I would like to request we start the process for promoting a new Pharo 7 VM. d952580 (vmLatest as I write this) has two changes that I'm looking forward to: - Fix path encoding / decoding on OSX Hopefully this will finally allow me to submit the File Attributes changes (fogbugz 18279[1] & 21368[2]). - Add primitiveChangeMode(), primitiveChangeOwner() and primitiveSymlinkChangeOwner() This will allow Pharo to set file owner & group IDs and posix permissions on Unix platforms (Linux & OSX). Other changes include: - stdio is flagged correctly on Windows - Windows 64 bit work - fflush added to sqFileTruncate() - Eliot's work on Cog - Everything else I've missed :-) (sorry to those authors) Running the automated test suite on Linux 32 bit, Linux 64 bit and Windows 32 bit produces basically the same set of failures with the current stable VM and the proposed VM. [1] https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… [2] https://pharo.fogbugz.com/f/cases/21368/Integrate-FileAttributesPlugin Thanks, Alistair

Aug. 30, 2018

[Pharo 7.0-dev] Build #1198: 22366-TabMorph-should-use-displayScaleFactor

by ci-pharo-ci-jenkins2＠inria.fr

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…

Aug. 29, 2018

[Pharo 7.0-dev] Build #1197: 21989-TPrintOnSequencedTesttestStoreOn-contains-commented-code

by ci-pharo-ci-jenkins2＠inria.fr

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…

Aug. 29, 2018

[Pharo 7.0-dev] Build #1196: 22370-RF-tests-related-to-level

by ci-pharo-ci-jenkins2＠inria.fr

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…

Aug. 29, 2018

[Pharo 7.0-dev] Build #1195: 21504-StringromanNumber-should-be-symmetric-to-IntegerprintStringRoman

by ci-pharo-ci-jenkins2＠inria.fr

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…

Aug. 29, 2018

Re: [Pharo-dev] ZnCharacterEncoder default instances

by Alistair Grant

Hi Sven, Thanks for the quick reply. On Tue, 28 Aug 2018 at 13:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Alistair, > > Thanks for the feedback, but consider: > > count := 10000. > str := 'test-Ã¤Ã¶Ã¼'. > [ > count timesRepeat: [ > ZnCharacterEncoder utf8 encodeString: str > ] ] timeToRunWithoutGC. > > => 8 > > #newForEncoding: is indeed slow as it has to look through all known encoders, which also involves a subclasses search, which is a PITA. > > ZnCharacterEncoder class>>#utf8 actually uses a cached default instance (see ZnUTF8Encoder class>>#default). As this is the most used encoder, with no customization options, it makes sense. For example, #utf8Encoded and #utf8Decoded use this instance. > > However, some (byte, utf16, utf32) encoders do have state (endianness, strictness, ...), so global caching could be an issue. > > Users of the encoders are free to cache their own instances. > > I am not (yet) convinced that a global cache is needed. Somehow I missed the existence of ZnCharacterEncoder class>>#utf8. That certainly covers the cases I'm think of, so I'll just use it. Thanks again, Alistair

Aug. 28, 2018

Re: [Pharo-dev] ZnCharacterEncoder default instances

by Sven Van Caekenberghe

Hi Alistair, Thanks for the feedback, but consider: count := 10000. str := 'test-Ã¤Ã¶Ã¼'. [ count timesRepeat: [ ZnCharacterEncoder utf8 encodeString: str ] ] timeToRunWithoutGC. => 8 #newForEncoding: is indeed slow as it has to look through all known encoders, which also involves a subclasses search, which is a PITA. ZnCharacterEncoder class>>#utf8 actually uses a cached default instance (see ZnUTF8Encoder class>>#default). As this is the most used encoder, with no customization options, it makes sense. For example, #utf8Encoded and #utf8Decoded use this instance. However, some (byte, utf16, utf32) encoders do have state (endianness, strictness, ...), so global caching could be an issue. Users of the encoders are free to cache their own instances. I am not (yet) convinced that a global cache is needed. Sven > On 28 Aug 2018, at 12:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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 >

Aug. 28, 2018