March 2020 - Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #146: Add executable comments in SequenceableCollection - conevrting protocol

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #146 was: FAILURE. The Pull Request #5806 was integrated: "Add executable comments in SequenceableCollection - conevrting protocol" Pull request url: https://github.com/pharo-project/pharo/pull/5806 Issue Url: https://github.com/pharo-project/pharo/issues/Pharo9.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 15, 2020

Re: [Pharo-dev] Iceberg confusion

by Esteban Lorenzano

Hi, > On 14 Mar 2020, at 04:35, Ben Coman <btc(a)openinworld.com> wrote: > > So I discovered a bug with Pharo Launcher and logged... https://github.com/pharo-project/pharo-launcher/issues/431 <https://github.com/pharo-project/pharo-launcher/issues/431> > and then wanted to contributing a fix, > but hit some confusion with Iceberg that discouraged me continuing. > > The first thing I'm compelled to do to build my sense of control/mastery of the situation > is sync the local github repo to the in-Image code, and I continually struggle with doing this quickly and fluently. wellâ¦ no :) It doesnât matters in which commit you are, you can just create a branch from there and commit your changes there. > > > In a fresh install of Pharo Launcher (pharo-launcher-1.9.2.zip), > after opening Iceberg and on the pharo-launcher repo > doing Repair > Clone again this repository > Clone from github.com <http://github.com/> > + Owner Name: pharo-project > + Project Name: pharo-launcher > > I find it is "not-yet" repaired. There is more-to-do [1] to repair a "Detach Working Copy" > <image.png> > > A newcomer confronted with that may just stop there > but I'm familiar with Iceberg so IIUC to clear a "Detached Working Copy" I need to do checkout a commit. No you donât :) Detached working copy does not means you need to checkout a commit. It means you are working in a commit which is not your head. You have several strategies (repairs) you can follow here : - you can indeed checkout the head. - you can create a branch from your commit. - you can discard what you have in image and load what is the working copy head. > So I try... Right-click pharo-launcher > Repository... > <image.png> > > But that doesn't help me since there is no clue which commit the in-Image code came from**, so I don't know which to check out. You do not want to checkout a commit, see previous comment. > I presume the middle tab at the bottom is showing the diff between "a49ef1d to HEAD" on disk and not the in-Image source. > > If I take a guess to check out the latest then that shows a lot of difference, so that is discouraging. I really don't want to have to try checking out each commit in turn searching for the matching one. > > Now luckily half an hour later while writing this post I notice there is a "1.9.2" tag. Checking this out gave now differences so yay! I managed to work around my problem. But still, I lost that half-hour (and similar many times before) so my Big Question still remains... > > Why must information about where there code comes always from be deleted from release-images??? > > Above I had prior knowledge to to fill in the "Repair" fields with > + Owner Name: pharo-project > + Project Name: pharo-launcher > > but other times having to research-and-guess what these fields should be > to match in-Image code is a real barrier to contributing. > > It would be really-really great if rather than an image being delivered like this... > <image.png> > > it would look like this... > <image.png> > with all the other Unknowns also filled in, > but discovering that info would take another half hour (also a case in point) > > This would make it simple to fill in the Repair dialog fields, > and remove my main workflow irritation in an otherwise fantastic tool. > > cheers -ben Esteban

March 14, 2020

Iceberg confusion

by Ben Coman

