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

[Pharo 7.0-dev] Build #1174: 22315-remove-implicit-requirement-from-traits

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

There is a new Pharo build available! The status of the build #1174 was: SUCCESS. The Pull Request #1686 was integrated: "22315-remove-implicit-requirement-from-traits" Pull request url: https://github.com/pharo-project/pharo/pull/1686 Issue Url: https://pharo.fogbugz.com/f/cases/22315 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

[Pharo 7.0-dev] Build #1173: 22314-Stdio-doesnt-handle-cygwin-terminals-correctly

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

There is a new Pharo build available! The status of the build #1173 was: FAILURE. The Pull Request #1684 was integrated: "22314-Stdio-doesnt-handle-cygwin-terminals-correctly" Pull request url: https://github.com/pharo-project/pharo/pull/1684 Issue Url: https://pharo.fogbugz.com/f/cases/22314 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

Re: [Pharo-dev] Association hash vs equality

by Guillermo Polito

Actually, #= and #hash should be defined so: if (a=b) then a hash = b hash if a != b, it's not important This is required because some collections (like sets, dictionaries) will index their elements by their hash. Then, typically the collection implementation will first ask the hash, access the index with it, and retrieve the object if it is = only. Notice that several objects can have the same hash but be equals nonetheless. On Thu, Aug 16, 2018 at 11:36 AM Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > Hello, I've been looking at implementation of Associtation and LookupKey > (its > superclass). > In LookupKey, there is LookupKey>>#= and LookupKey>>#hash both implemented > to use key (compare keys and use hash of key), but in Association, > Association>>#= compares both key and value, but hash is not changed there, > so only hash of key is used, therefore it does not correspond to > implementation of method = ... shouldn't it? > > To demonstrate: > (1 -> #a) = (1 -> #b). > is false but > (1 -> #a) hash = (1 -> #b) hash. > is true > > I also noticed similar discussion for Doplhin smalltalk > http://forum.world.st/Association-gt-gt-hash-td3368868.html where guys > state > it is all right, but I still do not see why. > > Jan > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 16, 2018

Association hash vs equality

by Jan BlizniÄenko

Hello, I've been looking at implementation of Associtation and LookupKey (its superclass). In LookupKey, there is LookupKey>>#= and LookupKey>>#hash both implemented to use key (compare keys and use hash of key), but in Association, Association>>#= compares both key and value, but hash is not changed there, so only hash of key is used, therefore it does not correspond to implementation of method = ... shouldn't it? To demonstrate: (1 -> #a) = (1 -> #b). is false but (1 -> #a) hash = (1 -> #b) hash. is true I also noticed similar discussion for Doplhin smalltalk http://forum.world.st/Association-gt-gt-hash-td3368868.html where guys state it is all right, but I still do not see why. Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 16, 2018

[Pharo 7.0-dev] Build #1172: 22307-Refactoring-doesnt-work-in-debugger---Walkback-dnu-contentSelection

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

There is a new Pharo build available! The status of the build #1172 was: FAILURE. The Pull Request #1680 was integrated: "22307-Refactoring-doesnt-work-in-debugger---Walkback-dnu-contentSelection" Pull request url: https://github.com/pharo-project/pharo/pull/1680 Issue Url: https://pharo.fogbugz.com/f/cases/22307 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

[Pharo 7.0-dev] Build #1171: 22312-Integrate-Iceberg-v122

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

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

Aug. 16, 2018

Re: [Pharo-dev] Collection groupedBy: and groups order

by Damien Pollet

The problem is, there isn't really an order to preserve in the first place, since even if the original collection is a sequencable one, the elements of each group would be interleaved in it. I could see the point of sorting the keys though. On Tue, 14 Aug 2018 at 18:32, Petr Fischer via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Hello, I found a useful method in the collection - groupedBy: - the result > container is some PlugableDictionary (integer variant) and group order > (keys) is not preserved. > > Would not it be better to choose some other Dictionary variant, which > preserve the order of groups (like in source Collection)? > > pf > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 15, 2018

[Pharo 7.0-dev] Build #1170: 22137-gif-read-writer-refactoring-and-animated-images

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

There is a new Pharo build available! The status of the build #1170 was: FAILURE. The Pull Request #1666 was integrated: "22137-gif-read-writer-refactoring-and-animated-images" Pull request url: https://github.com/pharo-project/pharo/pull/1666 Issue Url: https://pharo.fogbugz.com/f/cases/22137 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 15, 2018

[Pharo 7.0-dev] Build #1169: Revert "Disabling OSX tests until the slave resucitates"

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

There is a new Pharo build available! The status of the build #1169 was: SUCCESS. The Pull Request #1688 was integrated: "Revert "Disabling OSX tests until the slave resucitates"" Pull request url: https://github.com/pharo-project/pharo/pull/1688 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 14, 2018

ZnHeaders should allow custom or empty Server info

by Torsten Bergmann

Hi Sven, when running a Zinc Server ZnServer startDefaultOn: 8080. the server currently reveals the framework, the framework version and the Pharo version the server is running on as part of the HTTP communication. For instance (ZnEasy get: 'http://localhost:8080') headers at: 'Server' would give Zinc HTTP Components 1.0 (Pharo/7.0) in the Server Header. While this is nice for debugging and during development this can be a problem in more secured/pentested environments where usually specific headers are turned off to not give specific informations to an attacker (to allow him to find vulnerabilities of specific versions or servers). While headers could be changed rewritten in front-ends or load balancing servers we can not assume that Pharo images work as backend server always. Webservers like Nginx, Apache, IIS, Express in JS, PHP and other allow to disable/modify these headers. Using the attached changeset it is possible to modify the Server header and customize it: ZnHeaders serverString: 'MoreSecureServer' If the server string is not customized the default server string is used as before. We should make sure this is integrated into Pharo 7 but also into the Zinc framework. I opened a bug https://pharo.fogbugz.com/f/cases/22317/ZnHeaders-should-allow-custom-or-em… As Zinc is also managed externally how should we proceed? Thx T.

Aug. 14, 2018