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

[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

[Pharo 9.0] Build #19: FAILURE
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 #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…

1 0

[Pharo 9.0] Build #18: Add 64 bits to the list of architectures for test runs
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 #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…

1 0

[Pharo 9.0] Build #17: RB* and GR* should be renamed as Re* ... Rule - fixes: #5496
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 #17 was: FAILURE. The Pull Request #5497 was integrated: "RB* and GR* should be renamed as Re* ... Rule - fixes: #5496" Pull request url: https://github.com/pharo-project/pharo/pull/5497 Issue Url: https://github.com/pharo-project/pharo/issues/RenameRBGRRuleIntoReRule Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] [P9] Large images tag
by ducasse Jan. 22, 2020

Jan. 22, 2020

Thanks I went over the list and tagged nearly all of them. I think that P9 will be a real stabilisation phase. S. > On 22 Jan 2020, at 12:47, Vincent Blondeau <vincent.blondeau(a)lifeware.ch> wrote: > > > From: "Vincent Blondeau" <vincent.blondeau(a)lifeware.ch> > Subject: RE: [Pharo-dev] [P9] Large images tag > Date: 22 January 2020 at 12:47:21 CET > To: "'Pharo Development List'" <pharo-dev(a)lists.pharo.org> > > > Hi Stef, > > Great idea! Here are some that could be added to the list: > https://github.com/pharo-project/pharo/issues/5478 > https://github.com/pharo-project/pharo/issues/5260 > https://github.com/pharo-project/pharo/issues/5191 > https://github.com/pharo-project/pharo/issues/5188 > https://github.com/pharo-project/pharo/issues/5187 > https://github.com/pharo-project/pharo/issues/4896 > > Cheers, > Vincent > > Ps: only members of the Pharo git repo can tag issues. > > > -----Original Message----- > From: Pharo-dev On Behalf Of ducasse > Sent: Tuesday, 21 January 2020 20:34 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] [P9] Large images tag > > Hi all > > We are starting an effort to review and improve the behavior of pharo in presence of super large images. > I created a special tag to highlight the issues. > So if you have concerns and found annoying behavior related to slugginess in large image, please use this tag. > > We are also looking for misuse of operations fully scanning the memory or kind of like allInstances of and others. > > S. > > > > > >

1 0

[P9] Large images tag
by ducasse Jan. 22, 2020

Jan. 22, 2020

Hi all We are starting an effort to review and improve the behavior of pharo in presence of super large images. I created a special tag to highlight the issues. So if you have concerns and found annoying behavior related to slugginess in large image, please use this tag. We are also looking for misuse of operations fully scanning the memory or kind of like allInstances of and others. S.

2 1

[ANN] Cross Platform Embedding Example (Linux, MacOS)
by Pierce Ng Jan. 22, 2020

Jan. 22, 2020

Hi all, Inspired by Pablo's example, I've created a cross-platform implemenation. Pablo's example uses Pharo.image embedded as a Windows resource. Well, the excellent and, like Smalltalk, vastly underrated Free Pascal has built-in cross platform support for Windows resources. Basically I have implemented, in Pascal, FFI to libPharoVMCore and the embedded image access routines for callback by libPharoVMCore, together with a driver program to run the embedded Pharo.image. Repository is here: https://github.com/PierceNg/pharo-vm-embedded-pascal More details to come in the repository. Pierce

1 0