So I discovered a bug with Pharo Launcher and logged... https://github.com/pharo-project/pharo-launcher/issues/431 and then wanted to contributing a fix, but hit some confusion with Iceberg that discouraged me continuing. The first thing I'm compelled to do to build my sense of control/mastery of the situation is sync the local github repo to the in-Image code, and I continually struggle with doing this quickly and fluently. In a fresh install of Pharo Launcher (pharo-launcher-1.9.2.zip), after opening Iceberg and on the pharo-launcher repo doing Repair > Clone again this repository > Clone from github.com + Owner Name: pharo-project + Project Name: pharo-launcher I find it is "not-yet" repaired. There is more-to-do [1] to repair a "Detach Working Copy" [image: image.png] A newcomer confronted with that may just stop there but I'm familiar with Iceberg so IIUC to clear a "Detached Working Copy" I need to do checkout a commit. So I try... Right-click pharo-launcher > Repository... [image: image.png] But that doesn't help me since there is no clue which commit the in-Image code came from**, so I don't know which to check out. I presume the middle tab at the bottom is showing the diff between "a49ef1d to HEAD" on disk and not the in-Image source. If I take a guess to check out the latest then that shows a lot of difference, so that is discouraging. I really don't want to have to try checking out each commit in turn searching for the matching one. Now luckily half an hour later while writing this post I notice there is a "1.9.2" tag. Checking this out gave now differences so yay! I managed to work around my problem. But still, I lost that half-hour (and similar many times before) so my Big Question still remains... Why must information about where there code comes always from be deleted from release-images??? Above I had prior knowledge to to fill in the "Repair" fields with + Owner Name: pharo-project + Project Name: pharo-launcher but other times having to research-and-guess what these fields should be to match in-Image code is a real barrier to contributing. It would be really-really great if rather than an image being delivered like this... [image: image.png] it would look like this... [image: image.png] with all the other Unknowns also filled in, but discovering that info would take another half hour (also a case in point) This would make it simple to fill in the Repair dialog fields, and remove my main workflow irritation in an otherwise fantastic tool. cheers -ben

March 14, 2020

[Pharo 9.0] Build #145: Bug in the comparison of CompiledMethods

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #145 was: FAILURE. The Pull Request #5880 was integrated: "Bug in the comparison of CompiledMethods" Pull request url: https://github.com/pharo-project/pharo/pull/5880 Issue Url: https://github.com/pharo-project/pharo/issues/fixing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 13, 2020

[Pharo 9.0] Build #144: merge spec2 0.3

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #144 was: FAILURE. The Pull Request #5862 was integrated: "merge spec2 0.3" Pull request url: https://github.com/pharo-project/pharo/pull/5862 Issue Url: https://github.com/pharo-project/pharo/issues/merge Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 13, 2020

[Pharo 9.0] Build #143: 5875-Some-TTF-Fonts-are-not-visible-in-Pharo-Windows

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #143 was: SUCCESS. The Pull Request #5882 was integrated: "5875-Some-TTF-Fonts-are-not-visible-in-Pharo-Windows" Pull request url: https://github.com/pharo-project/pharo/pull/5882 Issue Url: https://github.com/pharo-project/pharo/issues/5875 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 11, 2020

[Pharo 9.0] Build #142: 5883-Cleanup GLMMorphic togglingButtonLabelled:pressed:style:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #142 was: FAILURE. The Pull Request #5884 was integrated: "5883-Cleanup GLMMorphic togglingButtonLabelled:pressed:style: " Pull request url: https://github.com/pharo-project/pharo/pull/5884 Issue Url: https://github.com/pharo-project/pharo/issues/5883 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 11, 2020

[ANN] Match Tool was successfully ported to Pharo 9

by Juan Pablo Sandoval Alcocer

Dear friends, I would like to comment that Sebastian, an intern of my company, just ported the MatchTool to Pharo 9. You may find the install instructions in the following link :) https://github.com/jordanmontt/MatchTool-Spec2 Please, help us to test it, any feedback is welcome. Regards, Juan P. Sandoval http://www.semantics.bo/ https://jpsandoval.github.io/

March 11, 2020

[Pharo 9.0] Build #141: UnsafeAlien is missing nonPointerObject: implementation

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #141 was: FAILURE. The Pull Request #5848 was integrated: "UnsafeAlien is missing nonPointerObject: implementation" Pull request url: https://github.com/pharo-project/pharo/pull/5848 Issue Url: https://github.com/pharo-project/pharo/issues/5847 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 11, 2020

[Pharo 9.0] Build #140: Fixing problem with class trait compositions with parens

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #140 was: SUCCESS. The Pull Request #5861 was integrated: "Fixing problem with class trait compositions with parens" Pull request url: https://github.com/pharo-project/pharo/pull/5861 Issue Url: https://github.com/pharo-project/pharo/issues/fixing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 10, 2020