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

[ANN] Next Pharo Sprint: Aug 31

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Aug 31, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events <http://pharo.org/contribute-events> Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973616 <https://association.pharo.org/event-2973616>

Aug. 22, 2018

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

by Christophe Demarey

Hi all, Indeed, there is now a problem to run recent Pharo 7 images from the launcher. The problem comes from the integration of this change: https://github.com/pharo-project/pharo/pull/1684. This change is good but requires the last VM. If you do not have a recent VM, you wonât be able to run latest Pharo 7 images. It does not affect other images. Assuming you use a PharoLauncher 64-bits: For now, there is a workaround to run latest Pharo 7 32-bits images: remove the vms folder from Documents/Pharo, then start Pharo Launcher. It will automatically get the latest 32-bits VM. For Pharo 7 64-bits images, the problem is a bit harder: - Pharo Launcher uses the VM shipped with itself to determine image version. This image has to be updated. - It looks like the latest 61 VM does not have the code required to avoid the problem (code change in Pharo 70, fix in Pharo 70 VM). Maybe it would be best that Pharo Launcher never uses its own VM to determine pharo version of images having a compatible image format number? If so, a solution could be to always use the latest available VM compatible with the image format number to determine the pharo version. It does not guarantee that it will always work but we have to deal with the problem that, for now, it is impossible to know the pharo version of an image without running it. In the future, it would be nice to embed this information in the image header. As a workaround for now, we are thinking to ship the pharo.version file along with the image to avoid to run images with compatible VMs that we cannot ensure they work well with a given image. I will come back to you once we have a fix for this problem. Sorry for the inconvenience. Christophe > Le 22 aoÃ»t 2018 Ã 02:10, nacho <0800nacho(a)gmail.com> a Ã©crit : > > I have the same problem. > Just erased everything and downloaded a new pharo-launcher and the problem > is still there.... > I'm using PharoLauncher 1.3-2018.06.21 (21.0) > All the images are useless..... > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 22, 2018

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

by nacho

I have the same problem. Just erased everything and downloaded a new pharo-launcher and the problem is still there.... I'm using PharoLauncher 1.3-2018.06.21 (21.0) All the images are useless..... ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 22, 2018

Re: [Pharo-dev] Extension methods in p7

by Denis Kudriashov

Yes, the problem related to some changes. In latest image I have two packages: Gofer-Core and Gofer-core-accessing. So all such extensions force separate packages. 2018-08-21 10:10 GMT+01:00 Torsten Bergmann <astares(a)gmx.de>: > 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/272816.html > > 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] Reducing the cost of documentation

by Alistair Grant

Hi Torsten, Thanks for your feedback. On Mon, Aug 20, 2018 at 09:29:35AM +0200, Torsten Bergmann wrote: > Hi Alistair, > > I don't think the contribution process hold people back from writing > documentation since providing a contribution is easy to do now (see [1] and [2]). > > And (even when more cumbersome) I like the review process - as it helped > several times in the past to discuss contributions or even fixing them or find trivial typos. > > I guess the primary problem is lazyness: people dont like to write > documentation as it is always additional effort. Remember that often people > do not even write a simple comment on a class to inform about the purpose > it was created... > > I personally doubt that we increase the number and quality of the provided > in-image docu with the proposal. I agree that code reviews are good - my code is much better for all the feedback I get from various members of this community (I'm not going to name names since I'm bound to leave someone out). And I agree that "laziness" plays a significant role - programmers are renowned for not wanting to write documentation / comments. However I think wikis are a good example demonstrating that documentation can be generated under the right conditions. Admitedly there's more required than making it easy to submit a change - having formatted class comments would also encourage people to maintain the documentation. From memory there are plans to support Pillar in class comments, and the work the Feenk are doing will no doubt improve things. So hopefully formatting will not be an issue soon(ish). So I still think that reducing the cost of submitting documentation changes would be worthwhile. But, given the lack of other replies, it looks like I'm in the minority, so I'll keep quiet (for now :-)). Thanks again, Alistair > Bye > T. > > [1] https://github.com/pharo-project/pharo/blob/development/CONTRIBUTING.md > [2] https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > > > > Gesendet: Montag, 20. August 2018 um 08:37 Uhr > > Von: "Alistair Grant" <akgrant0710(a)gmail.com> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Betreff: [Pharo-dev] Reducing the cost of documentation > > > > Hi Everyone, > > > > The topic of documentation recently came up again on the squeak list and > > it made me wonder about some of the blocks that currently prevent more > > contributions to in-image documentation. > > > > One of the things holding back the in-image documentation is that the > > cost of contributing is too high: apart from actually making the change > > we currently have to (maybe) open an issue, create a branch, commit and > > open a PR. Someone with commit privileges then has to review the PR > > enough and decide to merge it. We then need to manually delete the > > branch some time later. > > > > This is one of the reasons that wikis have been successful, they lower > > the cost of making changes. > > > > We could extend iceberg to automatically submit PRs for documentation > > only commits (it could be a separate option, so that the doco only > > requirement is enforced), and set up github to auto-accept the PR. > > Modifying in-image documentation would then become a few extra clicks, > > significantly lowering the cost. > > > > I'm not familiar with Jenkins, or any other CI system, but hunting > > around google it looks like it may be possible to directly implement > > this, if not there are services such as https://mergify.io/ which > > advertise being able to do this by using flags in the CI to determine > > whether the PR should be merged (disclaimer, I've never looked at > > mergify.io, just found it while thinking about this). > > > > Thoughts? > > > > > > Cheers, > > Alistair > > > > >

