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

[Pharo 7.0-dev] Build #923: 21929-Metacello-has-problem-with-archive-deletion-on-windows

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

There is a new Pharo build available! The status of the build #923 was: SUCCESS. The Pull Request #1385 was integrated: "21929-Metacello-has-problem-with-archive-deletion-on-windows" Pull request url: https://github.com/pharo-project/pharo/pull/1385 Issue Url: https://pharo.fogbugz.com/f/cases/21929 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

LibFFI/NB Cairo External Module Not Found debugging

by Peter UhnÃ¡k

Hi, some Windows users are repeatedly running into Pharo failing to load Cairo library on Windows (see stack screenshot at the bottom). The problem is that I have no idea how to even start debugging this. Is there some documentation on how Pharo loads libraries via FFI on Windows that I can start digging into? Note that the library is definitely present, as this happens only occasionally -- it can be fixed by restarting PC. But I cannot reasonably ask users to restart just because Pharo decided it doesn't feel like loading a library. Any pointers / docs / ideas appreciated. Thanks, Peter

May 19, 2018

[Pharo 7.0-dev] Build #922: 21926-PluggableButtonMorph-instance-valiable-lastColor-is-not-written

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

There is a new Pharo build available! The status of the build #922 was: SUCCESS. The Pull Request #1382 was integrated: "21926-PluggableButtonMorph-instance-valiable-lastColor-is-not-written" Pull request url: https://github.com/pharo-project/pharo/pull/1382 Issue Url: https://pharo.fogbugz.com/f/cases/21926 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

[Pharo 7.0-dev] Build #921: 19209-OrderedDictionary-not-storeOn-aStream-d-correctly

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

There is a new Pharo build available! The status of the build #921 was: FAILURE. The Pull Request #1358 was integrated: "19209-OrderedDictionary-not-storeOn-aStream-d-correctly" Pull request url: https://github.com/pharo-project/pharo/pull/1358 Issue Url: https://pharo.fogbugz.com/f/cases/19209 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

[Pharo 7.0-dev] Build #920: 21930-Display-the-progress-of-zip-downloads-in-Metacello

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

There is a new Pharo build available! The status of the build #920 was: FAILURE. The Pull Request #1386 was integrated: "21930-Display-the-progress-of-zip-downloads-in-Metacello" Pull request url: https://github.com/pharo-project/pharo/pull/1386 Issue Url: https://pharo.fogbugz.com/f/cases/21930 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

by Cyril Ferlicot D.

Le 18/05/2018 Ã 21:42, Sean P. DeNigris a Ã©critÂ : > Tim Mackinnon wrote >> Hi what does it mean âIceberg does not manage yet upgrade of the local >> clonesâ > > This is most commonly encountered when one enables shared repository > location in Iceberg. Say you already have a local clone of Zinc in the > shared root folder, but it's out of date. Then you try to load a project > which has Zinc as a dependency, but requires the current stable version. > Iceberg will just load from the outdated clone without trying to update from > the origin remote. > > This is exactly the problem! This is something I already described here: https://github.com/pharo-vcs/iceberg/issues/723 Here is what I wrote in that thread: With a project on Monticello managed via a ConfigurationOf, when you install it it will download the .mcz in the package cache and install the project with the version/baseline you asked. If you ask for development, you'll get the latest packages described in the "development" baseline. Now, with a project hosted on github and managed via a baseline, if the Iceberg Metacello integration is enabled, when I ask to load the branch "development", I'm not sure I'll get the latest version of the packages. If there is no local clone of the project it will clone the project and checkout the latest version of the branch. But, if I already have a local clone with the branch (not in sync with the remote branch), it will install the version present locally. This version might be 5 commits behind the remote branch. That's why, maybe Iceberg can check the remote branch before installing the repository and if the local branch is behind the remote branch, it can ask the user what to do. Either install the local version or pull the install. > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Cyril Ferlicot https://ferlicot.fr

May 19, 2018

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

by Sean P. DeNigris

Tim Mackinnon wrote > Hi what does it mean âIceberg does not manage yet upgrade of the local > clonesâ This is most commonly encountered when one enables shared repository location in Iceberg. Say you already have a local clone of Zinc in the shared root folder, but it's out of date. Then you try to load a project which has Zinc as a dependency, but requires the current stable version. Iceberg will just load from the outdated clone without trying to update from the origin remote. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 18, 2018

[Ann] OSSubprocess 1.0.0

by Guillermo Polito

Hi all, News from the OSSubprocess side. For those who do not know it, OSSubprocess is the library to call external processes from Pharo. These are the main points of this release. - 64bits support - Issues Working on both Pharo 6 and 7 - Issue #34: Adding tests to validate that the return code is correctly handled - Issue #27: Cleanup: remove OSSubprocess-Tests package - PR #26: Add stress tests This version works for Pharo >=6. Users of Pharo5 will need to stick with v0.2.5, because of non compatible changes in uFFI (required mostly for 64 bits). Additionally: - We moved the repository to pharo-contribution to remove pressure from Mariano for releases and integrations - We updated the configuration in the catalog - We decided to move to a 1.0.0 versioning schema because 0.* does look like the library is not stable and it actually is (We have been using it in pillar and iceberg for quite some time). You can load this version from the catalog or using with: Metacello new baseline: 'OSSubprocess'; repository: 'github://pharo-contributions/OSSubprocess:v1.0.0/repository'; load. Detailed changes log in - https://github.com/pharo-contributions/OSSubprocess/releases/tag/v1.0.0 - https://github.com/pharo-contributions/OSSubprocess/compare/v0.2.5...v1.0.0 If you have any issues (or PR!), we wait for your issue entry in https://github.com/pharo-contributions/OSSubprocess/issues Have a nice weekend, -- 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

May 18, 2018

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

by Tim Mackinnon

Hi what does it mean âIceberg does not manage yet upgrade of the local clonesâ As I noticed funny load characteristics when trying different library versions of things and not getting versions I thought I was getting. Is it that? Tim Sent from my iPhone > On 18 May 2018, at 15:24, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > >> Le 18/05/2018 Ã 15:21, Torsten Bergmann a Ã©crit : >> Thanks Sven for the #stable definition. >> >> That seems to solve the Zinc issue ... but now I run into a problem with #greaseInteger sent to a character >> in WAUrlEncoder class when loading Seaside-Core-Johan-Brichau.875. >> >> Screenshot attached. >> >> But #greaseInteger is not defined for Character, only for Number, Integer and String. >> >> To reproduce: I loaded Seaside from STHub using >> >> Metacello new >> baseline:'Seaside3'; >> repository: 'github://SeasideSt/Seaside:master/repository'; >> load >> >> on latest Pharo-7.0+alpha.build.917. >> > > I did not get the problem (yet). > > Can you check that your local Seaside and Grease clones are up to date? > Iceberg does not manage yet upgrade of the local clones :( > >> Thanks >> Torsten >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

May 18, 2018

[Pharo 7.0-dev] Build #918: 21644-RBRefersToClassRule-gives-misleading-advice-for-class-methods

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

There is a new Pharo build available! The status of the build #918 was: SUCCESS. The Pull Request #1380 was integrated: "21644-RBRefersToClassRule-gives-misleading-advice-for-class-methods" Pull request url: https://github.com/pharo-project/pharo/pull/1380 Issue Url: https://pharo.fogbugz.com/f/cases/21644 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 18, 2018