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

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

[pharo-project/pharo-core]

by GitHub

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

May 17, 2016

[pharo-project/pharo-core] 96698c: 60010

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 96698cbeb27393860effe85738f937fb4dd96338 https://github.com/pharo-project/pharo-core/commit/96698cbeb27393860effe857… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-17 (Tue, 17 May 2016) Changed paths: M Collections-Strings.package/String.class/instance/converting/repeat_.st M Collections-Tests.package/StringTest.class/instance/testing - converting/testRepeat.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60009.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60010.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60009.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60010.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60010 18229 Allow String>>#repeat: to repeat a string 0 times https://pharo.fogbugz.com/f/cases/18229 http://files.pharo.org/image/60/60010.zip

May 17, 2016

about spurious conflicts

by stepharo

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] UnifiedFFI Interrupted system call error on OSX

by stepharo

Le 17/5/16 Ã 21:33, Jan van de Sandt a Ã©crit : > Hi, > > I'm helping with the port of LibGit [1] from Pharo 4 to Pharo 5 [2]. BIG THANKS!!!! > This project provides Smalltalk bindings for the libgit2 library. Very > useful for better Git support in Pharo. The port means using the new > UnifiedFFI instead of NativeBoost. > > The project is still in the alpha stage but a lot of the libgit2 > features are already accessible. Some libgit2 calls access the > network. For example to clone a repository or to push a commit. The > calls that use https work on Linux and on Windows but on OSX we always > get the following error in Pharo 5: > > LGit_GIT_ERROR: Failed to connect to github.com <http://github.com>: > Interrupted system call. > > In Pharo4/NB this error does not occur. Could this be an issue in UFFI > or perhaps in the VM ? > > To reproduce the problem in Pharo 5 (after loading [2]): > > > | repo | > repo := LGitRepository on: 'my-test-repo' asFileReference. > repo cloneHttps: 'https://github.com/theseion/LibGit.git' > > > Jan. > > [1] https://github.com/theseion/LibGit > [2] https://github.com/jvdsandt/LibGit

May 17, 2016