January 2019 - Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #105: 22870-Remove-Compiler-packages-from-Pharo

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

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

Jan. 8, 2019

New book: Pharo with Style

by ducasse

Thanks Esteban I saw your feedback and I will go over it soon. Just busy deprecating my google accounts and other job duties. Stef

Jan. 8, 2019

Re: [Pharo-dev] [Issue 19852] Cached settings and moving images

by ducasse

Thanks guille for this analysis. I would move it to Pharo 8.0 Now I think that we should revive your analysis on state because I would love to have first class objects with a good and nice logic for such cases and others. The lifetime of a variable looks more complex than it looks. > On 8 Jan 2019, at 12:19, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > I was checking issue https://pharo.fogbugz.com/f/cases/19852 <https://pharo.fogbugz.com/f/cases/19852> which is about the problems that arise when we move an image of location, and moreover when we move it between different platforms (windows to linux or mac for example). > > The problem are dangling file references pointing to invalid locations. > > We have found 4 of them: > > SystemResolver localdirectory is cached in a class variable > GTPlaybook caches the cache and stash directories in class variables > OMSessionStore retrieves at some point during startup an invalid file reference from the (wrongly cached) local directory > IceLibgitRepository Sharedrepositorieslocation is also cached > > All these are actually caused by settings, whose behavior is not defined when an image is moved. > There are several strange issues like, if we store settings, the local directory is stored, and then all images will (wrongly) use the same pharo-local directory of the first image. This is particularly annoying when using the launcher for example :). > > Now, we can leave this as it is right now and just move it to pharo8. > A quick fix for Pharo7 would be removing those settings and avoiding caching, but that is probably very disruptive too... > > Opinions? > > Guille

Jan. 8, 2019

[Issue 19852] Cached settings and moving images

by Guillermo Polito

Hi all, I was checking issue https://pharo.fogbugz.com/f/cases/19852 which is about the problems that arise when we move an image of location, and moreover when we move it between different platforms (windows to linux or mac for example). The problem are dangling file references pointing to invalid locations. We have found 4 of them: - SystemResolver localdirectory is cached in a class variable - GTPlaybook caches the cache and stash directories in class variables - OMSessionStore retrieves at some point during startup an invalid file reference from the (wrongly cached) local directory - IceLibgitRepository Sharedrepositorieslocation is also cached All these are actually caused by settings, whose behavior is not defined when an image is moved. There are several strange issues like, if we store settings, the local directory is stored, and then all images will (wrongly) use the same pharo-local directory of the first image. This is particularly annoying when using the launcher for example :). Now, we can leave this as it is right now and just move it to pharo8. A quick fix for Pharo7 would be removing those settings and avoiding caching, but that is probably very disruptive too... Opinions? Guille

Jan. 8, 2019

[Pharo 7.0] Build #104: 22867-Add-a-comment-to-Metacello-cypress-recent-fix

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

There is a new Pharo build available! The status of the build #104 was: SUCCESS. The Pull Request #2176 was integrated: "22867-Add-a-comment-to-Metacello-cypress-recent-fix" Pull request url: https://github.com/pharo-project/pharo/pull/2176 Issue Url: https://pharo.fogbugz.com/f/cases/22867 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 8, 2019

Vote for the Pharo mooc :)

by ducasse

Hi there is a competition for the mooc loved by its users: you can vote for the Pharo mooc at https://docs.google.com/forms/d/e/1FAIpQLSfPtKTnyRqJDlJ53A7Ml-nVoKRrz9ijz9L… Stef

Jan. 7, 2019

Bad naming of libfreetype in latest Pharo vm windows 64bits

by Guillermo Polito

Hi all, I'm trying the latest windows pharo VM 64bits (pharo-win-x86_64-201901051900-7a3c6b6.zip from http://files.pharo.org/vm/pharo-spur64/win/) to see how reproducible are the problems with freetype, athens and the bitblt. While in that I've found that libcairo does not load due to a bad naming of libfreetype. I had libfreetype.dll, and renaming it to libfreetype-6.dll made it loadable again. The 32bit windows VM that corresponds to the same commit, the freetype library file is also named libfreetype.dll but there it works. I've found that the specs for freetype for win64 in that commit are right: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/7a3c6b642312bc2778fd… but maybe the default ones are used? https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/7a3c6b642312bc2778fd… Does somebody know what else could be causing this? Tx, Guille

Jan. 7, 2019

[Pharo 7.0] Build #103: 22865-Metacello-Baselines-using-the-copy-functionality-over-a-p

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

There is a new Pharo build available! The status of the build #103 was: SUCCESS. The Pull Request #2173 was integrated: "22865-Metacello-Baselines-using-the-copy-functionality-over-a-p" Pull request url: https://github.com/pharo-project/pharo/pull/2173 Issue Url: https://pharo.fogbugz.com/f/cases/22865 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 6, 2019

[Pharo 7.0] Build #102: 22493-Classes-after-Removing-traits-should-not-have-methods-from-TraitedClass

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

There is a new Pharo build available! The status of the build #102 was: SUCCESS. The Pull Request #1847 was integrated: "22493-Classes-after-Removing-traits-should-not-have-methods-from-TraitedClass" Pull request url: https://github.com/pharo-project/pharo/pull/1847 Issue Url: https://pharo.fogbugz.com/f/cases/22493 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 6, 2019

Re: [Pharo-dev] [Pharo-users] New book: Pharo with Style

by Esteban Maringolo

I've read the whole booklet and I'm happy to follow most, if not all, the guidelines. Kent Beck's book was influential on this. I have a few remarks, though... Guideline 2.2 Typed variables should mention only existing or loadable types in the system. E.g selectFrom: aDate to: anotherDate and not selectFrom: aBeginningDate to: anEndDate (where Beginning and EndDate are not classes in the system) This affects guideline 2.3 because it says aBinaryBlock and there is no BinaryBlock class. I would also add another guideline here for the use of the 'as' preffix, e.g. asDate, asString, etc. where "as" means a different representation of receiver. E.g. asString is okay, while asShortString is not, because there is no ShortString class. Guideline 2.6 Should be "Number of" or "Count"? E.g. numberOfSomething or somethingCount? I don't like using "of" "with" or similar prepositions to name variables and classes. Guideline 3.2 #beSuprised would be better than #lookSurprised and follows a used convention of using #beSomething, e.g. #beBinary, #beReadOnly, etc. In the Guideline 5.6 the examples are the same. Regards! Esteban A. Maringolo El miÃ©., 2 ene. 2019 a las 2:33, Sean P. DeNigris via Pharo-dev (< pharo-dev(a)lists.pharo.org>) escribiÃ³: > Pharo Smalltalk Developers mailing list wrote > > Including what the method does, even when the code is fairly simple > > (OK, not getter / setter methods), is still useful. > > Yes, but... there is no free lunch. While there may be a benefit when the > code and comment are freshly written and in sync, they are duplication > which > smells whether code or comment and it is all too easy for the code to be > patched without updating the comment. Now that minor speedup turns into a > more significant slowdown when a user blindly follows the now-wrong > comment. > This possibility is made more likely be the fact that a stale comment will > not be picked up by the testing framework. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Jan. 6, 2019