- Pharo-dev - lists.pharo.org

[Pharo 70] Build 22 / PR 169
by Stephane Ducasse Aug. 10, 2017

Aug. 10, 2017

Build 22 https://github.com/pharo-project/pharo/pull/169 https://pharo.fogbugz.com/f/cases/20249/Add-some-colors-to-the-themes

1 0

Pull requests ready to be reviewed
by Pavel Krivanek Aug. 10, 2017

Aug. 10, 2017

We have several pull requests validated successfully by the infrastructure. They need to be reviewed by humans: https://github.com/pharo-project/pharo/pull/75 https://github.com/pharo-project/pharo/pull/66 https://github.com/pharo-project/pharo/pull/175 https://github.com/pharo-project/pharo/pull/172 https://github.com/pharo-project/pharo/pull/169 https://github.com/pharo-project/pharo/pull/168 https://github.com/pharo-project/pharo/pull/134 Cheers, -- Pavel

4 3

Re: [Pharo-dev] Pharo 7 provisional HOWTO
by Nicolai Hess Aug. 9, 2017

Aug. 9, 2017

And if I only want to contribute by reviewing a fix. Do I have to go the git-path ? Or is there a way to just start up an image and load and review the change? Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" <pavel.krivanek(a)gmail.com >: 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi all, > > Just to be clear, in Pharo 7, if I want to get some code integrated: > - I *have to* use the pull request process described by Pavel > OR > - I *can* use the pull request process, but I can also use the old slice > monticello process > ? > > What is the answer to the first question now, and what will be the answer > of this question in 6 months from now ? > You should use the pull request process. It is possible to create a standard slice BUT it must be done from Pharo 6 and then sent into Pharo60Inbox. And then you need to wait until somebody converts this slice to pull request. That means that it will be harder and harder to contribute this way because the code-base is moving. No slice will be integrated into Pharo 7 with the old process directly. Cheers, -- Pavel > > Thanks > > > On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> >> wrote: >> >>> >>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: >>> >>> >>> >>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com >>>> >: >>>> >>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>> > >>>>> > >>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>> serge.stinckwich(a)gmail.com>: >>>>> >> >>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>> >> > Hi, >>>>> >> > >>>>> >> > this mail describes how to start to send pull requests to Pharo 7 >>>>> Github >>>>> >> > repository from Pharo 7. >>>>> >> >>>>> >> Thank you for the great explanation Pavel. >>>>> >> >>>>> >> > Preparations >>>>> >> > ===================== >>>>> >> > >>>>> >> > - you need to have a Github account and set SSH keys. See >>>>> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" button >>>>> and >>>>> >> > follow >>>>> >> > the instructions >>>>> >> >>>>> >> [ ... ] >>>>> >> >>>>> >> > Issue processing >>>>> >> > ===================== >>>>> >> > >>>>> >> > - create new case on FogBugz to get the issue number >>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>> repository do: >>>>> >> > Pharo >>>>> >> > - Create new branch from FogBugz issue, enter the issue ID and it >>>>> will >>>>> >> > fill >>>>> >> > the full branch name for you >>>>> >> > - create your changes (you can do it before the creation of the >>>>> branch >>>>> >> > too) >>>>> >> > - commit and push your changes in Iceberg, this way you will >>>>> commit your >>>>> >> > branch to your fork repository. Remember that the Iceberg commit >>>>> window >>>>> >> > has >>>>> >> > two buttons, one for local commit, the second for commit with >>>>> immediate >>>>> >> > push. They can be very long because they contain the full branch >>>>> (issue) >>>>> >> > name >>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >>>>> Create >>>>> >> > pull >>>>> >> > request, fill your >>>>> >> > - fill your Github credentials >>>>> >> > - leave the PR title, comment is not required, check the pull >>>>> request >>>>> >> > head >>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>> Create the >>>>> >> > pull >>>>> >> > requests >>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check your >>>>> pull >>>>> >> > requests and put URL of it into the issue record on FogBugz (as a >>>>> >> > comment). >>>>> >> > Resolve the issue as Fix review needed >>>>> >> >>>>> >> It means, there is no PR without a corresponding FogBugz issue ? >>>>> > >>>>> > >>>>> > Yes, at least for code changes we would like to keep this relation. >>>>> If it is >>>>> > a really trivial change in readme or something like that, we can >>>>> accept no >>>>> > related issue record. >>>>> > Please prefer to comment the issues instead of PRs directly to have >>>>> all >>>>> > information at one place. >>>>> >>>>> Thank you Pavel for the explanation. >>>>> >>>>> Maybe in the future, it will make sense to put everything in the PR >>>>> and use github issues. >>>>> You will use CI travis builds for all PR ? >>>>> >>>> >>>> For now we will use FogBugz because it has a lot of nice features and >>>> good API. Maybe we will switch it in future but now we should not change >>>> too many things at once :-) >>>> For several reasons we now prefer to use own infrastructure for >>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>> can be changed in future. >>>> >>>> >>> It would be interesting to see how this might fit in with our workflow... >>> https://blog.fogcreek.com/fogbugz-github-integration/ >>> >>> >>> >>> What is the benefit of the integration? I do not understand it from the >>> given link. >>> >>> >> When you submit a PR on github, Fogbugz is automatically updated with a >> link to the PR. >> Presumably this makes it easier for people reviewing cases in Fogbugz to >> identify the slice to test. >> This is a better link... >> https://blog.fogcreek.com/improved-github-integration-automa >> tically-create-bug-events-with-commits/ >> >> cheers -ben >> > >

