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

[Pharo 7.0-dev] Build #1346: 22585 Tag ManifestSystemSupport and related classes in System-Support

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

There is a new Pharo build available! The status of the build #1346 was: FAILURE. The Pull Request #1931 was integrated: "22585 Tag ManifestSystemSupport and related classes in System-Support" Pull request url: https://github.com/pharo-project/pharo/pull/1931 Issue Url: https://pharo.fogbugz.com/f/cases/22585 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

[Pharo 7.0-dev] Build #1345: 22598 Tag ManifestManifestTests and other classes in Manifest-Tests

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

There is a new Pharo build available! The status of the build #1345 was: FAILURE. The Pull Request #1934 was integrated: "22598 Tag ManifestManifestTests and other classes in Manifest-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1934 Issue Url: https://pharo.fogbugz.com/f/cases/22598 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

Re: [Pharo-dev] About #zipped / #unzipped

by Marcus Denker

> On 18 Oct 2018, at 20:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. > > (note also that there are no real users of these methods) > > Right now it seems cool that the following is an identity. > > 'foobar' zipped unzipped. > > However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. > > Of course, the current methods are broken, as can be seen from a more complex (wide) string. > > 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> > > The error results from some implicit/wrong character encoding being used. > > The right way to do this is to explicitly encode/decode the string. > > (GZipReadStream on: (ByteArray streamContents: [ :out | > (GZipWriteStream on: out) > nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; > close ])) upToEnd utf8Decoded. > > From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. > > 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. > > This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded > > What do you think ? > Yes, to me this sounds interestingâ¦ I think compression is indeed better done on the level of bytes then on Strings. Marcus

Oct. 23, 2018

[Pharo 7.0-dev] Build #1344: 22599 Tag ManifestPharoBootstrapInitialization and related classes

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

There is a new Pharo build available! The status of the build #1344 was: SUCCESS. The Pull Request #1935 was integrated: "22599 Tag ManifestPharoBootstrapInitialization and related classes" Pull request url: https://github.com/pharo-project/pharo/pull/1935 Issue Url: https://pharo.fogbugz.com/f/cases/22599 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

[Pharo 7.0-dev] Build #1343: 22593-GZipReadStream-enhancement-Pharo-7-streams-and-tests

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

There is a new Pharo build available! The status of the build #1343 was: SUCCESS. The Pull Request #1929 was integrated: "22593-GZipReadStream-enhancement-Pharo-7-streams-and-tests" Pull request url: https://github.com/pharo-project/pharo/pull/1929 Issue Url: https://pharo.fogbugz.com/f/cases/22593 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

[Pharo 7.0-dev] Build #1342: 22223 Categorize classes in System-Changes

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

There is a new Pharo build available! The status of the build #1342 was: FAILURE. The Pull Request #1930 was integrated: "22223 Categorize classes in System-Changes" Pull request url: https://github.com/pharo-project/pharo/pull/1930 Issue Url: https://pharo.fogbugz.com/f/cases/22223 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

Open Croquet will ahve issues in next version of Mac OS X

by LawsonEnglish

https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/ <https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/> This sounds really cool, but thereâs an issue coming up: Apple is doing away with ANY support for 32-bit apps and plugins and of course, Croquet is built for 32-bits and uses 32-bit plugins all over the place. Croquet could STILL be the killer-app for Smalltalk even though it never realized its potential in the past, and it wonât be able to if something isnât done about the looming 32-bit vs 64-bit issue. Need I point out that it should work on Pharo just the same way it does on Squeak? L

Oct. 22, 2018

[Pharo 7.0-dev] Build #1341: 22591-MoticellowarnAboutLosingChangesTo-is-dead-code

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

There is a new Pharo build available! The status of the build #1341 was: FAILURE. The Pull Request #1927 was integrated: "22591-MoticellowarnAboutLosingChangesTo-is-dead-code" Pull request url: https://github.com/pharo-project/pharo/pull/1927 Issue Url: https://pharo.fogbugz.com/f/cases/22591 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 22, 2018

[ANN] Next Pharo Sprint: Oct 26

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Oct 26, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973622

Oct. 22, 2018

About #zipped / #unzipped

by Sven Van Caekenberghe

Hi, Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. (note also that there are no real users of these methods) Right now it seems cool that the following is an identity. 'foobar' zipped unzipped. However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. Of course, the current methods are broken, as can be seen from a more complex (wide) string. 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> The error results from some implicit/wrong character encoding being used. The right way to do this is to explicitly encode/decode the string. (GZipReadStream on: (ByteArray streamContents: [ :out | (GZipWriteStream on: out) nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; close ])) upToEnd utf8Decoded. >From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded What do you think ? Sven

Oct. 18, 2018