Re: [Pharo-dev] Pharo 7 provisional HOWTO
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@gmail.com
:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com
:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/ - 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
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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@gmail.com <mailto:pavel.krivanek@gmail.com>>:
2017-06-28 17:06 GMT+02:00 Clément Bera <bera.clement@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@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud.com <mailto:juraj.kubelka@icloud.com>> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>>: On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <pavel.krivanek@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-b... <https://blog.fogcreek.com/improved-github-integration-automatically-create-b...>
cheers -ben
What is the github plugin? an Iceberg Pharo code or a C plugin? On Wed, Jun 28, 2017 at 6:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/ - 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-b...
cheers -ben
It is an iceberg plugin. 100% Pharo Code, uses the github.com rest api. On 30 Jun 2017 09:25, "Stephane Ducasse" <stepharo.self@gmail.com> wrote:
What is the github plugin? an Iceberg Pharo code or a C plugin?
On Wed, Jun 28, 2017 at 6:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <
juraj.kubelka@icloud.com>
wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/ - 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
2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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
Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error : Image: Pharo7.0SNAPSHOT [Latest update: #0] LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1 LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil And finally after some more tries, the vm crashed (crash.dmp attached). If this only happens on windows, what else would be an option to start with contributing for pharo 7 ?
Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < pavel.krivanek@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud.com
wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich < serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/ - 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
2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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
Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error :
Image: Pharo7.0SNAPSHOT [Latest update: #0]
LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1
LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
And finally after some more tries, the vm crashed (crash.dmp attached).
If this only happens on windows, what else would be an option to start with contributing for pharo 7 ?
maybe I am doing something wrong ? I thought this should work now with the latest vm (and libgit)? It is still crashing for me. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository UndefinedObject>>DoIt VM windows 32 bit: CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < pavel.krivanek@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < juraj.kubelka@icloud.com> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich < serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/ - 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
Hey, is it possible to integrate updates to external projects (like Renraku) into Pharo 7? Uko
On 10 Jul 2017, at 22:01, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@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
Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error :
Image: Pharo7.0SNAPSHOT [Latest update: #0]
LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1
LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
And finally after some more tries, the vm crashed (crash.dmp attached).
If this only happens on windows, what else would be an option to start with contributing for pharo 7 ?
maybe I am doing something wrong ? I thought this should work now with the latest vm (and libgit)? It is still crashing for me.
[31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository UndefinedObject>>DoIt
VM windows 32 bit: CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $
Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>>:
2017-06-28 17:06 GMT+02:00 Clément Bera <bera.clement@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@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud.com <mailto:juraj.kubelka@icloud.com>> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>>: On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <pavel.krivanek@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-b... <https://blog.fogcreek.com/improved-github-integration-automatically-create-b...>
cheers -ben
Yes, they should be be provided as standard pull requests from the package maintainers. -- Pavel 2017-07-11 12:15 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>: > Hey, is it possible to integrate updates to external projects (like > Renraku) into Pharo 7? > > Uko > > On 10 Jul 2017, at 22:01, Nicolai Hess <nicolaihess@gmail.com> wrote: > > > > 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>: > >> >> >> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>: >> >>> >>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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 >>> >> >> Anyone got this working on windows (32) ? >> I followed this guide, enabled the ssh key setting for iceberg. >> But I still got the error : >> >> Image: Pharo7.0SNAPSHOT [Latest update: #0] >> >> LGitReturnCodeEnum>>handleLGitReturnCode >> Receiver: a LGitReturnCodeEnum(#git_error [-1]) >> Arguments and temporary variables: >> handler: LGit_GIT_ERROR >> Receiver's instance variables: >> value: -1 >> >> >> LGitRepository(LGitExternalObject)>>withReturnHandlerDo: >> Receiver: a LGitRepository (<not initialized>) >> Arguments and temporary variables: >> callBlock: [ self >> clone: self >> url: aString >> local_path: aFileReference pathSt...etc... >> Receiver's instance variables: >> handle: @ 16r00000000 >> repositoryPath: File @ pharo-core >> isOpen: nil >> workingDirectory: nil >> >> >> LGitRepository>>clone:options:to: >> Receiver: a LGitRepository (<not initialized>) >> Arguments and temporary variables: >> aString: 'git@github.com:pharo-project/pharo.git' >> cloneOptions: a LGitCloneOptions () >> aFileReference: File @ pharo-core >> Receiver's instance variables: >> handle: @ 16r00000000 >> repositoryPath: File @ pharo-core >> isOpen: nil >> workingDirectory: nil >> >> >> And finally after some more tries, the vm crashed >> (crash.dmp attached). >> >> If this only happens on windows, what else would be an option to start >> with contributing for pharo 7 ? >> > > maybe I am doing something wrong ? I thought this should work now with the > latest vm (and libgit)? > It is still crashing for me. > > [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed > [0mExternalAddress class(Object)>>primitiveFailed: > ExternalAddress class(Object)>>primitiveFailed > ExternalAddress class>>allocate: > LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew > LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults > LGitRemoteCallbacks class>>defaults > LGitRemoteCallbacks class>>withProvider: > LGitCloneOptions class>>withCredentialsProvider: > [ | repo cloneOptions | > repo := LGitRepository on: self location. > cloneOptions := LGitCloneOptions > withCredentialsProvider: IceCredentialsProvider default. > repo clone: url options: cloneOptions. > aBranchName ifNotNil: [ repo checkout: aBranchName ]. > (LGitRemote of: repo named: 'origin') > lookup; > setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > in Block: [ | repo cloneOptions |... > [ self checkInitialized. > [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed > [0mExternalAddress class(Object)>>primitiveFailed: > ExternalAddress class(Object)>>primitiveFailed > ExternalAddress class>>allocate: > LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew > LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults > LGitRemoteCallbacks class>>defaults > LGitRemoteCallbacks class>>withProvider: > LGitCloneOptions class>>withCredentialsProvider: > [ | repo cloneOptions | > repo := LGitRepository on: self location. > cloneOptions := LGitCloneOptions > withCredentialsProvider: IceCredentialsProvider default. > repo clone: url options: cloneOptions. > aBranchName ifNotNil: [ repo checkout: aBranchName ]. > (LGitRemote of: repo named: 'origin') > lookup; > setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > in Block: [ | repo cloneOptions |... > [ self checkInitialized. > aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self > checkInitialized.... > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in > Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > LGitActionSequence(DynamicVariable)>>value:during: > LGitActionSequence class(DynamicVariable class)>>value:during: > LGitGlobal class>>runSequence: > IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > IceRepositoryCreator>>createRepository > UndefinedObject>>DoIt > > VM windows 32 bit: > CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c > Jul 10 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 > VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > > > >> >> >> >>> >>> >>> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >>> pavel.krivanek@gmail.com>: >>> >>> >>> >>> 2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud. >>>>> com> wrote: >>>>> >>>>>> >>>>>> El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek@ >>>>>> gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich@ >>>>>>> gmail.com>: >>>>>>> >>>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>>> <pavel.krivanek@gmail.com> wrote: >>>>>>>> > >>>>>>>> > >>>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>>> serge.stinckwich@gmail.com>: >>>>>>>> >> >>>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>>> >> <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/ >>>>>>>> >> > - 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 >>>>> >>>> >
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows... -- Pavel 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>: > > > 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>: > >> >> >> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>: >> >>> >>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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 >>> >> >> Anyone got this working on windows (32) ? >> I followed this guide, enabled the ssh key setting for iceberg. >> But I still got the error : >> >> Image: Pharo7.0SNAPSHOT [Latest update: #0] >> >> LGitReturnCodeEnum>>handleLGitReturnCode >> Receiver: a LGitReturnCodeEnum(#git_error [-1]) >> Arguments and temporary variables: >> handler: LGit_GIT_ERROR >> Receiver's instance variables: >> value: -1 >> >> >> LGitRepository(LGitExternalObject)>>withReturnHandlerDo: >> Receiver: a LGitRepository (<not initialized>) >> Arguments and temporary variables: >> callBlock: [ self >> clone: self >> url: aString >> local_path: aFileReference pathSt...etc... >> Receiver's instance variables: >> handle: @ 16r00000000 >> repositoryPath: File @ pharo-core >> isOpen: nil >> workingDirectory: nil >> >> >> LGitRepository>>clone:options:to: >> Receiver: a LGitRepository (<not initialized>) >> Arguments and temporary variables: >> aString: 'git@github.com:pharo-project/pharo.git' >> cloneOptions: a LGitCloneOptions () >> aFileReference: File @ pharo-core >> Receiver's instance variables: >> handle: @ 16r00000000 >> repositoryPath: File @ pharo-core >> isOpen: nil >> workingDirectory: nil >> >> >> And finally after some more tries, the vm crashed >> (crash.dmp attached). >> >> If this only happens on windows, what else would be an option to start >> with contributing for pharo 7 ? >> > > maybe I am doing something wrong ? I thought this should work now with the > latest vm (and libgit)? > It is still crashing for me. > > [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed > [0mExternalAddress class(Object)>>primitiveFailed: > ExternalAddress class(Object)>>primitiveFailed > ExternalAddress class>>allocate: > LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew > LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults > LGitRemoteCallbacks class>>defaults > LGitRemoteCallbacks class>>withProvider: > LGitCloneOptions class>>withCredentialsProvider: > [ | repo cloneOptions | > repo := LGitRepository on: self location. > cloneOptions := LGitCloneOptions > withCredentialsProvider: IceCredentialsProvider default. > repo clone: url options: cloneOptions. > aBranchName ifNotNil: [ repo checkout: aBranchName ]. > (LGitRemote of: repo named: 'origin') > lookup; > setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > in Block: [ | repo cloneOptions |... > [ self checkInitialized. > [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed > [0mExternalAddress class(Object)>>primitiveFailed: > ExternalAddress class(Object)>>primitiveFailed > ExternalAddress class>>allocate: > LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew > LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults > LGitRemoteCallbacks class>>defaults > LGitRemoteCallbacks class>>withProvider: > LGitCloneOptions class>>withCredentialsProvider: > [ | repo cloneOptions | > repo := LGitRepository on: self location. > cloneOptions := LGitCloneOptions > withCredentialsProvider: IceCredentialsProvider default. > repo clone: url options: cloneOptions. > aBranchName ifNotNil: [ repo checkout: aBranchName ]. > (LGitRemote of: repo named: 'origin') > lookup; > setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > in Block: [ | repo cloneOptions |... > [ self checkInitialized. > aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self > checkInitialized.... > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in > Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > LGitActionSequence(DynamicVariable)>>value:during: > LGitActionSequence class(DynamicVariable class)>>value:during: > LGitGlobal class>>runSequence: > IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > IceRepositoryCreator>>createRepository > UndefinedObject>>DoIt > > VM windows 32 bit: > CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c > Jul 10 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 > VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > > > >> >> >> >>> >>> >>> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >>> pavel.krivanek@gmail.com>: >>> >>> >>> >>> 2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < >>>>> juraj.kubelka@icloud.com> wrote: >>>>> >>>>>> >>>>>> El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>>>> pavel.krivanek@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>>>> serge.stinckwich@gmail.com>: >>>>>>> >>>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>>> <pavel.krivanek@gmail.com> wrote: >>>>>>>> > >>>>>>>> > >>>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>>> serge.stinckwich@gmail.com>: >>>>>>>> >> >>>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>>> >> <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-s >>>>>>>> sh/ >>>>>>>> >> > - 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 >>>>> >>>> >>>> >>> >>> >>> >> >
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>: > What is the system you use? > AFAIK Esteban is fixing the latest Iceberg because it stopped to work on > Windows... > > -- Pavel > windows 10 32 bit > > 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>: > >> >> >> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>: >> >>> >>> >>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>: >>> >>>> >>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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 >>>> >>> >>> Anyone got this working on windows (32) ? >>> I followed this guide, enabled the ssh key setting for iceberg. >>> But I still got the error : >>> >>> Image: Pharo7.0SNAPSHOT [Latest update: #0] >>> >>> LGitReturnCodeEnum>>handleLGitReturnCode >>> Receiver: a LGitReturnCodeEnum(#git_error [-1]) >>> Arguments and temporary variables: >>> handler: LGit_GIT_ERROR >>> Receiver's instance variables: >>> value: -1 >>> >>> >>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo: >>> Receiver: a LGitRepository (<not initialized>) >>> Arguments and temporary variables: >>> callBlock: [ self >>> clone: self >>> url: aString >>> local_path: aFileReference pathSt...etc... >>> Receiver's instance variables: >>> handle: @ 16r00000000 >>> repositoryPath: File @ pharo-core >>> isOpen: nil >>> workingDirectory: nil >>> >>> >>> LGitRepository>>clone:options:to: >>> Receiver: a LGitRepository (<not initialized>) >>> Arguments and temporary variables: >>> aString: 'git@github.com:pharo-project/pharo.git' >>> cloneOptions: a LGitCloneOptions () >>> aFileReference: File @ pharo-core >>> Receiver's instance variables: >>> handle: @ 16r00000000 >>> repositoryPath: File @ pharo-core >>> isOpen: nil >>> workingDirectory: nil >>> >>> >>> And finally after some more tries, the vm crashed >>> (crash.dmp attached). >>> >>> If this only happens on windows, what else would be an option to start >>> with contributing for pharo 7 ? >>> >> >> maybe I am doing something wrong ? I thought this should work now with >> the latest vm (and libgit)? >> It is still crashing for me. >> >> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed >> [0mExternalAddress class(Object)>>primitiveFailed: >> ExternalAddress class(Object)>>primitiveFailed >> ExternalAddress class>>allocate: >> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >> LGitRemoteCallbacks class>>defaults >> LGitRemoteCallbacks class>>withProvider: >> LGitCloneOptions class>>withCredentialsProvider: >> [ | repo cloneOptions | >> repo := LGitRepository on: self location. >> cloneOptions := LGitCloneOptions >> withCredentialsProvider: IceCredentialsProvider default. >> repo clone: url options: cloneOptions. >> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >> (LGitRemote of: repo named: 'origin') >> lookup; >> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >> in Block: [ | repo cloneOptions |... >> [ self checkInitialized. >> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed >> [0mExternalAddress class(Object)>>primitiveFailed: >> ExternalAddress class(Object)>>primitiveFailed >> ExternalAddress class>>allocate: >> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >> LGitRemoteCallbacks class>>defaults >> LGitRemoteCallbacks class>>withProvider: >> LGitCloneOptions class>>withCredentialsProvider: >> [ | repo cloneOptions | >> repo := LGitRepository on: self location. >> cloneOptions := LGitCloneOptions >> withCredentialsProvider: IceCredentialsProvider default. >> repo clone: url options: cloneOptions. >> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >> (LGitRemote of: repo named: 'origin') >> lookup; >> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >> in Block: [ | repo cloneOptions |... >> [ self checkInitialized. >> aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self >> checkInitialized.... >> [ activeProcess psValueAt: index put: anObject. >> aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in >> Block: [ activeProcess psValueAt: index put: anObject.... >> BlockClosure>>ensure: >> LGitActionSequence(DynamicVariable)>>value:during: >> LGitActionSequence class(DynamicVariable class)>>value:during: >> LGitGlobal class>>runSequence: >> IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >> IceRepositoryCreator>>createRepository >> UndefinedObject>>DoIt >> >> VM windows 32 bit: >> CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c >> Jul 10 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 >> VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> >> >> >>> >>> >>> >>>> >>>> >>>> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >>>> pavel.krivanek@gmail.com>: >>>> >>>> >>>> >>>> 2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < >>>>>> juraj.kubelka@icloud.com> wrote: >>>>>> >>>>>>> >>>>>>> El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> >>>>>>> escribió: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>>>>> pavel.krivanek@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>>>>> serge.stinckwich@gmail.com>: >>>>>>>> >>>>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>>>> <pavel.krivanek@gmail.com> wrote: >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>>>> serge.stinckwich@gmail.com>: >>>>>>>>> >> >>>>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>>>> >> <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-s >>>>>>>>> sh/ >>>>>>>>> >> > - 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system on both, it crashes on working with libgit/iceberg
2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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
Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error :
Image: Pharo7.0SNAPSHOT [Latest update: #0]
LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1
LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
And finally after some more tries, the vm crashed (crash.dmp attached).
If this only happens on windows, what else would be an option to start with contributing for pharo 7 ?
maybe I am doing something wrong ? I thought this should work now with the latest vm (and libgit)? It is still crashing for me.
[31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository UndefinedObject>>DoIt
VM windows 32 bit: CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < pavel.krivanek@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < juraj.kubelka@icloud.com> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich < serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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-s sh/ - 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
2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system
on both, it crashes on working with libgit/iceberg
Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ? Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ?
2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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
Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error :
Image: Pharo7.0SNAPSHOT [Latest update: #0]
LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1
LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
And finally after some more tries, the vm crashed (crash.dmp attached).
If this only happens on windows, what else would be an option to start with contributing for pharo 7 ?
maybe I am doing something wrong ? I thought this should work now with the latest vm (and libgit)? It is still crashing for me.
[31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository UndefinedObject>>DoIt
VM windows 32 bit: CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < pavel.krivanek@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < juraj.kubelka@icloud.com> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich < serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/articl es/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
2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system
on both, it crashes on working with libgit/iceberg
Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ?
Now, I tried again with the latest vm/image version and I get this error LGit_GIT_ERROR: username does not match previous request' Any idea ?
2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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
Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error :
Image: Pharo7.0SNAPSHOT [Latest update: #0]
LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1
LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil
And finally after some more tries, the vm crashed (crash.dmp attached).
If this only happens on windows, what else would be an option to start with contributing for pharo 7 ?
maybe I am doing something wrong ? I thought this should work now with the latest vm (and libgit)? It is still crashing for me.
[31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository UndefinedObject>>DoIt
VM windows 32 bit: CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < pavel.krivanek@gmail.com>:
2017-06-28 17:06 GMT+02:00 Clément Bera <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@openinworld.com> wrote:
On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < juraj.kubelka@icloud.com> wrote:
El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribió:
On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2017-06-27 16:17 GMT+02:00 Serge Stinckwich < serge.stinckwich@gmail.com>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
serge.stinckwich@gmail.com>:
On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek <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/articl es/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
2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system
on both, it crashes on working with libgit/iceberg
Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ?
Now, I tried again with the latest vm/image version and I get this error
LGit_GIT_ERROR: username does not match previous request'
Any idea ?
I used my git username in the ssh settings. If I use "git" as username for the ssh setting, it complains about failed to authenticate SSH session How do other windows users use all this for pharo 7, any windows user how can write a little howto ?
2017-07-28 23:19 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system
on both, it crashes on working with libgit/iceberg
Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ?
Now, I tried again with the latest vm/image version and I get this error
LGit_GIT_ERROR: username does not match previous request'
Any idea ?
I used my git username in the ssh settings. If I use "git" as username for the ssh setting, it complains about failed to authenticate SSH session
How do other windows users use all this for pharo 7, any windows user how can write a little howto ?
Any news on howto use iceberg / libgit on windows. Does no one else use windows ?
On 8 Aug 2017, at 20:40, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-07-28 23:19 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system
on both, it crashes on working with libgit/iceberg
Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ?
Now, I tried again with the latest vm/image version and I get this error
LGit_GIT_ERROR: username does not match previous request'
Any idea ?
I used my git username in the ssh settings. If I use "git" as username for the ssh setting, it complains about failed to authenticate SSH session
How do other windows users use all this for pharo 7, any windows user how can write a little howto ?
Any news on howto use iceberg / libgit on windows. Does no one else use windows ?
I do not understand what's the problem. It was working on my tests... and I know several people is using windows (Torsten one of them). What's the problem you are having in concrete? I need to see how to reproduce it :( Esteban
2017-08-08 23:00 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 8 Aug 2017, at 20:40, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-07-28 23:19 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
What is the system you use? AFAIK Esteban is fixing the latest Iceberg because it stopped to work on Windows...
-- Pavel
windows 10 32 bit
and on another windows 10 64 bit system
on both, it crashes on working with libgit/iceberg
Any news ? Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
Or is there any other way to be up to date with fixes, doing reviews and bug fixes (without using github in the web browser) ?
Now, I tried again with the latest vm/image version and I get this error
LGit_GIT_ERROR: username does not match previous request'
Any idea ?
I used my git username in the ssh settings. If I use "git" as username for the ssh setting, it complains about failed to authenticate SSH session
How do other windows users use all this for pharo 7, any windows user how can write a little howto ?
Any news on howto use iceberg / libgit on windows. Does no one else use windows ?
I do not understand what's the problem. It was working on my tests... and I know several people is using windows (Torsten one of them). What's the problem you are having in concrete? I need to see how to reproduce it :(
Like I described above. I followed this howto ( the first mail from pavel). But I get this error: 'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned error' Now I enabled the setting for "Use custom SSH keys", followed the github-doc for adding a ssh-key on windows and add this key to my github-account. But I still get the same error.
Esteban
Le 08/08/2017 à 23:37, Nicolai Hess a écrit :
Like I described above.
I followed this howto ( the first mail from pavel).
But I get this error:
'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned error'
Now I enabled the setting for "Use custom SSH keys", followed the github-doc for adding a ssh-key on windows and add this key to my github-account. But I still get the same error.
To be sure this is not a ssh key problem you can try to install git bash and to commit on a repository with a ssh remote. If it works you'll be sure the ssh key is good. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2017-08-08 23:41 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
Le 08/08/2017 à 23:37, Nicolai Hess a écrit :
Like I described above.
I followed this howto ( the first mail from pavel).
But I get this error:
'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned error'
Now I enabled the setting for "Use custom SSH keys", followed the github-doc for adding a ssh-key on windows and add this key to my github-account. But I still get the same error.
To be sure this is not a ssh key problem you can try to install git bash and to commit on a repository with a ssh remote. If it works you'll be sure the ssh key is good.
yes, just tested, this seems to work. I can use the key for a ssh remote commit from the command line. but somehow I can not use it with pharo /iceberg..
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2017-08-09 23:18 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-08-08 23:41 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
Le 08/08/2017 à 23:37, Nicolai Hess a écrit :
Like I described above.
I followed this howto ( the first mail from pavel).
But I get this error:
'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned error'
Now I enabled the setting for "Use custom SSH keys", followed the github-doc for adding a ssh-key on windows and add this key to my github-account. But I still get the same error.
To be sure this is not a ssh key problem you can try to install git bash and to commit on a repository with a ssh remote. If it works you'll be sure the ssh key is good.
yes, just tested, this seems to work. I can use the key for a ssh remote commit from the command line. but somehow I can not use it with pharo /iceberg..
Ah, I think I got it to work now. I created a new ssh key, but this time I did not set a passphrase. So maybe, ssh remotes with iceberg are only working if you don't use passphrases for you secret key!
--
Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Le 08/08/2017 à 20:40, Nicolai Hess a écrit :
Any news on howto use iceberg / libgit on windows. Does no one else use windows ?
Hi, I can use Iceberg on Windows 7 but not to participate to Pharo (or any project with file name longer than 255chars). So I can work on my projects or on projects like Iceberg. I have a ssh key on my Windows that is associated to my github account and I have a startup script executing this: IceCredentialsProvider useCustomSsh: true. Since my ssh key has the default name for a rsa key it select it by default and I can use Iceberg. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2017-08-08 23:05 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
Le 08/08/2017 à 20:40, Nicolai Hess a écrit :
Any news on howto use iceberg / libgit on windows. Does no one else use windows ?
Hi,
I can use Iceberg on Windows 7 but not to participate to Pharo (or any project with file name longer than 255chars).
So I can work on my projects or on projects like Iceberg. I have a ssh key on my Windows that is associated to my github account and I have a startup script executing this:
IceCredentialsProvider useCustomSsh: true.
Since my ssh key has the default name for a rsa key it select it by default and I can use Iceberg.
Thanks for the info, cyril. What do you use for the ssh username in pharo setting and what username did you use for creating the ssh-key ? I tried both, my github-email and my github-username, I didn't get it to work.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Le 08/08/2017 à 23:40, Nicolai Hess a écrit :
Thanks for the info, cyril.
What do you use for the ssh username in pharo setting and what username did you use for creating the ssh-key ? I tried both, my github-email and my github-username, I didn't get it to work.
I did not use anything special. While creating the ssh key I used all the default options and in the setting I do not change the username (see joined screenshot). This is the command I probably used since I followed github tutorial[1]: ssh-keygen -t rsa -b 4096 -C "cyril.ferlicot@gmail.com" [1] https://help.github.com/articles/connecting-to-github-with-ssh/ -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On 8 Aug 2017, at 23:47, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 08/08/2017 à 23:40, Nicolai Hess a écrit :
Thanks for the info, cyril.
What do you use for the ssh username in pharo setting and what username did you use for creating the ssh-key ? I tried both, my github-email and my github-username, I didn't get it to work.
I did not use anything special. While creating the ssh key I used all the default options and in the setting I do not change the username (see joined screenshot).
This is the command I probably used since I followed github tutorial[1]:
ssh-keygen -t rsa -b 4096 -C "cyril.ferlicot@gmail.com"
[1] https://help.github.com/articles/connecting-to-github-with-ssh/ <https://help.github.com/articles/connecting-to-github-with-ssh/>
yes, the keys may be an issue, but the standard rsa generated key should work. We need to do a pass in security/credentials system (and probably a revamp of some parts), but I still didnât find the time. about the 255 limitation, if you execute this in command line: git config --system core.longpaths true it should also fix the problem with pharo repo. Esteban
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France <PharoScreenshot.png>
On Wed, Aug 9, 2017 at 9:33 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
yes, the keys may be an issue, but the standard rsa generated key should work. We need to do a pass in security/credentials system (and probably a revamp of some parts), but I still didnât find the time. about the 255 limitation, if you execute this in command line:
git config --system core.longpaths true
I already did it but I still get the problem :(
it should also fix the problem with pharo repo.
Esteban
-- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2017-08-09 9:33 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 8 Aug 2017, at 23:47, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 08/08/2017 à 23:40, Nicolai Hess a écrit :
Thanks for the info, cyril.
What do you use for the ssh username in pharo setting and what username did you use for creating the ssh-key ? I tried both, my github-email and my github-username, I didn't get it to work.
I did not use anything special. While creating the ssh key I used all the default options and in the setting I do not change the username (see joined screenshot).
This is the command I probably used since I followed github tutorial[1]:
ssh-keygen -t rsa -b 4096 -C "cyril.ferlicot@gmail.com"
[1] https://help.github.com/articles/connecting-to-github-with-ssh/
yes, the keys may be an issue, but the standard rsa generated key should work. We need to do a pass in security/credentials system (and probably a revamp of some parts), but I still didnât find the time. about the 255 limitation, if you execute this in command line:
git config --system core.longpaths true
it should also fix the problem with pharo repo.
Esteban
Now I have the same problem. I can not get the pharo repo because it can not operate on files with long path names. even with longpaths true, this does not work ...
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France <PharoScreenshot.png>
participants (8)
-
Cyril Ferlicot -
Cyril Ferlicot D.
-
Esteban Lorenzano -
Nicolai Hess -
Pavel Krivanek -
Stephane Ducasse -
tesonep＠gmail.com -
Yuriy Tymchuk