Aug. 21, 2018

[Pharo 7.0-dev] Build #1190: 22352 Better tagging in ReflectionMirrors-Primitives and related tests

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

There is a new Pharo build available! The status of the build #1190 was: SUCCESS. The Pull Request #1708 was integrated: "22352 Better tagging in ReflectionMirrors-Primitives and related tests" Pull request url: https://github.com/pharo-project/pharo/pull/1708 Issue Url: https://pharo.fogbugz.com/f/cases/22352 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 21, 2018

[Pharo 7.0-dev] Build #1189: 22293-Sendersimplementors-searching-can-cause-DNU-in-Rubric

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

There is a new Pharo build available! The status of the build #1189 was: SUCCESS. The Pull Request #1668 was integrated: "22293-Sendersimplementors-searching-can-cause-DNU-in-Rubric" Pull request url: https://github.com/pharo-project/pharo/pull/1668 Issue Url: https://pharo.fogbugz.com/f/cases/22293 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 21, 2018

[update 6.0] #60543

by Marcus Denker

60543 ----- 22346 #mustBeBooleanDeOptimizeIn: needs to clean semantic annotation before recompile https://pharo.fogbugz.com/f/cases/22346 22356 CompiledMethod: #methodNode should reuse #parseTree https://pharo.fogbugz.com/f/cases/22356

Aug. 21, 2018

[Pharo 7.0-dev] Build #1188: 22324-Wrong-implementation-of-stop-in-RBMethodNode

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

There is a new Pharo build available! The status of the build #1188 was: FAILURE. The Pull Request #1713 was integrated: "22324-Wrong-implementation-of-stop-in-RBMethodNode" Pull request url: https://github.com/pharo-project/pharo/pull/1713 Issue Url: https://pharo.fogbugz.com/f/cases/22324 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 21, 2018

Submit your Project to the ESUG Awards

by N. Bouraqadi

Hi everyone! This is a reminder to submit your projects to the ESUG Innovation Technology Awards. It will be held on september the 10th as part of the ESUG conference in Sardinia (https://esug.github.io/2018-Conference/conf2018.html) Any Pharo Smalltalk-related project is eligible. All you need to do is provide me with few info and give a short demo during the awards session. I hope to hear from you soon, Noury

Aug. 21, 2018

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

[Pharo 7.0-dev] Build #1183: 22327-Add-a-rule-to-check-the-use-of-printString-inside-printOnaStream

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

There is a new Pharo build available! The status of the build #1183 was: SUCCESS. The Pull Request #1691 was integrated: "22327-Add-a-rule-to-check-the-use-of-printString-inside-printOnaStream" Pull request url: https://github.com/pharo-project/pharo/pull/1691 Issue Url: https://pharo.fogbugz.com/f/cases/22327 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 20, 2018

[Pharo 7.0-dev] Build #1182: 22330-PluggableSliderMorph-does-not-respect-theme-

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

There is a new Pharo build available! The status of the build #1182 was: SUCCESS. The Pull Request #1694 was integrated: "22330-PluggableSliderMorph-does-not-respect-theme-" Pull request url: https://github.com/pharo-project/pharo/pull/1694 Issue Url: https://pharo.fogbugz.com/f/cases/22330 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 20, 2018

[Pharo 7.0-dev] Build #1181: 22346-mustBeBooleanDeOptimizeIn-needs-to-clean-semantic-annotation-before-recompile

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

There is a new Pharo build available! The status of the build #1181 was: FAILURE. The Pull Request #1704 was integrated: "22346-mustBeBooleanDeOptimizeIn-needs-to-clean-semantic-annotation-before-recompile" Pull request url: https://github.com/pharo-project/pharo/pull/1704 Issue Url: https://pharo.fogbugz.com/f/cases/22346 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 20, 2018

Pharo and Docker (some steps)

by Torsten Bergmann

For those interested in Docker: I recently played with Pharo and Docker and summarized some of my steps in a small tutorial in my Pharo wiki: http://wiki.astares.com/pharo/613 There is also a page following Mike Filonovs suggestions on the Pharo docker file: http://wiki.astares.com/pharo/615 Maybe this is useful for others too. Bye T.

Aug. 20, 2018

[Pharo 7.0-dev] Build #1180: 22308-Cleaning-baseClassclassClass-leftovers

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

There is a new Pharo build available! The status of the build #1180 was: SUCCESS. The Pull Request #1689 was integrated: "22308-Cleaning-baseClassclassClass-leftovers" Pull request url: https://github.com/pharo-project/pharo/pull/1689 Issue Url: https://pharo.fogbugz.com/f/cases/22308 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 20, 2018