- Pharo-dev - lists.pharo.org

[ANN] Pharo Consortium New Academic Member: ÃTS MontrÃ©al
by Marcus Denker Jan. 24, 2020

Jan. 24, 2020

The Pharo Consortium is very happy to announce that ÃTS MontrÃ©al has joined the Consortium as an Academic Member. About - ÃTS MontrÃ©al: https://www.etsmtl.ca/en/Home - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

1 0

Reddit Request: Bootstrap Example/Tutorial
by Sean P. DeNigris Jan. 24, 2020

Jan. 24, 2020

>> Deployment - it is now possible to bootstrap an image containing exactly what you want > Where can I see examples of how to do that? (Genuine question) I replied with http://forum.world.st/Pharo-Bootstrap-tt5080441.html, but maybe there's something better? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

1 0

Bug report from HN: Windows - "Unsupported 16-bit Application"
by Sean P. DeNigris Jan. 24, 2020

Jan. 24, 2020

Quote: vm doesn't start on Windows - "Unsupported 16-bit Application"... I resolved the issue by navigating to the directory where it downloaded the vm's, deleting the folder and unzipping manually. Seems the launcher corrupts the files when it unzips them. https://news.ycombinator.com/item?id=22100514 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

1 1

[TechTalk] Contributing to External Projects with Iceberg
by tesonep＠gmail.com Jan. 23, 2020

Jan. 23, 2020

Hi, I am sending the link of the video of today techtalk, maybe can be useful for someone. https://youtu.be/-jenQJp5m2U Cheers, Pablo -- Pablo Tesone. tesonep(a)gmail.com

1 0

[Pharo 9.0] Build #22: Adding setting for the limit of items in spotter
by ci-pharo-ci-jenkins2＠inria.fr Jan. 23, 2020

Jan. 23, 2020

There is a new Pharo build available! The status of the build #22 was: FAILURE. The Pull Request #5565 was integrated: "Adding setting for the limit of items in spotter" Pull request url: https://github.com/pharo-project/pharo/pull/5565 Issue Url: https://github.com/pharo-project/pharo/issues/5563 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #21: SUCCESS
by ci-pharo-ci-jenkins2＠inria.fr Jan. 23, 2020

Jan. 23, 2020

There is a new Pharo build available! The status of the build #21 was: SUCCESS. Could not extract further issue information from commit message: Updating the upload to handle 32 / 64 bits Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #20: FAILURE
by ci-pharo-ci-jenkins2＠inria.fr Jan. 23, 2020

Jan. 23, 2020

There is a new Pharo build available! The status of the build #20 was: FAILURE. Could not extract further issue information from commit message: Updating the upload to handle 32 / 64 bits Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Fed up
by ducasse Jan. 23, 2020

Jan. 23, 2020

Hi Iâm fed up. Why? Because I see lousy code in Pharo and that such lousy code in Pharo is slower, and sure that writing a type inferencer for pharo will be more complex, and probably will make sista more complex too. I asked the pharo consortium to take a clear position because I want a better Pharo not the inverse. So what is it. You can write in your code but not in Pharo. aCol do: #store in Pharo we should write aCol do: [ :each | each store ] Block argument should be blocks else any static analyser will have to check it is a block, it is a symbol, is it a RANDOM object that answer value. Seriously can be not make the life of people doing program analysis simpler? So now if Iâm wrong then I will shut up and Iâm really pissed that we do that without paying attention to the consequence. I asked the consortium to take position and to take action. We should have a better code review for REAL. S.

9 12

[Pharo 8.0] Build #1124: fix-predebug-error
by ci-pharo-ci-jenkins2＠inria.fr Jan. 22, 2020

Jan. 22, 2020

There is a new Pharo build available! The status of the build #1124 was: SUCCESS. The Pull Request #5554 was integrated: "fix-predebug-error" Pull request url: https://github.com/pharo-project/pharo/pull/5554 Issue Url: https://github.com/pharo-project/pharo/issues/fix Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Fed up
by John Brant Jan. 22, 2020

Jan. 22, 2020

On Jan 22, 2020, at 5:20 AM, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > Who, in their right mind, would code like that? Is it a trend among younger Smalltalkers while dinosaurs like me just "naturally" still use the "old way" and blocks? Using symbols for blocks has been around for quite some time. I heard about it from Ward Cunningham about 25 years ago. Early Smalltalk images were limited by the number of objects that could exist. If you used a block, then you needed to create an object for that block, but if you used a symbol, you didnât need any additional objects as the symbol already existed. When I heard about this, I didnât know of any Smalltalkâs that implemented Symbol>>value: in their base classes. I think it was a couple years later before I started seeing it used. As for whether Symbol>>value: should exist in the base Pharo image, I donât have a strong opinion. There are a bunch of methods/classes that could be removed from the base image and put into add-on packages. As for whether Pharo should allow someone to create such a method, I think it should. It really isnât any different from allowing me to add any method to any other class. As for the readability of the code, once you know the symbol as block âtrickâ, I find that they are both almost equally readable. In fact, the symbol version may be a little more readable as when you scan the block, you must check the receiver is âeachâ and not something else like âselfâ (which is the same length as âeachâ). Finally, as for making a type inferencer more complex, dealing with dynamically typed Smalltalk is already a complex job so if you can handle it without symbol blocks, I doubt that it would take much more to add support for them. BTW, there are other objects that implement #value:, and can be used instead of blocks. For example, to get a collection of the first 256 characters: (0 to: 255) collect: Character John Brant

2 1