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

[TechTalk] Contributing to External Projects with Iceberg

by tesonep＠gmail.com

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

Jan. 23, 2020

[Pharo 9.0] Build #22: Adding setting for the limit of items in spotter

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

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…

Jan. 23, 2020

[Pharo 9.0] Build #21: SUCCESS

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

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…

Jan. 23, 2020

[Pharo 9.0] Build #20: FAILURE

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

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…

Jan. 23, 2020

Re: [Pharo-dev] Fed up

by Eliot Miranda

Hi Ronie, On Tue, Jan 21, 2020 at 5:48 PM Ronie Salgado <roniesalg(a)gmail.com> wrote: > That performance regression looks more like a language implementation bug > that a problem of the language itself. If we assume that #do: and some > other selectors (e.g. #select, #reject) should always receive a block > instead of a symbol, then the compiler could perfectly replace the symbol > literal for an already instantiated block literal transparently from the > user perspective. If the compiler does that we can save the bytecode for > instantiating the block closure, which can save a potential roundtrip to > the garbage collector. I guess (I am just speculating) that this > performance overhead must be in the implementation of the #perform: > primitive, which I guess has to: > 1) go through the JIT stack into the C stack transition (saving/restoring > interpreter/JIT state, additional pressure, and primitive activation > overhead. > perform:, perform:with: et al (primitive 83), but not perform:withArguments: are completely implemented in machine code with no transition to C unless the method is not in the first-level method lookup cache. See genPrimitivePerform, genLookupForPerformNumArgs: and adjustArgumentsForPerform:. 2) the lack of inline caches for #perform: (again, I am just guessing in > this case). > Right. There is only the first level method lookup cache so it has interpreter-like performance. The selector and classs of receiver have to be hashed and the first-level method lookup cache probed. Way slower than block activation. I will claim though that Cog/Spur OpenSmalltalk's JIT perform implementation is as good as or better than any other Smalltalk VM's. IIRC VW only machine coded/codes perform: and perform:with: Note that the OpalCompiler is currently inlining some methods such as > #ifTrue:ifFalse: , #ifNil:ifNotNil: #and: #or: and there are not actual > message sends, so adding an additional list of selector where literal > symbol arguments are synthesized as blocks is not different to the cheating > that the current compiler is doing. If an user wants to disable this > inlining, there is currently a pragma for telling the compiler. > > Do you want me to propose an experimental patch for testing this > infrastructure? > > Best regards, > Ronie > > El mar., 21 ene. 2020 a las 19:56, Sven Van Caekenberghe (<sven(a)stfx.eu>) > escribiÃ³: > >> I also like the use of symbols but more for casual code. >> >> I know using blocks can be faster, but the difference is not massive. >> >> What I don't understand is why it is so super bad. Polymorphism will >> always be there, that is really powerful, when used wisely. I can't >> immediately see why one or the other would make analysis easier or better. >> Can you explain ? >> >> > On 21 Jan 2020, at 23:37, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> > >> > ducasse wrote >> >> in Pharo we should write >> >> aCol do: [ :each | each store ] >> > >> > I always enjoyed the Symbol/Block polymorphism because I thought it was >> such >> > a clever and visible example of the power of Smalltalk, and, let's face >> it, >> > I'm lazy and enjoyed saving a few key strokes! >> > >> > That said, I had no idea that there was a dramatic performance cost. >> Also, >> > the issues you raise about analysis seem important. >> > >> > Since people are free to still use it in their own projects, it doesn't >> seem >> > to controversial. Can/should we add a lint rule? Can/should it be >> scoped to >> > Pharo core? >> > >> > >> > >> > ----- >> > Cheers, >> > Sean >> > -- >> > Sent from: >> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > >> >> >> -- _,,,^..^,,,_ best, Eliot

Jan. 23, 2020

[Pharo 8.0] Build #1124: fix-predebug-error

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

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…

Jan. 22, 2020

Re: [Pharo-dev] Fed up

by ducasse

> On 22 Jan 2020, at 18:29, John Brant <brant(a)refactoryworkers.com> wrote: > > 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. This is a fun perspective. To me this is do we want to have a language that is super permissive instead of permissive and at which costs. Not measuring costs is not a good way to take decision. > 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. I will discuss it next week with Pablo because he wrote one. > > 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 To me this is not needed. Again my point is does it bring something for real or this is just a nice hack. And what is the impact. > > > John Brant

Jan. 22, 2020

[Pharo 9.0] Build #19: FAILURE

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

There is a new Pharo build available! The status of the build #19 was: FAILURE. Could not extract further issue information from commit message: Moving the upload after the split for architectures Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2020

[Pharo 9.0] Build #18: Add 64 bits to the list of architectures for test runs

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

There is a new Pharo build available! The status of the build #18 was: FAILURE. The Pull Request #5268 was integrated: "Add 64 bits to the list of architectures for test runs" Pull request url: https://github.com/pharo-project/pharo/pull/5268 Issue Url: https://github.com/pharo-project/pharo/issues/fix/tests64bits Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2020

Re: [Pharo-dev] Fed up

by John Brant

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

Jan. 22, 2020