- Pharo-dev - lists.pharo.org

Now this is fun ...

by Sven Van Caekenberghe

https://github.com/pharo ;-)

Nov. 5, 2018

[ANN] Pharo v7.0.0-rc1 released!

by Esteban Lorenzano

Greetings! Iâm announcing today we reach Pharo 7.0.0-rc1! This is the first step to release a definitive version, and while we will continue integrating bug fixes, API change Pull Requests will be delayed until the open of Pharo 8.0.0 development. Now, you would wonder what is the ChangeLog of this releaseâ¦ and answer is we still do not have one (btw, we should find a way to automate this). Anywayâ¦ we are very close to release now :) Please download, test, report issues. Esteban

Nov. 5, 2018

[Pharo 7.0-dev] Build #1362: 22627-Integrate-Iceberg-131

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

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

Nov. 5, 2018

Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]

by Ben Coman

On Mon, 5 Nov 2018 at 20:02, Stephan Eggermont <stephan(a)stack.nl> wrote: > Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users < > > pharo-users(a)lists.pharo.org> wrote: > > > > What is the current status of this? DelaySpinScheduler is default in my > recent Pharo 7 images and makes my images unusable on Ubuntu 18.04LTS. > The refactoring was enabled a month ago. DelaySemaphoreScheduler in the refactored hierarchy was made default so that DelaySpinScheduler could remain in place in the old hierarchy . https://github.com/pharo-project/pharo/blame/development/src/Kernel/Delay.c… On discord you mention that DelaySpinScheduler was the default in build 1358. But with PharoLauncher I just downloaded "Pharo-7.0.0-alpha.build.1358.sha.f9325e7.arch.32bit" and for me it shows DelaySemaphoreScheduler is the default. Evaluating ```Delay delaySchedulerClass``` ==> "DelaySemaphoreScheduler" and the process browser shows... [image: DelayScheduler-build-71358.png] So I'm curious how DelaySpinScheduler became enabled for you? cheers -ben P.S. a case was found where a process running at highestPriority (the same as the delay scheduling loop) that called Delay>>schedule: twice would lock DelaySpinScheduler - since the delay scheduling loop would not get an opportunity to process & clear the transfer-variable "delayToStart". I'd always worked with the assumption that the delay scheduling loop was the only process running at highest priority. DelaySemaphoreScheduler works fine with multiple highestPriority processes, so it will be the default going forward.

Nov. 5, 2018

[ANN] Iceberg v1.3.1

by Cyril Ferlicot

Hello! This week we are releasing the version v1.3 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.0 +https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.1) This version will be available after we merge this PR: https://github.com/pharo-project/pharo/pull/1951 This release contains some new features such as the support of self hosted gitlab, integration with github, etc. It also contains multiple bug fixes, cleanups and enhancements. On the CI part, Guille made the Appveyor build green! This will increase the stability of the windows support. Thanks to all contributors. Enjoy! Full changelog: Features #1021 Self hosted gitlab support #1027 Improved new tag dialog to generate semantic versionning tags #1044 Show a button "View on Github" when creating a PR #1008 Add "create branch from GitHub issue" option #1048 Add commands to open remotes on Github #1010 Add menu entry in extras to force calculate diff Bug corrections #975 Metacello asks too many times what to install when there are conflicting versions #980 Iceberg should Identify better the packages and the normal files #982 The Edit Project should have a Warning if it will affect the packages #986 Iceberg does not realize changes in extended classes #999 Pulling and pushing to a gitolite server asks password #984 Conversion to Tonel generates corrupted .properties #1041 Filter in repository view don't work with capital letters #1019 Metacello Integration leaves Monticello leftover repositories #859 Creating a branch and pushing does not sets the upstream #1043 Packages starting with lowercase not recognized #991 Error on right click in the project editon wizard #775 Reviewing a PR is broken #1036 Debugger if we try to merge without selecting a branch #1064 Fix failing tests regarding clean code in Pharo Enhancements #988 Iceberg should load the packages in a single MCLoader (This will make the loads of packages atomic) #1001 Use "instance creation" instead of "instance-creation" for method protocol name #1004 Use displayScaleFactor in UI #977 Add ToolTip help to the Commands #1030 Better support for binary files #1034 SSH passphrase is now hidden Cleanups #1018 Iceberg UI relies on deprecated classes from Spec and Commander #1051 Clean useless huge hierarchy in Github plugin UI Infrastructure Enhancements #1023 Fix CI for windows -- Cyril Ferlicot https://ferlicot.fr

Nov. 5, 2018

Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]

by Stephan Eggermont

Ben Coman <btc(a)openinworld.com> wrote: > On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > What is the current status of this? DelaySpinScheduler is default in my recent Pharo 7 images and makes my images unusable on Ubuntu 18.04LTS. Stephan

Nov. 5, 2018

[Pharo 7.0-dev] Build #1361: 22620-Move-zippedunzipped-from-String-to-ByteArray

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

There is a new Pharo build available! The status of the build #1361 was: FAILURE. The Pull Request #1947 was integrated: "22620-Move-zippedunzipped-from-String-to-ByteArray" Pull request url: https://github.com/pharo-project/pharo/pull/1947 Issue Url: https://pharo.fogbugz.com/f/cases/22620 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 5, 2018

[Pharo 7.0-dev] Build #1360: 22625-FileReferencenextVersion-gets-stuck-at-11

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

There is a new Pharo build available! The status of the build #1360 was: SUCCESS. The Pull Request #1950 was integrated: "22625-FileReferencenextVersion-gets-stuck-at-11" Pull request url: https://github.com/pharo-project/pharo/pull/1950 Issue Url: https://pharo.fogbugz.com/f/cases/22625 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 5, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Stephan Eggermont

Tim Mackinnon <tim(a)testit.works> wrote: > > In retrospect, Iâm wondering if successful projects that have proved > integration usefulness should be moved into the core repo? > (Iceberg/Calypso?) or are we missing something to help easily track the > journey of a multi faceted change (although this sounds overkill?). Or > are there sprint days to try and knock these things through easily with > everyone on board to do it together? > > We are sort of damned if you do and damned if you donât. But certainly we > want to endure that progress can be made without losing the will to contribute. > Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter. With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well. Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints. With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo. With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable. So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate. Is this helpful? Stephan

Nov. 5, 2018

[Pharo 7.0-dev] Build #1359: 22614-Integrate-Calypso-v0120

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

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

Nov. 5, 2018