- Pharo-dev - lists.pharo.org

Sources location inconsistency between WIndows and OSX

by Aliaksei Syrel

Hi, I just realised that on OSX it is enough to put .sources in the same folder with Pharo.app which is extremely cool because there is no need to carry them around with images. However, in case of Window it is different. I tried to put .source in the same folder with Pharo.exe but got a notification that sources in the *image* folder were not found. It would be great to unify this behaviour among platforms :) I prefer OSX .sources location strategy. Cheers, Alex

June 28, 2017

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

by Aliaksei Syrel

But now OSX latest VM (http://files.pharo.org/vm/pha ro-spur32/mac/pharo-mac-i386-201706280928-1bd79a7.zip) crashes when trying to load a project using Iceberg without crash.dmp. I only get the following in terminal: Pharo(4280,0xa6f3b1c0) malloc: *** error for object 0x8416a314: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug I tested with both 60501 and 60503 images to prove that it is a VM problem, because it works well with 60501 and Stable :) Maybe it is somehow related to the new version of libgit in the latest vm... Cheers, Alex On 28 June 2017 at 18:26, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Eliot, > > I confirm that OSX performance issue is fixed in latest VM ( > http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-2 > 01706280928-1bd79a7.zip). > Thanks a lot! > > Cheers, > Alex > > On 22 June 2017 at 08:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> >> >> On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Clement why you cannot load OSSubprocess? >>> >>> >> 1) project has to work on itimer Linux VM. >> 2) existing project working with OSProcess and I don't want to spend time >> migrating. >> 3) code base has to work at least in Squeak and Pharo, I don't want to >> add extra code so it uses different frameworks in different platforms and >> then maintain this extra code. >> >> >>> >>> >>> On Tue, Jun 20, 2017 at 3:10 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> > Hi Thierry, hi all, >>> > >>> > The Pharo catalog version of OSProcess is not working in the Pharo 6 >>> release >>> > and I need to load OSProcess in one of my projects. I cannot load >>> > OSSubProcess instead, so no need to answer this mail talking about it. >>> > >>> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os >>> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess >>> tests the >>> > version number against 1000, and should now test against 10. >>> > >>> > I checked the SqueakSource repo of OSProcess, I can see that the last >>> > version is 4.6.8 and the catalog configuration loads an older version, >>> but I >>> > cannot see any fix related to the version number ? >>> > >>> > Can someone update the OSProcess configuration in the Pharo catalog so >>> that >>> > it loads a working version in the Pharo 6 release or point me to an >>> > OSProcess configuration, outside of the catalog, which works in the >>> release >>> > of Pharo 6 please ? >>> > >>> > Thank you very much. >>> > >>> > Clement >>> >>> >> >

June 28, 2017

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

by Aliaksei Syrel

Hi Eliot, I confirm that OSX performance issue is fixed in latest VM ( http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201706280928-1bd7… ). Thanks a lot! Cheers, Alex On 22 June 2017 at 08:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Clement why you cannot load OSSubprocess? >> >> > 1) project has to work on itimer Linux VM. > 2) existing project working with OSProcess and I don't want to spend time > migrating. > 3) code base has to work at least in Squeak and Pharo, I don't want to add > extra code so it uses different frameworks in different platforms and then > maintain this extra code. > > >> >> >> On Tue, Jun 20, 2017 at 3:10 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> > Hi Thierry, hi all, >> > >> > The Pharo catalog version of OSProcess is not working in the Pharo 6 >> release >> > and I need to load OSProcess in one of my projects. I cannot load >> > OSSubProcess instead, so no need to answer this mail talking about it. >> > >> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os >> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess >> tests the >> > version number against 1000, and should now test against 10. >> > >> > I checked the SqueakSource repo of OSProcess, I can see that the last >> > version is 4.6.8 and the catalog configuration loads an older version, >> but I >> > cannot see any fix related to the version number ? >> > >> > Can someone update the OSProcess configuration in the Pharo catalog so >> that >> > it loads a working version in the Pharo 6 release or point me to an >> > OSProcess configuration, outside of the catalog, which works in the >> release >> > of Pharo 6 please ? >> > >> > Thank you very much. >> > >> > Clement >> >> >

June 28, 2017

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