Pharo 7 provisional HOWTO

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Pavel Krivanek-3
Unfortunately you cannot share the repository the way you try because it always needs to be in the image working directory in a folder named 'pharo-core'. Without it the Monticello will not be able to see changes int the packages. 

On one location place Pharo 7 image and execute the first script that clones the repository and sets the remote fork.
Then into some other repository take a fresh Pharo 7 image, create symlink to the 'pharo-core' folder in the original directory and then execute the second script that only registers this repository into Iceberg and sets proper pull and push targets on it.

Cheers,
-- Pavel

2017-06-30 10:04 GMT+02:00 Stephane Ducasse <[hidden email]>:
So I do not understand

Now if I do

repository := IceRepositoryCreator new
location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core'
asFileReference);
subdirectory:'src';
createRepository.
repository register.


it works but doing it twice breaks. How can I get access to the repo?
Because
fork := repository remotes detect: [ :remote | remote remoteName = #pharo ].

Does not work :(
And my github fork is name pharo I tried with 'pharo' but it failed too.


"origin ([hidden email]:Ducasse/pharo.git)"


"upstream ([hidden email]:pharo-project/pharo.git)"

;(




On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse
<[hidden email]> wrote:
> No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip
>
> On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek
> <[hidden email]> wrote:
>> The script in section "Use already created clone" is supposed to be used by
>> a fresh Pharo 7 image. Maybe you are trying it on an image that already has
>> the repository set? Even if I tried to use the name 'pharo' instead of
>> 'myFork', the scripts work.
>>
>> Cheers,
>> -- Pavel
>>
>>
>> <a href="tel:2017-06-30%209" value="+420201706309">2017-06-30 9:34 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>>
>>> Hi pavel
>>>
>>> Since I want to reuse my clone. I tried the following. But I have no
>>> idea about the name of my fork so I put the one of my fork = pharo and
>>> it seems that this is what should be done.
>>>
>>> Now when I execute this script I get
>>>
>>> 'You already have an Iceberg repository
>>>
>>> So hat should I do?
>>>
>>>
>>>
>>> Use already created clone
>>> =====================
>>>
>>>
>>> repository := IceRepositoryCreator new
>>> location: ('pharo-core' asFileReference);
>>> subdirectory:'src';
>>> createRepository.
>>> repository register.
>>>
>>> fork := repository remotes detect: [ :remote | remote remoteName = #pharo
>>> ].
>>> repository pushRemote: fork.
>>> repository pullRemote: repository origin.
>>>
>>> repository checkoutBranch: 'development'.
>>> repository backend pullFrom: repository origin.
>>> repository push.
>>>
>>> repository checkoutBranch: (SystemVersion current commitHash).
>>>
>>> On Mon, Jun 26, 2017 at 1:14 PM, Pavel Krivanek
>>> <[hidden email]> wrote:
>>> > Hi,
>>> >
>>> > this mail describes how to start to send pull requests to Pharo 7 Github
>>> > repository from Pharo 7.
>>> >
>>> > 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
>>> >
>>> > Get Pharo 7 image
>>> > =====================
>>> >
>>> > The CI jobs for the Pharo 7 defelopment are currently not fully set and
>>> > we
>>> > still do not publish Pharo 7 image to files.pharo.org so you cannot get
>>> > it
>>> > using zero-conf scripts. But we have a provisional CI job that
>>> > bootstraps
>>> > the Pharo 7 image.
>>> >
>>> > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/
>>> >
>>> > There download a file named like Pharo7.0-32bit-hash.zip and decompress
>>> > it.
>>> > Unlike Pharo 6 images, the archive contains three files. Image, changes
>>> > and
>>> > sources. In Pharo 7 you have the sources file for every bootstrapped
>>> > version. It has a commit hash in the name and it cannot be shared
>>> > between
>>> > different Pharo 7 imges, however it can be shared between images that
>>> > were
>>> > created as snapshots with the same bootstrapped image as ancestor.
>>> >
>>> > Create local clone
>>> > =====================
>>> >
>>> > You need a local clone of the Pharo repository. Because it contains a
>>> > lot of
>>> > small files, it is not a good idea to have own clone for every image.
>>> > You
>>> > can have only one and share them between images. But because of some
>>> > current
>>> > Monticello constraints you need to have the clone placed in the image
>>> > directory in a folder with name 'pharo-core'.
>>> >
>>> > In this step we will clone the Pharo repository from pharo-project/pharo
>>> > Github repository and add your fork as default pull target. We will
>>> > update
>>> > your fork repository to contain all latest commits from the Pharo
>>> > repository
>>> > in the branch named 'development'. For latest stable version (Pharo 6)
>>> > we
>>> > use the master branch.
>>> > In the end we will checkout the repository to a particular commit from
>>> > which
>>> > the downloaded Pharo 7 image was bootstrapped. Imagine that you have a
>>> > Pharo
>>> > 7 image that is several days old and the development branch has already
>>> > some
>>> > commits that change code. If you would take this older image, checkout
>>> > to
>>> > the development branch and then do your commit, your would revert all
>>> > changes done in not-loaded commits. The other option is to update your
>>> > image
>>> > to correspond to the repository latest commit which requires packages
>>> > reloading.
>>> > If you checkout to a particular commit, you are in detached HEAD state.
>>> > In
>>> > this state you cannot do commits directly. You need to firstly create
>>> > new a
>>> > new branch which we will do anyway.
>>> >
>>> > Evaluate the following code. This functionality will be later direct
>>> > part of
>>> > Iceberg UI. Do not forget to change the user name.
>>> >
>>> > username := 'YOUR-USER-NAME'.
>>> > repository := IceRepositoryCreator new
>>> > url: '[hidden email]:pharo-project/pharo.git';
>>> > location: ('pharo-core' asFileReference ensureCreateDirectory);
>>> > subdirectory:'src';
>>> > createRepository.
>>> > repository checkoutBranch: 'development'.
>>> > repository register.
>>> >
>>> > fork := (IceRemote name: 'myFork' url: ('[hidden email]:{1}/pharo.git'
>>> > format: {username})).
>>> > repository addRemote: fork.
>>> > repository pushRemote: fork.
>>> > repository pullRemote: repository origin.
>>> >
>>> > "update fork"
>>> > repository backend pullFrom: repository origin. "use this low-level form
>>> > to
>>> > prevent packages reloading"
>>> > repository push.
>>> >
>>> > "checkout to the commit from which the image was bootstrapped"
>>> > repository checkoutBranch: (SystemVersion current commitHash).
>>> >
>>> > Use already created clone
>>> > =====================
>>> >
>>> > This is alternative to the previous step. Let's suppose that you already
>>> > have your local clone. You take some Pharo 7 image and you want to
>>> > create
>>> > commits. Then you need to create a symlink or move/copy the repository
>>> > into
>>> > your image directory. Remember, it must be named pharo-core (we do not
>>> > use
>>> > the name 'pharo' to avoid collision with VM executable).
>>> >
>>> > In this step we will register an existing Pharo repository clone, set
>>> > your
>>> > fork as the push target, update your fork and then switch to the
>>> > particular
>>> > commit.
>>> >
>>> > repository := IceRepositoryCreator new
>>> > location: ('pharo-core' asFileReference);
>>> > subdirectory:'src';
>>> > createRepository.
>>> > repository register.
>>> >
>>> > fork := repository remotes detect: [ :remote | remote remoteName =
>>> > #myFork
>>> > ].
>>> > repository pushRemote: fork.
>>> > repository pullRemote: repository origin.
>>> >
>>> > repository checkoutBranch: 'development'.
>>> > repository backend pullFrom: repository origin.
>>> > repository push.
>>> >
>>> > repository checkoutBranch: (SystemVersion current commitHash).
>>> >
>>> > 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
>>> >
>>> > Cheers,
>>> > -- Pavel
>>> >
>>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Stephane Ducasse-3
Ok I try to understand.
I already cloned the github repo and I do not want to be forced to
download all these small files all the time.
I want one place with all the forked code one and only one.

I will try to create a simlink and try again.
Tx

Stef

On Fri, Jun 30, 2017 at 10:26 AM, Pavel Krivanek
<[hidden email]> wrote:

> Unfortunately you cannot share the repository the way you try because it
> always needs to be in the image working directory in a folder named
> 'pharo-core'. Without it the Monticello will not be able to see changes int
> the packages.
>
> On one location place Pharo 7 image and execute the first script that clones
> the repository and sets the remote fork.
> Then into some other repository take a fresh Pharo 7 image, create symlink
> to the 'pharo-core' folder in the original directory and then execute the
> second script that only registers this repository into Iceberg and sets
> proper pull and push targets on it.
>
> Cheers,
> -- Pavel
>
> 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>
>> So I do not understand
>>
>> Now if I do
>>
>> repository := IceRepositoryCreator new
>> location:
>> ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core'
>> asFileReference);
>> subdirectory:'src';
>> createRepository.
>> repository register.
>>
>>
>> it works but doing it twice breaks. How can I get access to the repo?
>> Because
>> fork := repository remotes detect: [ :remote | remote remoteName = #pharo
>> ].
>>
>> Does not work :(
>> And my github fork is name pharo I tried with 'pharo' but it failed too.
>>
>>
>> "origin ([hidden email]:Ducasse/pharo.git)"
>>
>>
>> "upstream ([hidden email]:pharo-project/pharo.git)"
>>
>> ;(
>>
>>
>>
>>
>> On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse
>> <[hidden email]> wrote:
>> > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip
>> >
>> > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek
>> > <[hidden email]> wrote:
>> >> The script in section "Use already created clone" is supposed to be
>> >> used by
>> >> a fresh Pharo 7 image. Maybe you are trying it on an image that already
>> >> has
>> >> the repository set? Even if I tried to use the name 'pharo' instead of
>> >> 'myFork', the scripts work.
>> >>
>> >> Cheers,
>> >> -- Pavel
>> >>
>> >>
>> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <[hidden email]>:
>> >>>
>> >>> Hi pavel
>> >>>
>> >>> Since I want to reuse my clone. I tried the following. But I have no
>> >>> idea about the name of my fork so I put the one of my fork = pharo and
>> >>> it seems that this is what should be done.
>> >>>
>> >>> Now when I execute this script I get
>> >>>
>> >>> 'You already have an Iceberg repository
>> >>>
>> >>> So hat should I do?
>> >>>
>> >>>
>> >>>
>> >>> Use already created clone
>> >>> =====================
>> >>>
>> >>>
>> >>> repository := IceRepositoryCreator new
>> >>> location: ('pharo-core' asFileReference);
>> >>> subdirectory:'src';
>> >>> createRepository.
>> >>> repository register.
>> >>>
>> >>> fork := repository remotes detect: [ :remote | remote remoteName =
>> >>> #pharo
>> >>> ].
>> >>> repository pushRemote: fork.
>> >>> repository pullRemote: repository origin.
>> >>>
>> >>> repository checkoutBranch: 'development'.
>> >>> repository backend pullFrom: repository origin.
>> >>> repository push.
>> >>>
>> >>> repository checkoutBranch: (SystemVersion current commitHash).
>> >>>
>> >>> On Mon, Jun 26, 2017 at 1:14 PM, Pavel Krivanek
>> >>> <[hidden email]> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > this mail describes how to start to send pull requests to Pharo 7
>> >>> > Github
>> >>> > repository from Pharo 7.
>> >>> >
>> >>> > 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
>> >>> >
>> >>> > Get Pharo 7 image
>> >>> > =====================
>> >>> >
>> >>> > The CI jobs for the Pharo 7 defelopment are currently not fully set
>> >>> > and
>> >>> > we
>> >>> > still do not publish Pharo 7 image to files.pharo.org so you cannot
>> >>> > get
>> >>> > it
>> >>> > using zero-conf scripts. But we have a provisional CI job that
>> >>> > bootstraps
>> >>> > the Pharo 7 image.
>> >>> >
>> >>> > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/
>> >>> >
>> >>> > There download a file named like Pharo7.0-32bit-hash.zip and
>> >>> > decompress
>> >>> > it.
>> >>> > Unlike Pharo 6 images, the archive contains three files. Image,
>> >>> > changes
>> >>> > and
>> >>> > sources. In Pharo 7 you have the sources file for every bootstrapped
>> >>> > version. It has a commit hash in the name and it cannot be shared
>> >>> > between
>> >>> > different Pharo 7 imges, however it can be shared between images
>> >>> > that
>> >>> > were
>> >>> > created as snapshots with the same bootstrapped image as ancestor.
>> >>> >
>> >>> > Create local clone
>> >>> > =====================
>> >>> >
>> >>> > You need a local clone of the Pharo repository. Because it contains
>> >>> > a
>> >>> > lot of
>> >>> > small files, it is not a good idea to have own clone for every
>> >>> > image.
>> >>> > You
>> >>> > can have only one and share them between images. But because of some
>> >>> > current
>> >>> > Monticello constraints you need to have the clone placed in the
>> >>> > image
>> >>> > directory in a folder with name 'pharo-core'.
>> >>> >
>> >>> > In this step we will clone the Pharo repository from
>> >>> > pharo-project/pharo
>> >>> > Github repository and add your fork as default pull target. We will
>> >>> > update
>> >>> > your fork repository to contain all latest commits from the Pharo
>> >>> > repository
>> >>> > in the branch named 'development'. For latest stable version (Pharo
>> >>> > 6)
>> >>> > we
>> >>> > use the master branch.
>> >>> > In the end we will checkout the repository to a particular commit
>> >>> > from
>> >>> > which
>> >>> > the downloaded Pharo 7 image was bootstrapped. Imagine that you have
>> >>> > a
>> >>> > Pharo
>> >>> > 7 image that is several days old and the development branch has
>> >>> > already
>> >>> > some
>> >>> > commits that change code. If you would take this older image,
>> >>> > checkout
>> >>> > to
>> >>> > the development branch and then do your commit, your would revert
>> >>> > all
>> >>> > changes done in not-loaded commits. The other option is to update
>> >>> > your
>> >>> > image
>> >>> > to correspond to the repository latest commit which requires
>> >>> > packages
>> >>> > reloading.
>> >>> > If you checkout to a particular commit, you are in detached HEAD
>> >>> > state.
>> >>> > In
>> >>> > this state you cannot do commits directly. You need to firstly
>> >>> > create
>> >>> > new a
>> >>> > new branch which we will do anyway.
>> >>> >
>> >>> > Evaluate the following code. This functionality will be later direct
>> >>> > part of
>> >>> > Iceberg UI. Do not forget to change the user name.
>> >>> >
>> >>> > username := 'YOUR-USER-NAME'.
>> >>> > repository := IceRepositoryCreator new
>> >>> > url: '[hidden email]:pharo-project/pharo.git';
>> >>> > location: ('pharo-core' asFileReference ensureCreateDirectory);
>> >>> > subdirectory:'src';
>> >>> > createRepository.
>> >>> > repository checkoutBranch: 'development'.
>> >>> > repository register.
>> >>> >
>> >>> > fork := (IceRemote name: 'myFork' url:
>> >>> > ('[hidden email]:{1}/pharo.git'
>> >>> > format: {username})).
>> >>> > repository addRemote: fork.
>> >>> > repository pushRemote: fork.
>> >>> > repository pullRemote: repository origin.
>> >>> >
>> >>> > "update fork"
>> >>> > repository backend pullFrom: repository origin. "use this low-level
>> >>> > form
>> >>> > to
>> >>> > prevent packages reloading"
>> >>> > repository push.
>> >>> >
>> >>> > "checkout to the commit from which the image was bootstrapped"
>> >>> > repository checkoutBranch: (SystemVersion current commitHash).
>> >>> >
>> >>> > Use already created clone
>> >>> > =====================
>> >>> >
>> >>> > This is alternative to the previous step. Let's suppose that you
>> >>> > already
>> >>> > have your local clone. You take some Pharo 7 image and you want to
>> >>> > create
>> >>> > commits. Then you need to create a symlink or move/copy the
>> >>> > repository
>> >>> > into
>> >>> > your image directory. Remember, it must be named pharo-core (we do
>> >>> > not
>> >>> > use
>> >>> > the name 'pharo' to avoid collision with VM executable).
>> >>> >
>> >>> > In this step we will register an existing Pharo repository clone,
>> >>> > set
>> >>> > your
>> >>> > fork as the push target, update your fork and then switch to the
>> >>> > particular
>> >>> > commit.
>> >>> >
>> >>> > repository := IceRepositoryCreator new
>> >>> > location: ('pharo-core' asFileReference);
>> >>> > subdirectory:'src';
>> >>> > createRepository.
>> >>> > repository register.
>> >>> >
>> >>> > fork := repository remotes detect: [ :remote | remote remoteName =
>> >>> > #myFork
>> >>> > ].
>> >>> > repository pushRemote: fork.
>> >>> > repository pullRemote: repository origin.
>> >>> >
>> >>> > repository checkoutBranch: 'development'.
>> >>> > repository backend pullFrom: repository origin.
>> >>> > repository push.
>> >>> >
>> >>> > repository checkoutBranch: (SystemVersion current commitHash).
>> >>> >
>> >>> > 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
>> >>> >
>> >>> > Cheers,
>> >>> > -- Pavel
>> >>> >
>> >>>
>> >>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Stephane Ducasse-3
I do not get why

repository := IceRepositoryCreator new
location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core'
asFileReference);

is not working and

repository := IceRepositoryCreator new
location: ('pharo-core' asFileReference);

+ simlink would be working.



On Fri, Jun 30, 2017 at 10:46 AM, Stephane Ducasse
<[hidden email]> wrote:

> Ok I try to understand.
> I already cloned the github repo and I do not want to be forced to
> download all these small files all the time.
> I want one place with all the forked code one and only one.
>
> I will try to create a simlink and try again.
> Tx
>
> Stef
>
> On Fri, Jun 30, 2017 at 10:26 AM, Pavel Krivanek
> <[hidden email]> wrote:
>> Unfortunately you cannot share the repository the way you try because it
>> always needs to be in the image working directory in a folder named
>> 'pharo-core'. Without it the Monticello will not be able to see changes int
>> the packages.
>>
>> On one location place Pharo 7 image and execute the first script that clones
>> the repository and sets the remote fork.
>> Then into some other repository take a fresh Pharo 7 image, create symlink
>> to the 'pharo-core' folder in the original directory and then execute the
>> second script that only registers this repository into Iceberg and sets
>> proper pull and push targets on it.
>>
>> Cheers,
>> -- Pavel
>>
>> 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>>
>>> So I do not understand
>>>
>>> Now if I do
>>>
>>> repository := IceRepositoryCreator new
>>> location:
>>> ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core'
>>> asFileReference);
>>> subdirectory:'src';
>>> createRepository.
>>> repository register.
>>>
>>>
>>> it works but doing it twice breaks. How can I get access to the repo?
>>> Because
>>> fork := repository remotes detect: [ :remote | remote remoteName = #pharo
>>> ].
>>>
>>> Does not work :(
>>> And my github fork is name pharo I tried with 'pharo' but it failed too.
>>>
>>>
>>> "origin ([hidden email]:Ducasse/pharo.git)"
>>>
>>>
>>> "upstream ([hidden email]:pharo-project/pharo.git)"
>>>
>>> ;(
>>>
>>>
>>>
>>>
>>> On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse
>>> <[hidden email]> wrote:
>>> > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip
>>> >
>>> > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek
>>> > <[hidden email]> wrote:
>>> >> The script in section "Use already created clone" is supposed to be
>>> >> used by
>>> >> a fresh Pharo 7 image. Maybe you are trying it on an image that already
>>> >> has
>>> >> the repository set? Even if I tried to use the name 'pharo' instead of
>>> >> 'myFork', the scripts work.
>>> >>
>>> >> Cheers,
>>> >> -- Pavel
>>> >>
>>> >>
>>> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>> >>>
>>> >>> Hi pavel
>>> >>>
>>> >>> Since I want to reuse my clone. I tried the following. But I have no
>>> >>> idea about the name of my fork so I put the one of my fork = pharo and
>>> >>> it seems that this is what should be done.
>>> >>>
>>> >>> Now when I execute this script I get
>>> >>>
>>> >>> 'You already have an Iceberg repository
>>> >>>
>>> >>> So hat should I do?
>>> >>>
>>> >>>
>>> >>>
>>> >>> Use already created clone
>>> >>> =====================
>>> >>>
>>> >>>
>>> >>> repository := IceRepositoryCreator new
>>> >>> location: ('pharo-core' asFileReference);
>>> >>> subdirectory:'src';
>>> >>> createRepository.
>>> >>> repository register.
>>> >>>
>>> >>> fork := repository remotes detect: [ :remote | remote remoteName =
>>> >>> #pharo
>>> >>> ].
>>> >>> repository pushRemote: fork.
>>> >>> repository pullRemote: repository origin.
>>> >>>
>>> >>> repository checkoutBranch: 'development'.
>>> >>> repository backend pullFrom: repository origin.
>>> >>> repository push.
>>> >>>
>>> >>> repository checkoutBranch: (SystemVersion current commitHash).
>>> >>>
>>> >>> On Mon, Jun 26, 2017 at 1:14 PM, Pavel Krivanek
>>> >>> <[hidden email]> wrote:
>>> >>> > Hi,
>>> >>> >
>>> >>> > this mail describes how to start to send pull requests to Pharo 7
>>> >>> > Github
>>> >>> > repository from Pharo 7.
>>> >>> >
>>> >>> > 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
>>> >>> >
>>> >>> > Get Pharo 7 image
>>> >>> > =====================
>>> >>> >
>>> >>> > The CI jobs for the Pharo 7 defelopment are currently not fully set
>>> >>> > and
>>> >>> > we
>>> >>> > still do not publish Pharo 7 image to files.pharo.org so you cannot
>>> >>> > get
>>> >>> > it
>>> >>> > using zero-conf scripts. But we have a provisional CI job that
>>> >>> > bootstraps
>>> >>> > the Pharo 7 image.
>>> >>> >
>>> >>> > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/
>>> >>> >
>>> >>> > There download a file named like Pharo7.0-32bit-hash.zip and
>>> >>> > decompress
>>> >>> > it.
>>> >>> > Unlike Pharo 6 images, the archive contains three files. Image,
>>> >>> > changes
>>> >>> > and
>>> >>> > sources. In Pharo 7 you have the sources file for every bootstrapped
>>> >>> > version. It has a commit hash in the name and it cannot be shared
>>> >>> > between
>>> >>> > different Pharo 7 imges, however it can be shared between images
>>> >>> > that
>>> >>> > were
>>> >>> > created as snapshots with the same bootstrapped image as ancestor.
>>> >>> >
>>> >>> > Create local clone
>>> >>> > =====================
>>> >>> >
>>> >>> > You need a local clone of the Pharo repository. Because it contains
>>> >>> > a
>>> >>> > lot of
>>> >>> > small files, it is not a good idea to have own clone for every
>>> >>> > image.
>>> >>> > You
>>> >>> > can have only one and share them between images. But because of some
>>> >>> > current
>>> >>> > Monticello constraints you need to have the clone placed in the
>>> >>> > image
>>> >>> > directory in a folder with name 'pharo-core'.
>>> >>> >
>>> >>> > In this step we will clone the Pharo repository from
>>> >>> > pharo-project/pharo
>>> >>> > Github repository and add your fork as default pull target. We will
>>> >>> > update
>>> >>> > your fork repository to contain all latest commits from the Pharo
>>> >>> > repository
>>> >>> > in the branch named 'development'. For latest stable version (Pharo
>>> >>> > 6)
>>> >>> > we
>>> >>> > use the master branch.
>>> >>> > In the end we will checkout the repository to a particular commit
>>> >>> > from
>>> >>> > which
>>> >>> > the downloaded Pharo 7 image was bootstrapped. Imagine that you have
>>> >>> > a
>>> >>> > Pharo
>>> >>> > 7 image that is several days old and the development branch has
>>> >>> > already
>>> >>> > some
>>> >>> > commits that change code. If you would take this older image,
>>> >>> > checkout
>>> >>> > to
>>> >>> > the development branch and then do your commit, your would revert
>>> >>> > all
>>> >>> > changes done in not-loaded commits. The other option is to update
>>> >>> > your
>>> >>> > image
>>> >>> > to correspond to the repository latest commit which requires
>>> >>> > packages
>>> >>> > reloading.
>>> >>> > If you checkout to a particular commit, you are in detached HEAD
>>> >>> > state.
>>> >>> > In
>>> >>> > this state you cannot do commits directly. You need to firstly
>>> >>> > create
>>> >>> > new a
>>> >>> > new branch which we will do anyway.
>>> >>> >
>>> >>> > Evaluate the following code. This functionality will be later direct
>>> >>> > part of
>>> >>> > Iceberg UI. Do not forget to change the user name.
>>> >>> >
>>> >>> > username := 'YOUR-USER-NAME'.
>>> >>> > repository := IceRepositoryCreator new
>>> >>> > url: '[hidden email]:pharo-project/pharo.git';
>>> >>> > location: ('pharo-core' asFileReference ensureCreateDirectory);
>>> >>> > subdirectory:'src';
>>> >>> > createRepository.
>>> >>> > repository checkoutBranch: 'development'.
>>> >>> > repository register.
>>> >>> >
>>> >>> > fork := (IceRemote name: 'myFork' url:
>>> >>> > ('[hidden email]:{1}/pharo.git'
>>> >>> > format: {username})).
>>> >>> > repository addRemote: fork.
>>> >>> > repository pushRemote: fork.
>>> >>> > repository pullRemote: repository origin.
>>> >>> >
>>> >>> > "update fork"
>>> >>> > repository backend pullFrom: repository origin. "use this low-level
>>> >>> > form
>>> >>> > to
>>> >>> > prevent packages reloading"
>>> >>> > repository push.
>>> >>> >
>>> >>> > "checkout to the commit from which the image was bootstrapped"
>>> >>> > repository checkoutBranch: (SystemVersion current commitHash).
>>> >>> >
>>> >>> > Use already created clone
>>> >>> > =====================
>>> >>> >
>>> >>> > This is alternative to the previous step. Let's suppose that you
>>> >>> > already
>>> >>> > have your local clone. You take some Pharo 7 image and you want to
>>> >>> > create
>>> >>> > commits. Then you need to create a symlink or move/copy the
>>> >>> > repository
>>> >>> > into
>>> >>> > your image directory. Remember, it must be named pharo-core (we do
>>> >>> > not
>>> >>> > use
>>> >>> > the name 'pharo' to avoid collision with VM executable).
>>> >>> >
>>> >>> > In this step we will register an existing Pharo repository clone,
>>> >>> > set
>>> >>> > your
>>> >>> > fork as the push target, update your fork and then switch to the
>>> >>> > particular
>>> >>> > commit.
>>> >>> >
>>> >>> > repository := IceRepositoryCreator new
>>> >>> > location: ('pharo-core' asFileReference);
>>> >>> > subdirectory:'src';
>>> >>> > createRepository.
>>> >>> > repository register.
>>> >>> >
>>> >>> > fork := repository remotes detect: [ :remote | remote remoteName =
>>> >>> > #myFork
>>> >>> > ].
>>> >>> > repository pushRemote: fork.
>>> >>> > repository pullRemote: repository origin.
>>> >>> >
>>> >>> > repository checkoutBranch: 'development'.
>>> >>> > repository backend pullFrom: repository origin.
>>> >>> > repository push.
>>> >>> >
>>> >>> > repository checkoutBranch: (SystemVersion current commitHash).
>>> >>> >
>>> >>> > 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
>>> >>> >
>>> >>> > Cheers,
>>> >>> > -- Pavel
>>> >>> >
>>> >>>
>>> >>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Stephane Ducasse-3
I did a simlink

total 124088
-rw-rw-r--  1 ducasse  admin       381 Jun 30 10:18
Pharo7.0-32bit-70f3b57.changes
-rw-rw-r--  1 ducasse  admin  29740016 Jun 29 13:38 Pharo7.0-32bit-70f3b57.image
-rw-rw-r--  1 ducasse  admin  33711804 Jun 29 13:37
Pharo7.0-32bit-70f3b57.sources
-rw-r--r--@ 1 ducasse  admin     65620 Jun 30 10:05 PharoDebug.log
lrwxr-xr-x  1 ducasse  admin        33 Jun 30 10:45 pharo-core@ ->
../../../PharoCodeBase/pharo-core
drwxr-xr-x  4 ducasse  admin       136 Jun 30 09:59 pharo-local/

But now I get DNU url :(


repository := IceRepositoryCreator new
location: ('pharo-core' asFileReference);
subdirectory:'src';
createRepository.
repository register.

fork := repository remotes detect: [ :remote | remote remoteName = 'pharo' ].
repository pushRemote: fork.
repository pullRemote: repository origin.

repository checkoutBranch: 'development'.
repository backend pullFrom: repository origin.
repository push.

repository checkoutBranch: (SystemVersion current commitHash).


So I will wait that the system arrives to a state I can work with.

Stef



On Fri, Jun 30, 2017 at 10:48 AM, Stephane Ducasse
<[hidden email]> wrote:

> I do not get why
>
> repository := IceRepositoryCreator new
> location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core'
> asFileReference);
>
> is not working and
>
> repository := IceRepositoryCreator new
> location: ('pharo-core' asFileReference);
>
> + simlink would be working.
>
>
>
> On Fri, Jun 30, 2017 at 10:46 AM, Stephane Ducasse
> <[hidden email]> wrote:
>> Ok I try to understand.
>> I already cloned the github repo and I do not want to be forced to
>> download all these small files all the time.
>> I want one place with all the forked code one and only one.
>>
>> I will try to create a simlink and try again.
>> Tx
>>
>> Stef
>>
>> On Fri, Jun 30, 2017 at 10:26 AM, Pavel Krivanek
>> <[hidden email]> wrote:
>>> Unfortunately you cannot share the repository the way you try because it
>>> always needs to be in the image working directory in a folder named
>>> 'pharo-core'. Without it the Monticello will not be able to see changes int
>>> the packages.
>>>
>>> On one location place Pharo 7 image and execute the first script that clones
>>> the repository and sets the remote fork.
>>> Then into some other repository take a fresh Pharo 7 image, create symlink
>>> to the 'pharo-core' folder in the original directory and then execute the
>>> second script that only registers this repository into Iceberg and sets
>>> proper pull and push targets on it.
>>>
>>> Cheers,
>>> -- Pavel
>>>
>>> 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>>>
>>>> So I do not understand
>>>>
>>>> Now if I do
>>>>
>>>> repository := IceRepositoryCreator new
>>>> location:
>>>> ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core'
>>>> asFileReference);
>>>> subdirectory:'src';
>>>> createRepository.
>>>> repository register.
>>>>
>>>>
>>>> it works but doing it twice breaks. How can I get access to the repo?
>>>> Because
>>>> fork := repository remotes detect: [ :remote | remote remoteName = #pharo
>>>> ].
>>>>
>>>> Does not work :(
>>>> And my github fork is name pharo I tried with 'pharo' but it failed too.
>>>>
>>>>
>>>> "origin ([hidden email]:Ducasse/pharo.git)"
>>>>
>>>>
>>>> "upstream ([hidden email]:pharo-project/pharo.git)"
>>>>
>>>> ;(
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse
>>>> <[hidden email]> wrote:
>>>> > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip
>>>> >
>>>> > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek
>>>> > <[hidden email]> wrote:
>>>> >> The script in section "Use already created clone" is supposed to be
>>>> >> used by
>>>> >> a fresh Pharo 7 image. Maybe you are trying it on an image that already
>>>> >> has
>>>> >> the repository set? Even if I tried to use the name 'pharo' instead of
>>>> >> 'myFork', the scripts work.
>>>> >>
>>>> >> Cheers,
>>>> >> -- Pavel
>>>> >>
>>>> >>
>>>> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>>> >>>
>>>> >>> Hi pavel
>>>> >>>
>>>> >>> Since I want to reuse my clone. I tried the following. But I have no
>>>> >>> idea about the name of my fork so I put the one of my fork = pharo and
>>>> >>> it seems that this is what should be done.
>>>> >>>
>>>> >>> Now when I execute this script I get
>>>> >>>
>>>> >>> 'You already have an Iceberg repository
>>>> >>>
>>>> >>> So hat should I do?
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> Use already created clone
>>>> >>> =====================
>>>> >>>
>>>> >>>
>>>> >>> repository := IceRepositoryCreator new
>>>> >>> location: ('pharo-core' asFileReference);
>>>> >>> subdirectory:'src';
>>>> >>> createRepository.
>>>> >>> repository register.
>>>> >>>
>>>> >>> fork := repository remotes detect: [ :remote | remote remoteName =
>>>> >>> #pharo
>>>> >>> ].
>>>> >>> repository pushRemote: fork.
>>>> >>> repository pullRemote: repository origin.
>>>> >>>
>>>> >>> repository checkoutBranch: 'development'.
>>>> >>> repository backend pullFrom: repository origin.
>>>> >>> repository push.
>>>> >>>
>>>> >>> repository checkoutBranch: (SystemVersion current commitHash).
>>>> >>>
>>>> >>> On Mon, Jun 26, 2017 at 1:14 PM, Pavel Krivanek
>>>> >>> <[hidden email]> wrote:
>>>> >>> > Hi,
>>>> >>> >
>>>> >>> > this mail describes how to start to send pull requests to Pharo 7
>>>> >>> > Github
>>>> >>> > repository from Pharo 7.
>>>> >>> >
>>>> >>> > 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
>>>> >>> >
>>>> >>> > Get Pharo 7 image
>>>> >>> > =====================
>>>> >>> >
>>>> >>> > The CI jobs for the Pharo 7 defelopment are currently not fully set
>>>> >>> > and
>>>> >>> > we
>>>> >>> > still do not publish Pharo 7 image to files.pharo.org so you cannot
>>>> >>> > get
>>>> >>> > it
>>>> >>> > using zero-conf scripts. But we have a provisional CI job that
>>>> >>> > bootstraps
>>>> >>> > the Pharo 7 image.
>>>> >>> >
>>>> >>> > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/
>>>> >>> >
>>>> >>> > There download a file named like Pharo7.0-32bit-hash.zip and
>>>> >>> > decompress
>>>> >>> > it.
>>>> >>> > Unlike Pharo 6 images, the archive contains three files. Image,
>>>> >>> > changes
>>>> >>> > and
>>>> >>> > sources. In Pharo 7 you have the sources file for every bootstrapped
>>>> >>> > version. It has a commit hash in the name and it cannot be shared
>>>> >>> > between
>>>> >>> > different Pharo 7 imges, however it can be shared between images
>>>> >>> > that
>>>> >>> > were
>>>> >>> > created as snapshots with the same bootstrapped image as ancestor.
>>>> >>> >
>>>> >>> > Create local clone
>>>> >>> > =====================
>>>> >>> >
>>>> >>> > You need a local clone of the Pharo repository. Because it contains
>>>> >>> > a
>>>> >>> > lot of
>>>> >>> > small files, it is not a good idea to have own clone for every
>>>> >>> > image.
>>>> >>> > You
>>>> >>> > can have only one and share them between images. But because of some
>>>> >>> > current
>>>> >>> > Monticello constraints you need to have the clone placed in the
>>>> >>> > image
>>>> >>> > directory in a folder with name 'pharo-core'.
>>>> >>> >
>>>> >>> > In this step we will clone the Pharo repository from
>>>> >>> > pharo-project/pharo
>>>> >>> > Github repository and add your fork as default pull target. We will
>>>> >>> > update
>>>> >>> > your fork repository to contain all latest commits from the Pharo
>>>> >>> > repository
>>>> >>> > in the branch named 'development'. For latest stable version (Pharo
>>>> >>> > 6)
>>>> >>> > we
>>>> >>> > use the master branch.
>>>> >>> > In the end we will checkout the repository to a particular commit
>>>> >>> > from
>>>> >>> > which
>>>> >>> > the downloaded Pharo 7 image was bootstrapped. Imagine that you have
>>>> >>> > a
>>>> >>> > Pharo
>>>> >>> > 7 image that is several days old and the development branch has
>>>> >>> > already
>>>> >>> > some
>>>> >>> > commits that change code. If you would take this older image,
>>>> >>> > checkout
>>>> >>> > to
>>>> >>> > the development branch and then do your commit, your would revert
>>>> >>> > all
>>>> >>> > changes done in not-loaded commits. The other option is to update
>>>> >>> > your
>>>> >>> > image
>>>> >>> > to correspond to the repository latest commit which requires
>>>> >>> > packages
>>>> >>> > reloading.
>>>> >>> > If you checkout to a particular commit, you are in detached HEAD
>>>> >>> > state.
>>>> >>> > In
>>>> >>> > this state you cannot do commits directly. You need to firstly
>>>> >>> > create
>>>> >>> > new a
>>>> >>> > new branch which we will do anyway.
>>>> >>> >
>>>> >>> > Evaluate the following code. This functionality will be later direct
>>>> >>> > part of
>>>> >>> > Iceberg UI. Do not forget to change the user name.
>>>> >>> >
>>>> >>> > username := 'YOUR-USER-NAME'.
>>>> >>> > repository := IceRepositoryCreator new
>>>> >>> > url: '[hidden email]:pharo-project/pharo.git';
>>>> >>> > location: ('pharo-core' asFileReference ensureCreateDirectory);
>>>> >>> > subdirectory:'src';
>>>> >>> > createRepository.
>>>> >>> > repository checkoutBranch: 'development'.
>>>> >>> > repository register.
>>>> >>> >
>>>> >>> > fork := (IceRemote name: 'myFork' url:
>>>> >>> > ('[hidden email]:{1}/pharo.git'
>>>> >>> > format: {username})).
>>>> >>> > repository addRemote: fork.
>>>> >>> > repository pushRemote: fork.
>>>> >>> > repository pullRemote: repository origin.
>>>> >>> >
>>>> >>> > "update fork"
>>>> >>> > repository backend pullFrom: repository origin. "use this low-level
>>>> >>> > form
>>>> >>> > to
>>>> >>> > prevent packages reloading"
>>>> >>> > repository push.
>>>> >>> >
>>>> >>> > "checkout to the commit from which the image was bootstrapped"
>>>> >>> > repository checkoutBranch: (SystemVersion current commitHash).
>>>> >>> >
>>>> >>> > Use already created clone
>>>> >>> > =====================
>>>> >>> >
>>>> >>> > This is alternative to the previous step. Let's suppose that you
>>>> >>> > already
>>>> >>> > have your local clone. You take some Pharo 7 image and you want to
>>>> >>> > create
>>>> >>> > commits. Then you need to create a symlink or move/copy the
>>>> >>> > repository
>>>> >>> > into
>>>> >>> > your image directory. Remember, it must be named pharo-core (we do
>>>> >>> > not
>>>> >>> > use
>>>> >>> > the name 'pharo' to avoid collision with VM executable).
>>>> >>> >
>>>> >>> > In this step we will register an existing Pharo repository clone,
>>>> >>> > set
>>>> >>> > your
>>>> >>> > fork as the push target, update your fork and then switch to the
>>>> >>> > particular
>>>> >>> > commit.
>>>> >>> >
>>>> >>> > repository := IceRepositoryCreator new
>>>> >>> > location: ('pharo-core' asFileReference);
>>>> >>> > subdirectory:'src';
>>>> >>> > createRepository.
>>>> >>> > repository register.
>>>> >>> >
>>>> >>> > fork := repository remotes detect: [ :remote | remote remoteName =
>>>> >>> > #myFork
>>>> >>> > ].
>>>> >>> > repository pushRemote: fork.
>>>> >>> > repository pullRemote: repository origin.
>>>> >>> >
>>>> >>> > repository checkoutBranch: 'development'.
>>>> >>> > repository backend pullFrom: repository origin.
>>>> >>> > repository push.
>>>> >>> >
>>>> >>> > repository checkoutBranch: (SystemVersion current commitHash).
>>>> >>> >
>>>> >>> > 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
>>>> >>> >
>>>> >>> > Cheers,
>>>> >>> > -- Pavel
>>>> >>> >
>>>> >>>
>>>> >>
>>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2
In reply to this post by EstebanLM


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben






crash.dmp (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Pavel Krivanek-3
In reply to this post by Pavel Krivanek-3
A small update:

You are not forced to use a 'pharo-core' repository in your image folder if you provide a path to your own clone to the working copies of the bootstrapped packages. This way you can more easily share one local clone of the pharo-project/pharo repository. 
For the registration of your local repository use this script:

target := 'path/to/my/local/repository' asFileReference.

repository := IceRepositoryCreator new 
location: target;
subdirectory:'src';
createRepository.
repository register.

fork := repository remotes detect: [ :remote | remote remoteName = #myFork ].
repository pushRemote: fork.
repository pullRemote: repository origin.

repository checkoutBranch: 'development'.
repository backend pullFrom: repository origin. 
repository push.

repository checkoutBranch: (SystemVersion current commitHash).

fileTreeRepository := (MCFileTreeRepository new directory: target / #src; yourself).
repositoryGroup := MCRepositoryGroup withRepositories: { fileTreeRepository. MCCacheRepository uniqueInstance. }.
MCWorkingCopy allManagers 
select: [ :wc | (wc repositoryGroup repositories reject: [ :repo | repo isCache ]) isEmpty ] 
thenDo: [ :wc | wc repositoryGroup: repositoryGroup ]


2017-06-26 13:14 GMT+02:00 Pavel Krivanek <[hidden email]>:
Hi,

this mail describes how to start to send pull requests to Pharo 7 Github repository from Pharo 7.

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

Get Pharo 7 image
=====================

The CI jobs for the Pharo 7 defelopment are currently not fully set and we still do not publish Pharo 7 image to files.pharo.org so you cannot get it using zero-conf scripts. But we have a provisional CI job that bootstraps the Pharo 7 image. 


There download a file named like Pharo7.0-32bit-hash.zip and decompress it. Unlike Pharo 6 images, the archive contains three files. Image, changes and sources. In Pharo 7 you have the sources file for every bootstrapped version. It has a commit hash in the name and it cannot be shared between different Pharo 7 imges, however it can be shared between images that were created as snapshots with the same bootstrapped image as ancestor.

Create local clone
=====================

You need a local clone of the Pharo repository. Because it contains a lot of small files, it is not a good idea to have own clone for every image. You can have only one and share them between images. But because of some current Monticello constraints you need to have the clone placed in the image directory in a folder with name 'pharo-core'.

In this step we will clone the Pharo repository from pharo-project/pharo Github repository and add your fork as default pull target. We will update your fork repository to contain all latest commits from the Pharo repository in the branch named 'development'. For latest stable version (Pharo 6) we use the master branch.
In the end we will checkout the repository to a particular commit from which the downloaded Pharo 7 image was bootstrapped. Imagine that you have a Pharo 7 image that is several days old and the development branch has already some commits that change code. If you would take this older image, checkout to the development branch and then do your commit, your would revert all changes done in not-loaded commits. The other option is to update your image to correspond to the repository latest commit which requires packages reloading.
If you checkout to a particular commit, you are in detached HEAD state. In this state you cannot do commits directly. You need to firstly create new a new branch which we will do anyway.

Evaluate the following code. This functionality will be later direct part of Iceberg UI. Do not forget to change the user name.   

username := 'YOUR-USER-NAME'.
repository := IceRepositoryCreator new 
url: '[hidden email]:pharo-project/pharo.git';
location: ('pharo-core' asFileReference ensureCreateDirectory);
subdirectory:'src';
createRepository.
repository checkoutBranch: 'development'.
repository register.

fork := (IceRemote name: 'myFork' url: ('[hidden email]:{1}/pharo.git' format: {username})).
repository addRemote: fork.
repository pushRemote: fork.
repository pullRemote: repository origin.

"update fork"
repository backend pullFrom: repository origin. "use this low-level form to prevent packages reloading"
repository push.

"checkout to the commit from which the image was bootstrapped"
repository checkoutBranch: (SystemVersion current commitHash).

Use already created clone
=====================

This is alternative to the previous step. Let's suppose that you already have your local clone. You take some Pharo 7 image and you want to create commits. Then you need to create a symlink or move/copy the repository into your image directory. Remember, it must be named pharo-core (we do not use the name 'pharo' to avoid collision with VM executable).

In this step we will register an existing Pharo repository clone, set your fork as the push target, update your fork and then switch to the particular commit.

repository := IceRepositoryCreator new 
location: ('pharo-core' asFileReference);
subdirectory:'src';
createRepository.
repository register.

fork := repository remotes detect: [ :remote | remote remoteName = #myFork ].
repository pushRemote: fork.
repository pullRemote: repository origin.

repository checkoutBranch: 'development'.
repository backend pullFrom: repository origin. 
repository push.

repository checkoutBranch: (SystemVersion current commitHash).

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

Cheers,
-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2
In reply to this post by Nicolai Hess-3-2


2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben






Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Uko2
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 <[hidden email]> wrote:



2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:

>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Pavel Krivanek-3
In reply to this post by Nicolai Hess-3-2
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 <[hidden email]>:


2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben







Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Pavel Krivanek-3
In reply to this post by Uko2
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 <[hidden email]>:
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 <[hidden email]> wrote:



2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:

>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2
In reply to this post by Pavel Krivanek-3


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 <[hidden email]>:


2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben








Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2


2017-07-11 12:44 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 <[hidden email]>:


2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben









Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Uko2
In reply to this post by Pavel Krivanek-3
This is actually fun. For pharo contributions I just used Iceberg ui without scripting anything and it works absolutely fine. Iceberg has a default location for cloned repositories, and it puts pharo there too

Uko

On 4 Jul 2017, at 11:52, Pavel Krivanek <[hidden email]> wrote:

A small update:

You are not forced to use a 'pharo-core' repository in your image folder if you provide a path to your own clone to the working copies of the bootstrapped packages. This way you can more easily share one local clone of the pharo-project/pharo repository. 
For the registration of your local repository use this script:

target := 'path/to/my/local/repository' asFileReference.

repository := IceRepositoryCreator new 
location: target;
subdirectory:'src';
createRepository.
repository register.

fork := repository remotes detect: [ :remote | remote remoteName = #myFork ].
repository pushRemote: fork.
repository pullRemote: repository origin.

repository checkoutBranch: 'development'.
repository backend pullFrom: repository origin. 
repository push.

repository checkoutBranch: (SystemVersion current commitHash).

fileTreeRepository := (MCFileTreeRepository new directory: target / #src; yourself).
repositoryGroup := MCRepositoryGroup withRepositories: { fileTreeRepository. MCCacheRepository uniqueInstance. }.
MCWorkingCopy allManagers 
select: [ :wc | (wc repositoryGroup repositories reject: [ :repo | repo isCache ]) isEmpty ] 
thenDo: [ :wc | wc repositoryGroup: repositoryGroup ]


2017-06-26 13:14 GMT+02:00 Pavel Krivanek <[hidden email]>:
Hi,

this mail describes how to start to send pull requests to Pharo 7 Github repository from Pharo 7.

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

Get Pharo 7 image
=====================

The CI jobs for the Pharo 7 defelopment are currently not fully set and we still do not publish Pharo 7 image to files.pharo.org so you cannot get it using zero-conf scripts. But we have a provisional CI job that bootstraps the Pharo 7 image. 


There download a file named like Pharo7.0-32bit-hash.zip and decompress it. Unlike Pharo 6 images, the archive contains three files. Image, changes and sources. In Pharo 7 you have the sources file for every bootstrapped version. It has a commit hash in the name and it cannot be shared between different Pharo 7 imges, however it can be shared between images that were created as snapshots with the same bootstrapped image as ancestor.

Create local clone
=====================

You need a local clone of the Pharo repository. Because it contains a lot of small files, it is not a good idea to have own clone for every image. You can have only one and share them between images. But because of some current Monticello constraints you need to have the clone placed in the image directory in a folder with name 'pharo-core'.

In this step we will clone the Pharo repository from pharo-project/pharo Github repository and add your fork as default pull target. We will update your fork repository to contain all latest commits from the Pharo repository in the branch named 'development'. For latest stable version (Pharo 6) we use the master branch.
In the end we will checkout the repository to a particular commit from which the downloaded Pharo 7 image was bootstrapped. Imagine that you have a Pharo 7 image that is several days old and the development branch has already some commits that change code. If you would take this older image, checkout to the development branch and then do your commit, your would revert all changes done in not-loaded commits. The other option is to update your image to correspond to the repository latest commit which requires packages reloading.
If you checkout to a particular commit, you are in detached HEAD state. In this state you cannot do commits directly. You need to firstly create new a new branch which we will do anyway.

Evaluate the following code. This functionality will be later direct part of Iceberg UI. Do not forget to change the user name.   

username := 'YOUR-USER-NAME'.
repository := IceRepositoryCreator new 
url: '[hidden email]:pharo-project/pharo.git';
location: ('pharo-core' asFileReference ensureCreateDirectory);
subdirectory:'src';
createRepository.
repository checkoutBranch: 'development'.
repository register.

fork := (IceRemote name: 'myFork' url: ('[hidden email]:{1}/pharo.git' format: {username})).
repository addRemote: fork.
repository pushRemote: fork.
repository pullRemote: repository origin.

"update fork"
repository backend pullFrom: repository origin. "use this low-level form to prevent packages reloading"
repository push.

"checkout to the commit from which the image was bootstrapped"
repository checkoutBranch: (SystemVersion current commitHash).

Use already created clone
=====================

This is alternative to the previous step. Let's suppose that you already have your local clone. You take some Pharo 7 image and you want to create commits. Then you need to create a symlink or move/copy the repository into your image directory. Remember, it must be named pharo-core (we do not use the name 'pharo' to avoid collision with VM executable).

In this step we will register an existing Pharo repository clone, set your fork as the push target, update your fork and then switch to the particular commit.

repository := IceRepositoryCreator new 
location: ('pharo-core' asFileReference);
subdirectory:'src';
createRepository.
repository register.

fork := repository remotes detect: [ :remote | remote remoteName = #myFork ].
repository pushRemote: fork.
repository pullRemote: repository origin.

repository checkoutBranch: 'development'.
repository backend pullFrom: repository origin. 
repository push.

repository checkoutBranch: (SystemVersion current commitHash).

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

Cheers,
-- Pavel



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Stephane Ducasse-3
Tx Uko.
We should improve.

On Tue, Jul 11, 2017 at 7:07 PM, Yuriy Tymchuk <[hidden email]> wrote:

> This is actually fun. For pharo contributions I just used Iceberg ui without
> scripting anything and it works absolutely fine. Iceberg has a default
> location for cloned repositories, and it puts pharo there too
>
> Uko
>
> On 4 Jul 2017, at 11:52, Pavel Krivanek <[hidden email]> wrote:
>
> A small update:
>
> You are not forced to use a 'pharo-core' repository in your image folder if
> you provide a path to your own clone to the working copies of the
> bootstrapped packages. This way you can more easily share one local clone of
> the pharo-project/pharo repository.
> For the registration of your local repository use this script:
>
> target := 'path/to/my/local/repository' asFileReference.
>
> repository := IceRepositoryCreator new
> location: target;
> subdirectory:'src';
> createRepository.
> repository register.
>
> fork := repository remotes detect: [ :remote | remote remoteName = #myFork
> ].
> repository pushRemote: fork.
> repository pullRemote: repository origin.
>
> repository checkoutBranch: 'development'.
> repository backend pullFrom: repository origin.
> repository push.
>
> repository checkoutBranch: (SystemVersion current commitHash).
>
> fileTreeRepository := (MCFileTreeRepository new directory: target / #src;
> yourself).
> repositoryGroup := MCRepositoryGroup withRepositories: { fileTreeRepository.
> MCCacheRepository uniqueInstance. }.
> MCWorkingCopy allManagers
> select: [ :wc | (wc repositoryGroup repositories reject: [ :repo | repo
> isCache ]) isEmpty ]
> thenDo: [ :wc | wc repositoryGroup: repositoryGroup ]
>
>
> 2017-06-26 13:14 GMT+02:00 Pavel Krivanek <[hidden email]>:
>>
>> Hi,
>>
>> this mail describes how to start to send pull requests to Pharo 7 Github
>> repository from Pharo 7.
>>
>> 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
>>
>> Get Pharo 7 image
>> =====================
>>
>> The CI jobs for the Pharo 7 defelopment are currently not fully set and we
>> still do not publish Pharo 7 image to files.pharo.org so you cannot get it
>> using zero-conf scripts. But we have a provisional CI job that bootstraps
>> the Pharo 7 image.
>>
>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/
>>
>> There download a file named like Pharo7.0-32bit-hash.zip and decompress
>> it. Unlike Pharo 6 images, the archive contains three files. Image, changes
>> and sources. In Pharo 7 you have the sources file for every bootstrapped
>> version. It has a commit hash in the name and it cannot be shared between
>> different Pharo 7 imges, however it can be shared between images that were
>> created as snapshots with the same bootstrapped image as ancestor.
>>
>> Create local clone
>> =====================
>>
>> You need a local clone of the Pharo repository. Because it contains a lot
>> of small files, it is not a good idea to have own clone for every image. You
>> can have only one and share them between images. But because of some current
>> Monticello constraints you need to have the clone placed in the image
>> directory in a folder with name 'pharo-core'.
>>
>> In this step we will clone the Pharo repository from pharo-project/pharo
>> Github repository and add your fork as default pull target. We will update
>> your fork repository to contain all latest commits from the Pharo repository
>> in the branch named 'development'. For latest stable version (Pharo 6) we
>> use the master branch.
>> In the end we will checkout the repository to a particular commit from
>> which the downloaded Pharo 7 image was bootstrapped. Imagine that you have a
>> Pharo 7 image that is several days old and the development branch has
>> already some commits that change code. If you would take this older image,
>> checkout to the development branch and then do your commit, your would
>> revert all changes done in not-loaded commits. The other option is to update
>> your image to correspond to the repository latest commit which requires
>> packages reloading.
>> If you checkout to a particular commit, you are in detached HEAD state. In
>> this state you cannot do commits directly. You need to firstly create new a
>> new branch which we will do anyway.
>>
>> Evaluate the following code. This functionality will be later direct part
>> of Iceberg UI. Do not forget to change the user name.
>>
>> username := 'YOUR-USER-NAME'.
>> repository := IceRepositoryCreator new
>> url: '[hidden email]:pharo-project/pharo.git';
>> location: ('pharo-core' asFileReference ensureCreateDirectory);
>> subdirectory:'src';
>> createRepository.
>> repository checkoutBranch: 'development'.
>> repository register.
>>
>> fork := (IceRemote name: 'myFork' url: ('[hidden email]:{1}/pharo.git'
>> format: {username})).
>> repository addRemote: fork.
>> repository pushRemote: fork.
>> repository pullRemote: repository origin.
>>
>> "update fork"
>> repository backend pullFrom: repository origin. "use this low-level form
>> to prevent packages reloading"
>> repository push.
>>
>> "checkout to the commit from which the image was bootstrapped"
>> repository checkoutBranch: (SystemVersion current commitHash).
>>
>> Use already created clone
>> =====================
>>
>> This is alternative to the previous step. Let's suppose that you already
>> have your local clone. You take some Pharo 7 image and you want to create
>> commits. Then you need to create a symlink or move/copy the repository into
>> your image directory. Remember, it must be named pharo-core (we do not use
>> the name 'pharo' to avoid collision with VM executable).
>>
>> In this step we will register an existing Pharo repository clone, set your
>> fork as the push target, update your fork and then switch to the particular
>> commit.
>>
>> repository := IceRepositoryCreator new
>> location: ('pharo-core' asFileReference);
>> subdirectory:'src';
>> createRepository.
>> repository register.
>>
>> fork := repository remotes detect: [ :remote | remote remoteName = #myFork
>> ].
>> repository pushRemote: fork.
>> repository pullRemote: repository origin.
>>
>> repository checkoutBranch: 'development'.
>> repository backend pullFrom: repository origin.
>> repository push.
>>
>> repository checkoutBranch: (SystemVersion current commitHash).
>>
>> 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
>>
>> Cheers,
>> -- Pavel
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2
In reply to this post by Nicolai Hess-3-2


2017-07-11 12:46 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:44 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 <[hidden email]>:


2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben










Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2


2017-07-24 9:45 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:46 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:44 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 <[hidden email]>:


2017-07-03 23:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 28 Jun 2017, at 18:21, Nicolai Hess <[hidden email]> 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:     '[hidden email]: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" <[hidden email]>:


2017-06-28 17:06 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]> wrote:


On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <[hidden email]> wrote:

El 28-06-2017, a las 02:57, Ben Coman <[hidden email]> escribió:



On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <[hidden email]> wrote:


2017-06-27 16:17 GMT+02:00 Serge Stinckwich <[hidden email]>:
On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
<[hidden email]> wrote:
>
>
> 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <[hidden email]>:
>>
>> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>> <[hidden email]> 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...


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

cheers -ben











Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2


2017-07-28 23:13 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-24 9:45 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:46 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:44 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 ?
 
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

Nicolai Hess-3-2


2017-07-28 23:19 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-28 23:13 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-24 9:45 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:46 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:44 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 ?

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

EstebanLM


On 8 Aug 2017, at 20:40, Nicolai Hess <[hidden email]> wrote:



2017-07-28 23:19 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-28 23:13 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-24 9:45 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:46 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:44 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-11 12:28 GMT+02:00 Pavel Krivanek <[hidden email]>:
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 


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 provisional HOWTO

CyrilFerlicot
In reply to this post by Nicolai Hess-3-2
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


signature.asc (836 bytes) Download Attachment
123