8 25

Shouldn't new:0 fail for non-indexable classes
by Nicolai Hess Aug. 9, 2017

Aug. 9, 2017

see fogbugz 20246 ( https://pharo.fogbugz.com/f/cases/20246/Segfault-calling-new-0) Create a class with a single instance variable. call AClass new:0 -> segfaults (on windows latest vm). I can reproduce this on squeak (Squeak5.1-16549-32bit). It does not crash right away, but I was able to crash it by debugging into the new: call. from the comment of Behavior>>#new: , I would expect the error: self error: self printString, ' cannot have variable sized instances'

2 2

[Pharo 70] build 21 / PR 187
by Stephane Ducasse Aug. 9, 2017

Aug. 9, 2017

in PR 21 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… https://pharo.fogbugz.com/f/cases/20295/ Stef

1 0

[Pharo 70] build 18 / PR 66
by Stephane Ducasse Aug. 9, 2017

Aug. 9, 2017

20063-isDeprecated-should-consider-protocol-names Stef

1 0

[Pharo 70] PR 185 / Build 17
by Stephane Ducasse Aug. 9, 2017

Aug. 9, 2017

Hi We do not have yet an automated mail after each integration. So I will do it by hand. I'm going over the green issues https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… And integrating the ones I understand. Then I will look at the other ones. Stef [Pharo 70] PR 185 / Build 17 SLICE-Issue-18818-Add-labelled-simple-widget https://github.com/pharo-project/pharo/commit/73ffa96a4993ca482410437c91f39…

1 0

GTInspector auto refresh hooks?
by Denis Kudriashov Aug. 9, 2017

Aug. 9, 2017

Hi. Is there a way in GTInspector presentation to call some special updating block before each of auto refresh operation? I want something like: composite fastTable title: 'Devices'; display: [ devices ]; wantsAutomaticRefresh: true; * beforeUpdateDo: ["rows updating code"]* Imaging my presentation shows database table and I want query updated rows. (I activate updating by GTInspector setEnabledStepRefreshStatus: true). Best regards, Denis

2 3

Having green builds
by Guillermo Polito Aug. 9, 2017

Aug. 9, 2017

Hi all, As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!). In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state. Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always. Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :) https://github.com/pharo-project/pharo/pull/184 You can follow up all the things we did in the issue also: https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea). Enjoy, Guille and Pablo -- Guille Polito Research Engineer 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

6 6

fixing the tab morph
by Esteban Lorenzano Aug. 8, 2017

Aug. 8, 2017

Hi, Soâ¦ summer project (to do when there is too much hot to go outside): fix some minor things that are inside the image that annoys me since some time. First issue: the tab morph we have is horrible (and makes horrible anything with it). Iâve been working on it to fix that âchromish-but-badâ style we had and to fix some (a lot) hardcoded colors there. Now, for example, Calypso looks like this: which is IMHO a lot better :) some remarks: 1) I find TabManagerMorph an ugly name. Do you think we should change it? (I tend to think anything called *Manager, *Controller, etc. as a bad naming chose and probably the mark of a smell). 2) much more important: we should deprecate TabGroupMorph and LazyTabGroupMorph familyâ¦ there should not be more than one widget to do the same in the system. So well, as usual with old things: you fix a little thing and you uncover a lot of new problems :) Esteban

6 8