August 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Extension methods in p7

by Norbert Hartl

Denis, I have the same in voyage, too. Marcus gave a possible reference for this https://github.com/pharo-project/pharo/pull/1685/files <https://github.com/pharo-project/pharo/pull/1685/files> Norbert > Am 21.08.2018 um 10:05 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi Norbert. > > In Calypso there are no protocols for extensions. You should simply call command Move methods to package either from menu or drag and drop to package (where you see it). > > I don't know what the reason for commit and removal. I will check. > > Ð²Ñ, 21 Ð°Ð²Ð³. 2018 Ð³., 8:32 Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: > Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g. > > *Magritte-model-builder > > These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? > Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. > In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested. > > Norbert > >

Aug. 21, 2018

[Pharo 7.0-dev] Build #1187: 22355-TestRunner-got-broken-because-baseClass-is-not-baseClass

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

There is a new Pharo build available! The status of the build #1187 was: SUCCESS. The Pull Request #1710 was integrated: "22355-TestRunner-got-broken-because-baseClass-is-not-baseClass" Pull request url: https://github.com/pharo-project/pharo/pull/1710 Issue Url: https://pharo.fogbugz.com/f/cases/22355 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 21, 2018

[Pharo 7.0-dev] Build #1186: 22340-Cleanup-String-new-comment

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

There is a new Pharo build available! The status of the build #1186 was: FAILURE. The Pull Request #1712 was integrated: "22340-Cleanup-String-new-comment" Pull request url: https://github.com/pharo-project/pharo/pull/1712 Issue Url: https://pharo.fogbugz.com/f/cases/22340 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 21, 2018

Re: [Pharo-dev] Extension methods in p7

by Torsten Bergmann

Hi Norbert, maybe it is unrelated - but I saw strange behavior with extensions and upper/lowercase leading to Iceberg showing "Uncomitted changes in latest image" as I wrote in http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-August/2728… My scenario: I use my https://github.com/astares/pharo-contributor project to automatically get the most recent pharo image (Pharo-7.0+alpha.build.1185) and synch my github fork with the development branch of pharo-project as shown in the video of this project. When Iceberg synchs it should usually SHOW A CLEAN IMAGE WITHOUT CHANGES DONE but since a week or so (maybe after the latest Iceberg integration) I see that there are uncommitted changes (see screenshot) although it is a fresh image. But my forks development branch is definitely in synch with the pharo-project development branch and the latest image (as it was green in CI) should be in synch with the sources as well. If I look more detailed on what Iceberg display as "changed" or "uncommitted" then one will notice that these are all extensions methods look different in the browser. For instance #goferPriority is an extension on package "Gofer-Core" but the extension is displayed in Calypso as "Gofer-core-accessing" with lowercase in the name. Maybe there was a change related to package detection ... Dont know if it is a known problem but for Iceberg I found something here from Pablo: (https://github.com/pharo-vcs/iceberg/pull/981) Bye T. > Gesendet: Dienstag, 21. August 2018 um 09:31 Uhr > Von: "Norbert Hartl" <norbert(a)hartl.name> > An: "Pharo Dev" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Extension methods in p7 > > Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g. > > *Magritte-model-builder > > These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? > Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. > In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested. > > Norbert > > >

Aug. 21, 2018

Re: [Pharo-dev] Extension methods in p7

by Denis Kudriashov

Hi Norbert. In Calypso there are no protocols for extensions. You should simply call command Move methods to package either from menu or drag and drop to package (where you see it). I don't know what the reason for commit and removal. I will check. Ð²Ñ, 21 Ð°Ð²Ð³. 2018 Ð³., 8:32 Norbert Hartl <norbert(a)hartl.name>: > Iâm about preparing magritte to be loadable in pharo 7. I encountered a > bit strange behaviour where I had to take cumbersome measures. Magritte has > method extensions that are called e.g. > > *Magritte-model-builder > > These methods get loaded but when I commit something all of these methods > are to be removed. The only thing I could do was to rename the extension > methods. Is this intended? > Doing the renaming I encountered of few things. Magritte had the extension > method above in the Magritte-Model package. When I rename the category > *Magritte-model-builder to *Magritte-Model the method gets removed. Not a > very usual case but still strange. > In order to create a method extension one needs first to create a new > protocol before converting to extension method. If the new protocol is > empty and you convert it to an extension method it gets removed. So I had > to first create a protocol, move a method in and then convert. This > combined with the behaviour that if you select two methods the method pane > jumps to the beginning of the list is a lot of work just to do this job. > Still it is not a very usual case but some might be interested. > > Norbert > > >

Aug. 21, 2018

Extension methods in p7

by Norbert Hartl

Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g. *Magritte-model-builder These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested. Norbert

Aug. 21, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Alistair Grant

Hi Julien, On Mon, 20 Aug 2018 at 18:22, Julien <julien.delplanque(a)inria.fr> wrote: > > When starting the image by hand in normal mode (like this): > > "/Users/julien/Documents/Pharo/vms/private/68021/Pharo.app/Contents/MacOS/Pharo" "/Users/julien/Documents/Pharo/images/DrTest/DrTest.image Â» > > The image starts but I get a PrimitiveFailed for #fileDescriptorType:. > > Maybe it could help to find where this comes from. This sounds like you are using an old VM with a new image. Try updating to the latest stable VM (dated Jun 2018 or later). Cheers, Alistair

Aug. 20, 2018

[Pharo 7.0-dev] Build #1185: 22347-Prama-ivar-keyword-should-be-selector

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

There is a new Pharo build available! The status of the build #1185 was: SUCCESS. The Pull Request #1705 was integrated: "22347-Prama-ivar-keyword-should-be-selector" Pull request url: https://github.com/pharo-project/pharo/pull/1705 Issue Url: https://pharo.fogbugz.com/f/cases/22347 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 20, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Julien

When starting the image by hand in normal mode (like this): "/Users/julien/Documents/Pharo/vms/private/68021/Pharo.app/Contents/MacOS/Pharo" "/Users/julien/Documents/Pharo/images/DrTest/DrTest.image Â» The image starts but I get a PrimitiveFailed for #fileDescriptorType:. Maybe it could help to find where this comes from. Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 19 aoÃ»t 2018 Ã 05:38, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > Julien wrote >> Is there something wrong with the latest Pharo 7.0 32bits image? >> I got this error from Pharo Launcher: > > This happened to me because Launcher did not create the `pharo.version` > file. I copied one from another Pharo 7 image and it then worked. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 20, 2018

[Pharo 7.0-dev] Build #1184: 22349-add-test-for-argsAsArray

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

There is a new Pharo build available! The status of the build #1184 was: FAILURE. The Pull Request #1706 was integrated: "22349-add-test-for-argsAsArray" Pull request url: https://github.com/pharo-project/pharo/pull/1706 Issue Url: https://pharo.fogbugz.com/f/cases/22349 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 20, 2018