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

Human Reviews of Pull Requests

by Guillermo Polito

Hi all, As PRs are starting to stack, I think it would be good to gradually merge them. For that, I think it would be good to have both the automatic and a human review. When you issue a PR to the development branch, you see two validations are launched: - basic validation - full validation So far, they are in red because there are some failing tests (that we should fix BTW). By now we can consider that a PR that runs and has some failing tests is OK. Actually, being able to run the tests means also the bootstrap had no problems. I'm tagging such PRs with *human-review-needed* in github: https://github.com/pharo-project/pharo/pulls?q=is%3Apr+is%3Aopen+label%3Ahu… If gradually people can give their +1 or -1 to the PRs marked like that, we can quickly start integrating fixes. Guille -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 11, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> And if I only want to contribute by reviewing a fix. Do I have to go the >> git-path ? >> Or is there a way to just start up an image and load and review the >> change? >> >> >> right now, you can review by going to github and seeing. >> I will add a âPR toolâ to view/load PRs into an image, but thatâs not >> ready. If someone wants to take a hit on itâ¦ the idea is to extend the >> github plugin with it :) >> >> cheers! >> Esteban >> > > Anyone got this working on windows (32) ? > I followed this guide, enabled the ssh key setting for iceberg. > But I still got the error : > > Image: Pharo7.0SNAPSHOT [Latest update: #0] > > LGitReturnCodeEnum>>handleLGitReturnCode > Receiver: a LGitReturnCodeEnum(#git_error [-1]) > Arguments and temporary variables: > handler: LGit_GIT_ERROR > Receiver's instance variables: > value: -1 > > > LGitRepository(LGitExternalObject)>>withReturnHandlerDo: > Receiver: a LGitRepository (<not initialized>) > Arguments and temporary variables: > callBlock: [ self > clone: self > url: aString > local_path: aFileReference pathSt...etc... > Receiver's instance variables: > handle: @ 16r00000000 > repositoryPath: File @ pharo-core > isOpen: nil > workingDirectory: nil > > > LGitRepository>>clone:options:to: > Receiver: a LGitRepository (<not initialized>) > Arguments and temporary variables: > aString: 'git@github.com:pharo-project/pharo.git' > cloneOptions: a LGitCloneOptions () > aFileReference: File @ pharo-core > Receiver's instance variables: > handle: @ 16r00000000 > repositoryPath: File @ pharo-core > isOpen: nil > workingDirectory: nil > > > And finally after some more tries, the vm crashed > (crash.dmp attached). > > If this only happens on windows, what else would be an option to start > with contributing for pharo 7 ? > maybe I am doing something wrong ? I thought this should work now with the latest vm (and libgit)? It is still crashing for me. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed [0mExternalAddress class(Object)>>primitiveFailed: ExternalAddress class(Object)>>primitiveFailed ExternalAddress class>>allocate: LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository UndefinedObject>>DoIt VM windows 32 bit: CoInterpreter VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > >> >> >> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >> pavel.krivanek(a)gmail.com>: >> >> >> >> 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Hi all, >>> >>> Just to be clear, in Pharo 7, if I want to get some code integrated: >>> - I *have to* use the pull request process described by Pavel >>> OR >>> - I *can* use the pull request process, but I can also use the old slice >>> monticello process >>> ? >>> >>> What is the answer to the first question now, and what will be the >>> answer of this question in 6 months from now ? >>> >> >> You should use the pull request process. >> >> It is possible to create a standard slice BUT it must be done from Pharo >> 6 and then sent into Pharo60Inbox. And then you need to wait until somebody >> converts this slice to pull request. That means that it will be harder and >> harder to contribute this way because the code-base is moving. >> >> No slice will be integrated into Pharo 7 with the old process directly. >> >> Cheers, >> -- Pavel >> >> >> >>> >>> Thanks >>> >>> >>> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> >>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < >>>> juraj.kubelka(a)icloud.com> wrote: >>>> >>>>> >>>>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: >>>>> >>>>> >>>>> >>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>>> pavel.krivanek(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>>> serge.stinckwich(a)gmail.com>: >>>>>> >>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>>> > >>>>>>> > >>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>> serge.stinckwich(a)gmail.com>: >>>>>>> >> >>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>>>> >> > Hi, >>>>>>> >> > >>>>>>> >> > this mail describes how to start to send pull requests to Pharo >>>>>>> 7 Github >>>>>>> >> > repository from Pharo 7. >>>>>>> >> >>>>>>> >> Thank you for the great explanation Pavel. >>>>>>> >> >>>>>>> >> > Preparations >>>>>>> >> > ===================== >>>>>>> >> > >>>>>>> >> > - you need to have a Github account and set SSH keys. See >>>>>>> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >>>>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" button >>>>>>> and >>>>>>> >> > follow >>>>>>> >> > the instructions >>>>>>> >> >>>>>>> >> [ ... ] >>>>>>> >> >>>>>>> >> > Issue processing >>>>>>> >> > ===================== >>>>>>> >> > >>>>>>> >> > - create new case on FogBugz to get the issue number >>>>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>>>> repository do: >>>>>>> >> > Pharo >>>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID and >>>>>>> it will >>>>>>> >> > fill >>>>>>> >> > the full branch name for you >>>>>>> >> > - create your changes (you can do it before the creation of the >>>>>>> branch >>>>>>> >> > too) >>>>>>> >> > - commit and push your changes in Iceberg, this way you will >>>>>>> commit your >>>>>>> >> > branch to your fork repository. Remember that the Iceberg >>>>>>> commit window >>>>>>> >> > has >>>>>>> >> > two buttons, one for local commit, the second for commit with >>>>>>> immediate >>>>>>> >> > push. They can be very long because they contain the full >>>>>>> branch (issue) >>>>>>> >> > name >>>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >>>>>>> Create >>>>>>> >> > pull >>>>>>> >> > request, fill your >>>>>>> >> > - fill your Github credentials >>>>>>> >> > - leave the PR title, comment is not required, check the pull >>>>>>> request >>>>>>> >> > head >>>>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>>>> Create the >>>>>>> >> > pull >>>>>>> >> > requests >>>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check >>>>>>> your pull >>>>>>> >> > requests and put URL of it into the issue record on FogBugz (as >>>>>>> a >>>>>>> >> > comment). >>>>>>> >> > Resolve the issue as Fix review needed >>>>>>> >> >>>>>>> >> It means, there is no PR without a corresponding FogBugz issue ? >>>>>>> > >>>>>>> > >>>>>>> > Yes, at least for code changes we would like to keep this >>>>>>> relation. If it is >>>>>>> > a really trivial change in readme or something like that, we can >>>>>>> accept no >>>>>>> > related issue record. >>>>>>> > Please prefer to comment the issues instead of PRs directly to >>>>>>> have all >>>>>>> > information at one place. >>>>>>> >>>>>>> Thank you Pavel for the explanation. >>>>>>> >>>>>>> Maybe in the future, it will make sense to put everything in the PR >>>>>>> and use github issues. >>>>>>> You will use CI travis builds for all PR ? >>>>>>> >>>>>> >>>>>> For now we will use FogBugz because it has a lot of nice features and >>>>>> good API. Maybe we will switch it in future but now we should not change >>>>>> too many things at once :-) >>>>>> For several reasons we now prefer to use own infrastructure for >>>>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>>>> can be changed in future. >>>>>> >>>>>> >>>>> It would be interesting to see how this might fit in with our >>>>> workflow... >>>>> https://blog.fogcreek.com/fogbugz-github-integration/ >>>>> >>>>> >>>>> >>>>> What is the benefit of the integration? I do not understand it from >>>>> the given link. >>>>> >>>>> >>>> When you submit a PR on github, Fogbugz is automatically updated with a >>>> link to the PR. >>>> Presumably this makes it easier for people reviewing cases in Fogbugz >>>> to identify the slice to test. >>>> This is a better link... >>>> https://blog.fogcreek.com/improved-github-integration-automa >>>> tically-create-bug-events-with-commits/ >>>> >>>> cheers -ben >>>> >>> >>> >> >> >> >

July 10, 2017

Re: [Pharo-dev] integrating FileDialog into Pharo 7

by Pavel Krivanek

Can you try to prepare a pull requeast that will integrate it? The PR will need to: - add the packages into the repository - add them into the baseline (BaselineOfUI) - remove old FileDialogWindow (becuase when we add something, we should remove something too ;-)) If you need help, let me know -- Pavel 2017-07-10 20:01 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Done. What next? > > Peter > > > On Mon, Jul 10, 2017 at 12:46:50PM +0200, Pavel Krivanek wrote: > > We should work on integration of it. Firstly please move tests to a > > separate package. > > > > Cheers, > > -- Pavel > > > > 2017-07-10 12:34 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > > > Hi, > > > > > > some people expressed interest in integrating File Dialog > > > https://github.com/peteruhnak/file-dialog into Pharo as the default > file > > > dialog. > > > > > > Is it something people are interested in, or is the current solution > > > sufficient for them? > > > > > > Peter > > > > > > > >

July 10, 2017

Re: [Pharo-dev] integrating FileDialog into Pharo 7

by Peter Uhnak

Done. What next? Peter On Mon, Jul 10, 2017 at 12:46:50PM +0200, Pavel Krivanek wrote: > We should work on integration of it. Firstly please move tests to a > separate package. > > Cheers, > -- Pavel > > 2017-07-10 12:34 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > Hi, > > > > some people expressed interest in integrating File Dialog > > https://github.com/peteruhnak/file-dialog into Pharo as the default file > > dialog. > > > > Is it something people are interested in, or is the current solution > > sufficient for them? > > > > Peter > > > >

July 10, 2017

Re: [Pharo-dev] integrating FileDialog into Pharo 7

by Alexandre Bergel

Hi Peter! I have been using your file dialog for some time already. I really like it. Here some ideas of improvement. - double click instead of single click to dive in a folder? Single clicking feels a bit weird to me - Saving on the disk for preference folders? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jul 10, 2017, at 12:34 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > some people expressed interest in integrating File Dialog https://github.com/peteruhnak/file-dialog into Pharo as the default file dialog. > > Is it something people are interested in, or is the current solution sufficient for them? > > Peter >

July 10, 2017

Re: [Pharo-dev] integrating FileDialog into Pharo 7

by Pavel Krivanek

We should work on integration of it. Firstly please move tests to a separate package. Cheers, -- Pavel 2017-07-10 12:34 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > some people expressed interest in integrating File Dialog > https://github.com/peteruhnak/file-dialog into Pharo as the default file > dialog. > > Is it something people are interested in, or is the current solution > sufficient for them? > > Peter > >

July 10, 2017

integrating FileDialog into Pharo 7

by Peter Uhnak

Hi, some people expressed interest in integrating File Dialog https://github.com/peteruhnak/file-dialog into Pharo as the default file dialog. Is it something people are interested in, or is the current solution sufficient for them? Peter

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Pavel Krivanek

We can get the information using the GitHub API... like https://api.github.com/repos/pharo-project/pharo/commits/development?pathsr… -- Pavel 2017-07-10 11:32 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-10 11:22 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > >> On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote: >> > >> > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> > >> > However the real question is if we need them in the form we had >> them until >> > now because they are flattened as soon as a new changes file >> (release) is >> > created and it stores only information about the last person who >> touched >> > the method, not about the author nor wider history. >> > >> > For me, YES! >> > >> > I always take this data as a hint to track down bugs. Especially in >> > this community were different people do bug fixes or introduce >> > something new /change something, it is really helpfull and valueable >> > to track this changes by the method history. (not only *who* did the >> > change, but also, in what context, what else had changed. And I think >> > it is much easier to do this from within the image instead of looking >> > at the git diff). >> >> Are the two really mutually exclusive? Given the move to Iceberg >> wouldn't it make sense to extend Iceberg to be able to analyse the git >> history from within the image? >> > > > No, they are not mutually exclusive, it is just that you can not see the > history now. > Maybe iceberg will solve this, but for now you can not see the history > (and as a windows user, I can not even use iceberg). > > > >> >> >> > That hte history is already lost when we created a new changes/sources >> > for release is something that always disturbed me. And I hoped there >> > would be some way to reload the "real" history with all intermediate >> > changes. >> >> Cheers, >> Alistair >> >> >> >

July 10, 2017

Re: [Pharo-dev] latest 70 and vm

by Pavel Krivanek

So 64-bit version is now working too -- Pavel 2017-07-10 10:51 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Now we can get the latest Pharo 7 (32-bit only) by zero-conf: > > http://get.pharo.org/70+vm > http://get.pharo.org/70 > etc. > > Be sure that you have a virtual machine suitable for Pharo 7 (it contains > newer libgit2 version). > Pharo 7 is distributed in three files: image, changes and sources file > that is unique for every bootstrapped version, so if you use the zero-conf > scripts (e.g. on a CI), keep this in mind. > > Cheers, > > -- Pavel > > 2017-07-09 16:15 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Hi, >> >> I added upload of 32-bit version to CI so the link for the download of >> the version 7 starts to return proper result (for minimal image not). >> >> The link is http://files.pharo.org/image/70/latest.zip >> >> We still cannot use zero-conf because the script cannot process the new >> sources. >> >> -- Pavel >> >> 2017-07-09 14:12 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> In fact I cannot access it. So when esteban is back and fix the web >>> site we should not forget to update this. >>> >>> On Sun, Jul 9, 2017 at 2:04 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>> > Tx pavel I will update the website. >>> > >>> > >>> > On Sat, Jul 8, 2017 at 10:06 PM, Pavel Krivanek >>> > <pavel.krivanek(a)gmail.com> wrote: >>> >> the VM for Pharo 7 is available by zero-conf scripts >>> >> (http://get.pharo.org/vm70) or from files.pharo.org >>> >> (http://files.pharo.org/get-files/70/) >>> >> >>> >> We are currently not uploading Pharo 7 images to files.pharo.org. >>> They can >>> >> can be found here (32-bits): >>> >> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ >>> >> >>> >> -- Pavel >>> >> >>> >> >>> >> 2017-07-08 21:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com >>> >: >>> >>> >>> >>> Hi >>> >>> >>> >>> I realized that I forgot where I could find the latest 70 and vm. >>> >>> So I could not update the web site >>> >>> >>> >>> Stef >>> >>> >>> >> >>> >>> >> >

July 10, 2017

Re: [Pharo-dev] No Metadata in 7.0

by Nicolai Hess

2017-07-10 11:22 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote: > > > > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > > However the real question is if we need them in the form we had them > until > > now because they are flattened as soon as a new changes file > (release) is > > created and it stores only information about the last person who > touched > > the method, not about the author nor wider history. > > > > For me, YES! > > > > I always take this data as a hint to track down bugs. Especially in > > this community were different people do bug fixes or introduce > > something new /change something, it is really helpfull and valueable > > to track this changes by the method history. (not only *who* did the > > change, but also, in what context, what else had changed. And I think > > it is much easier to do this from within the image instead of looking > > at the git diff). > > Are the two really mutually exclusive? Given the move to Iceberg > wouldn't it make sense to extend Iceberg to be able to analyse the git > history from within the image? > No, they are not mutually exclusive, it is just that you can not see the history now. Maybe iceberg will solve this, but for now you can not see the history (and as a windows user, I can not even use iceberg). > > > > That hte history is already lost when we created a new changes/sources > > for release is something that always disturbed me. And I hoped there > > would be some way to reload the "real" history with all intermediate > > changes. > > Cheers, > Alistair > > >

July 10, 2017