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