August 2017 - Pharo-dev - lists.pharo.org

Spec menu extensibility (epicea)
by Stephane Ducasse Aug. 10, 2017

Aug. 10, 2017

Hi guys I would like to know if there is a pattern to build extensible menu in Spec. For example, I extending Epicea to support pillar fileout so that I can turn a coding section into a pillar steps of action. I wanted to extend the epicea browser to get my menu in: But the code is like that: EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu aMenu addGroup: [ :aGroup | self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | aGroup addItem: [ :anItem | anItem name: oldStyleMenuItemArray first; description: oldStyleMenuItemArray third; icon: (self iconNamed: oldStyleMenuItemArray fourth); action: [ self perform: oldStyleMenuItemArray second ] ] ] ]. aMenu addGroup: [ :aGroup | aGroup addItem: [ :anItem | anItem name: 'Filters'; icon: (self iconNamed: #smallFindIcon); subMenu: self filtersSubMenu ] ]. aMenu addGroup: [ :aGroup | aGroup addItem: [ :anItem | anItem name: 'File Out'; description: 'Write selected entries to an Ombu file'; icon: (self iconNamed: #smallSaveAsIcon); action: [ self fileOutSelection ] ] ]. EPLogBrowserModel >> menuMorphForSelectedItems | aMenu | aMenu := MenuModel new. showEntryItemMenu ifTrue: [ self addMenuItemsForSelectedItemsIn: aMenu ]. ^ aMenu buildWithSpecAsPopup So I would like to improve Epicea but I face the problem of the limits of Spec (presumably). I'm thinking to add a <specMenu: 10> pragma to handle this case. Any thought. Stef

3 6

Updating the CI
by Guillermo Polito Aug. 10, 2017

Aug. 10, 2017

Hi all, I'm updating some CI plugins right now. Will notify as soon as everything is smooth again. The issue related to the update is here: https://pharo.fogbugz.com/f/cases/20299/Update-CI-plugins-to-latest-git-plu… (yes, we have an issue so we can keep track of the plugins we have) -- 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

1 1

[Pharo 70] build 25 / PR 182
by Pavel Krivanek Aug. 10, 2017

Aug. 10, 2017

Hi, next Pharo 7 build is available: https://pharo.fogbugz.com/f/cases/20286/Bootstrap- packages-are-dirty-in-a-fresh-image https://github.com/pharo-project/pharo/pull/182 -- Pavel

1 0

post-download preparation of Pharo 7 image
by Pavel Krivanek Aug. 10, 2017

Aug. 10, 2017

Hi, currently we are fighting with several issues that make contributions to Pharo 7 much more complicated than we would like. Even in case you have no troubles with long paths (on Windows) nor SSH keys, it is now not easy now to start to contribute or review pull requests. Let's say you already have: - a Github fork of pharo-project/pharo repository - a local clone of pharo-project/pharo repository on your disk - this repository has a 'remote' pointing to your fork that is named by your GitHub user name During bootstrap the Iceberg registers a repository from which the image was bootstrapped and binds Monticello working copies history to it. This repository is hidden by default, to see it in the repositories list you need to enable Iceberg setting named 'Include system repositories by default'. If you will do it, you will see that this repository is red. You need to manually set the real path to you local clone (Edit). Then you should set your fork as default push target (in Iceberg: select 'pharo' repository - 'Remotes' tab - context menu on your fork remote - Make default push remote). It is good to synchronize your fork with the origin so it will contain recent commits on the development branch. You can do it by doing PULL from the origin (pharo-project/pharo) and PUSH to your fork. The alternative is to create a pull request from the original repository to your fork in the GitHub web interface and then let merge it) The next optional step is to checkout the particular commit hash from which the image was bootstrapped. It is optional because the Iceberg now supports cherry picking so you can avoid of committing changes you do not want. But to start your branches from a state when the image working copy is in sync with the git working copy is of course cleaner. Currently the bootstrapped image has some packages that are marked as dirty and it will make mess if you will try to commit your changes. You can avoid it by reloading of these dirty packages. This will be not needed in future. All these steps you can automatized by the following code. You need to at least customize your repository clone path and GitHub user name. It is supposed to be run only once on freshly downloaded Pharo 7 image. | location userName pharoRepository fork | location := '/path/to/your/pharo/repository'. userName := 'github-user-name'. Iceberg showSystemRepositories: true. pharoRepository := IceRepository registry detect: [ :each | each name = 'No name' ]. pharoRepository location: location asFileReference. fork := pharoRepository remotes detect: [ :remote | remote remoteName = userName ]. pharoRepository pushRemote: fork. pharoRepository pullRemote: pharoRepository origin. pharoRepository checkoutBranch: 'development'. pharoRepository backend pullFrom: pharoRepository origin. pharoRepository push. pharoRepository checkoutBranch: (SystemVersion current commitHash). [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning do: [ :warning | warning resume: true ] As the result you should get a clean image based on the latest code that is ready to to create or review pull requests. Cheers, -- Pavel

2 1

[ Pharo 70 ] build 24 / PR 188
by Guillermo Polito Aug. 10, 2017

Aug. 10, 2017

This PR is only jenkins related, it does not modify any pharo code. https://pharo.fogbugz.com/f/cases/20297/Avoid-deadlocks-in-jenkins https://github.com/pharo-project/pharo/pull/188 It produced build 24. Build artifacts in here: http://files.pharo.org/image/70/ -- 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

1 0

[ Pharo 70 ] build 23 / PR 132
by Stephane Ducasse Aug. 10, 2017

Aug. 10, 2017

Hi https://pharo.fogbugz.com/f/cases/17848/SequenciableCollection-first-raise-… https://github.com/pharo-project/pharo/pull/132 Stef

1 0

[Pharo 70] build 19 / PR-168
by Stephane Ducasse Aug. 10, 2017

Aug. 10, 2017

https://pharo.fogbugz.com/f/cases/20238/Run-out-of-memory-the-image-hangs-w… https://github.com/pharo-project/pharo/pull/168 Now I get message that I do not understand test failure error from jenkins :( https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… I can tell you that leaving the confort zone of a working but weak process for the promise of a better one is still painful. Stef

2 2

[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