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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Esteban Lorenzano

> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > 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? right now, you can review by going to github and seeing. I will add a âPR toolâ to view/load PRs into an image, but thatâs not ready. If someone wants to take a hit on itâ¦ the idea is to extend the github plugin with it :) cheers! Esteban > > Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: > > > 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@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 <mailto:btc@openinworld.com>> wrote: > > > On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: > >> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> escribiÃ³: >> >> >> >> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> >> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: >> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> > >> > >> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: >> >> >> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >> >> <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@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/ <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 <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 <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/ <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-automatically-create-… <https://blog.fogcreek.com/improved-github-integration-automatically-create-…> > > cheers -ben > > >

June 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

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 >> > >

June 28, 2017

[pharo-project/pharo-core]

by GitHub

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

June 28, 2017

[pharo-project/pharo-core] 72b8b1: 60503

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 72b8b154b3e120d81e3bf1cb7212a4202892cc85 https://github.com/pharo-project/pharo-core/commit/72b8b154b3e120d81e3bf1cb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-28 (Wed, 28 Jun 2017) Changed paths: M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F26%5F8_.st M FFI-Pools.package/FFIConstants.class/README.md M FFI-Pools.package/FFIConstants.class/class/pool initialization/initialize.st A FFI-Pools.package/FFIConstants.class/class/pool initialization/initializeCallingConventions.st A FFI-Pools.package/FFIConstants.class/class/pool initialization/initializeErrorConstants.st A FFI-Pools.package/FFIConstants.class/class/pool initialization/initializeTypeConstants.st R FFI-Pools.package/FFIConstants.class/class/private - initialization/initializeCallingConventions.st R FFI-Pools.package/FFIConstants.class/class/private - initialization/initializeErrorConstants.st R FFI-Pools.package/FFIConstants.class/class/private - initialization/initializeTypeConstants.st M Graphics-Files.package/PNGReadWriter.class/instance/pixel copies/copyPixelsRGBA_.st M Graphics-Files.package/PNGReadWriter.class/instance/pixel copies/copyPixelsRGBA_at_by_.st M Graphics-Files.package/PNGReadWriter.class/instance/pixel copies/copyPixelsRGB_.st M Graphics-Files.package/PNGReadWriter.class/instance/pixel copies/copyPixelsRGB_at_by_.st A Graphics-Tests.package/PNGReadWriterTest.class/instance/tests - decoding/testNewFromSampleBytes.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60502.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60503.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60502.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60503.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI.package/FFICallbackType.class/instance/emitting code/offsetWriteFieldAt_with_.st M UnifiedFFI.package/FFIExternalStructure.class/class/accessing/structureAlignment.st A UnifiedFFI.package/FFIExternalStructureReferenceHandle.class/instance/accessing/getHandle.st M UnifiedFFI.package/FFIExternalStructureType.class/instance/emitting code/offsetReadReferenceAt_.st M UnifiedFFI.package/FFIExternalStructureType.class/instance/emitting code/readReferenceAt_.st M UnifiedFFI.package/FFISizeT.class/class/converting/asExternalTypeOn_.st A UnifiedFFI.package/FFISizeT.class/instance/emitting code/readFieldAt_.st A UnifiedFFI.package/FFISizeT.class/instance/emitting code/writeFieldAt_with_.st M UnifiedFFI.package/FFISizeT.class/instance/private/basicHandle_at_.st M UnifiedFFI.package/FFISizeT.class/instance/private/basicHandle_at_put_.st M UnifiedFFI.package/extension/ExternalType/instance/offsetReadFieldAt_.st A UnifiedFFI.package/extension/ExternalType/instance/offsetReadStructFieldAt_.st M UnifiedFFI.package/extension/ExternalType/instance/offsetWriteFieldAt_with_.st A UnifiedFFI.package/extension/ExternalType/instance/offsetWriteStructFieldAt_with_.st Log Message: ----------- 60503 20167 Regression with PNGReaderWriter in P6 https://pharo.fogbugz.com/f/cases/20167 20198 inner structure access does not work on multiple architecture https://pharo.fogbugz.com/f/cases/20198 http://files.pharo.org/image/60/60503.zip

