- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60011 Home: https://github.com/pharo-project/pharo-core

May 18, 2016

Re: [Pharo-dev] about spurious conflicts

by Marcus Denker

The reason is that the merge does not find the âlast commonâ package. There is an issue that solves this (adding temporarily the Pharo5 repo). Marcus > On 17 May 2016, at 22:08, stepharo <stepharo(a)free.fr> wrote: > > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of the conflicts are > > not conflicts since the code of both methods and the protocols are the same. > > Does anybody experienced the same? > > Here are some examples and I'm puzzled. > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/417//artifact/valid… > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/418//artifact/valid… > > > Stef > >

May 18, 2016

Re: [Pharo-dev] fogbugz process Check seems to be stuck

by Alistair Grant

Hi Sven, On Wed, May 18, 2016 at 07:33:10AM +0200, Sven Van Caekenberghe wrote: > Hi Alistair, > > Everything is OK. > > Once Issue Validation succeeds, your slice is ready to be integrated (a review by another human would help too). Integration itself is a manual process done by an integrator. > > The reason there was a second check is that every time a new build is done, all open issues are rechecked. > > It got stuck, but also unstuck automatically. Thanks for the clarification, so I'll just wait for the issue to make its way through the system. Cheers, Alistair > > On 18 May 2016, at 07:03, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi All, > > > > Would someone mind clarifying the issue process for me. > > > > pharo.org states: > > > > In success, the state will be "Fix Reviewed by the Monkey". This is > > where humans come into the picture: your code needs to be reviewed, if > > possible by 2-3 people. If they accept it, the state moves to "Fix to > > Include", after which it will be committed to the development branch as > > soon as possible. > > > > After I submitted the slice to issue 18248 the monkey successfully > > reviewed it and then assigned it back to me. > > > > Then a little while later the monkey complained that the "Check seems to > > be stuck. I will try again". It looks like the second validation also > > succeeded. > > > > Do I need to do something to initiate the human review, or should I be > > taking some other action? > > > > Thanks, > > Alistair

May 18, 2016

File List -- MNU: RubTextEditor>>doIt

by Martin McClure

So I open Pharo 5, and the *very* *first* thing I do is to open a file list, select a file that contains the Metacello expression to load my project, and select "Do it" from the menu. And get MNU: RubTextEditor>>doIt :-( This was on Linux, in case that makes a difference. I couldn't quickly track down how this is *supposed* to work. Regards, -Martin

May 18, 2016

Re: [Pharo-dev] fogbugz process Check seems to be stuck

by Sven Van Caekenberghe

Hi Alistair, Everything is OK. Once Issue Validation succeeds, your slice is ready to be integrated (a review by another human would help too). Integration itself is a manual process done by an integrator. The reason there was a second check is that every time a new build is done, all open issues are rechecked. It got stuck, but also unstuck automatically. HTH, Sven > On 18 May 2016, at 07:03, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, > > Would someone mind clarifying the issue process for me. > > pharo.org states: > > In success, the state will be "Fix Reviewed by the Monkey". This is > where humans come into the picture: your code needs to be reviewed, if > possible by 2-3 people. If they accept it, the state moves to "Fix to > Include", after which it will be committed to the development branch as > soon as possible. > > After I submitted the slice to issue 18248 the monkey successfully > reviewed it and then assigned it back to me. > > Then a little while later the monkey complained that the "Check seems to > be stuck. I will try again". It looks like the second validation also > succeeded. > > Do I need to do something to initiate the human review, or should I be > taking some other action? > > Thanks, > Alistair > >

May 18, 2016

fogbugz process Check seems to be stuck

by Alistair Grant

Hi All, Would someone mind clarifying the issue process for me. pharo.org states: In success, the state will be "Fix Reviewed by the Monkey". This is where humans come into the picture: your code needs to be reviewed, if possible by 2-3 people. If they accept it, the state moves to "Fix to Include", after which it will be committed to the development branch as soon as possible. After I submitted the slice to issue 18248 the monkey successfully reviewed it and then assigned it back to me. Then a little while later the monkey complained that the "Check seems to be stuck. I will try again". It looks like the second validation also succeeded. Do I need to do something to initiate the human review, or should I be taking some other action? Thanks, Alistair

May 18, 2016

endless loop on debugging self or nil

by Nicolai Hess

evaluating "self" in an inspector workspace pane or "nil" with "do it" "inspect it" works. But if you use "debug it", enters an endless loop. I opened a bug report for squeak (bugs.squeak.org) and on fogbugz for pharo. I am not sure this bug has the same cause in squeak and pharo, because the stack trace is different. On pharo, this behavior starts with version 50519 with integrating a fix for issue 17251 "Quick method primitive not set correctly for #spurVMHeader" but I don't think this is the real cause of this behavior. nicolai

May 17, 2016

Re: [Pharo-dev] about spurious conflicts

by Denis Kudriashov

Yes. It should be solved by 18251 <https://pharo.fogbugz.com/f/cases/18251/add-50-repo-for-now-so-we-can-merge> 2016-05-17 22:08 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of > the conflicts are > > not conflicts since the code of both methods and the protocols are the > same. > > Does anybody experienced the same? > > Here are some examples and I'm puzzled. > > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/417//artifact/valid… > > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/418//artifact/valid… > > > Stef > > >

May 17, 2016

Re: [Pharo-dev] about spurious conflicts

by Max Leske

> On 17 May 2016, at 22:08, stepharo <stepharo(a)free.fr> wrote: > > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of the conflicts are > > not conflicts since the code of both methods and the protocols are the same. > > Does anybody experienced the same? > > Here are some examples and I'm puzzled. > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/417//artifact/valid… > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/418//artifact/valid… > > > Stef > > Yes, I saw the same with Fuel. But a simple manual merge with the latest version fixed that.

May 17, 2016

Re: [Pharo-dev] about spurious conflicts

by Nicolai Hess

2016-05-17 22:08 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of > the conflicts are > > not conflicts since the code of both methods and the protocols are the > same. > > Does anybody experienced the same? > > Here are some examples and I'm puzzled. > > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/417//artifact/valid… > > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/418//artifact/valid… > > The packages, these slices depends on, are older than what we have in the image. This packages were only in the inbox. Every new package version (Nautilus for example) we included afterwards, don't have these changes. I am afraid all this changes needs to be redone again. > > Stef > > >

May 17, 2016