June 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Pavel Krivanek

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 >> > >

June 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by ClÃ©ment Bera

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 ? 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- > automatically-create-bug-events-with-commits/ > > cheers -ben >

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Sven Van Caekenberghe

> On 27 Jun 2017, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. I made the code easier to load. The default group loads P3Client and its basic dependencies NeoJSON and ZTimestamp Metacello new baseline: 'P3'; repository: 'github://svenvc/P3'; load. The glorp group loads P3DatabaseDriver and the whole of Glorp (warning: large download) Metacello new baseline: 'P3'; repository: 'github://svenvc/P3'; load: 'glorp'. > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! >

June 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Ben Coman

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-automatically-create-… cheers -ben

June 28, 2017

[FT improvements] [GSoC] [guidance needed] move some of the data source responsibilities to the cells

by Elhamer

Dear Pharo community, I've been working on improving the FT package recently and i would like to get your opinions about introducing a new cell data source layer. The idea is to move some of the data source responsibilities to the <cell data source, cell morph> in order to have a 'less dumber cell morphs' and a better design that reduces the complexity of extending the functionalities of a fast table. The changes are kind of expensive and might break Glamour and some other FT-based packages out there (unless the new implementation is integrated in the FT package as an alternative way -the old implementation will be deprecated and removed progressively-). There three main parts in the fast table package: - The data source - The table Morph - The cell Morph In the current design, all data managements are centralized around the data source. The Data source has the following responsibilities (schema below): - Creates the cell Morphs and populate them (cellColumn: column row: rowIndex). - Creates the header cells Morphs. - Manipulates the data that will be used to populate the table. - Updates the cell data (when the strong selection announcement is handled for example). <http://forum.world.st/file/n4952783/old_impl.png> * Limitation of this design:* - A high level of complexity in the data source. - The cell morph is a dumb object and itâs not being used to its full potential. - Extending the cell functionalities (usually done from the data source) can be challenging. A better design would be for the cell morph to interact directly with a new layer of data source âthe cell data sourceâ, and the cell's data source will propagate to the tableâs data source (the table refresh will triggered from the table's data source). Here are the responsibilities for each part (schema below): *The cell Morph responsibilities:* - Handle mouse/keyboard events and fire announcements. *The cell data source responsibilities:* - Handles cellâs announcements and manage cellâs data. - Propagates the changes to the data source. - Creates the cell morphs. *The tableâs data source responsibilities:* - Send refresh messages to the table morph when data changed. - Create the cell data sources object for each data element. *The table morph responsibilities:* - Render the morphs/widgets â¦ - Handle column/row selection. - â¦ <http://forum.world.st/file/n4952783/new_impl.png> *Requirement changes:* *The cell data source:* - A light version of the data source package to manage cell content. - â¦ *Announcements:* - Create new cells announcements that propagate the required properties to the cell's data source to handle data changes. - Propagate those announcements when the required event is fired on the cell morph. - â¦ *The data source* - Creates cells' data sources instead of cell Morphs. - â¦ *The cell Morph* - Fires the announcements, plus some tiny changes to bound the morph to its data source. - â¦ *The table Morph* - The FTTableMorph doesnât need much modification, just few changes here and there, The FTTableContainerMorph might be improved as well to take advantage from the fact that the cell morph knows its data (probably a better exposed-rows updates). - â¦ *Notes:* - These updates will definitely break Glamour, so some changes to the Glamour FT package is also required. - The best way to introduce these changes is by adding this new cell data source layer side by side with the current implementation, and mark the old implementation as deprecated (will be removed progressively in the next versions). Thank you :) Best regards, Elhamer. -- View this message in context: http://forum.world.st/FT-improvements-GSoC-guidance-needed-move-some-of-the… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Pierce Ng

On Tue, Jun 27, 2017 at 02:56:48PM +0200, Sven Van Caekenberghe wrote: > P3 is a modern, lean and mean PostgreSQL client for Pharo. > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. This is great stuff! Pierce

June 28, 2017