- Pharo-dev - lists.pharo.org

[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

Unnecessary double checks of infinity
by Serge Stinckwich Jan. 22, 2020

Jan. 22, 2020

Hi all, I'm having a look how floats are printed. Why we check two times if a Float is infinite ? A first time in: Float>>printOn: stream base: base ... self isInfinite ifTrue: [ stream nextPutAll: 'Float infinity'. ^ self sign = -1 ifTrue: [ stream nextPutAll: ' negated' ] ]. ... and a second time in: Float>>absPrintExactlyOn: aStream base: base ... self isInfinite ifTrue: [ aStream nextPutAll: 'Float infinity'. ^ self]. ... the same in Float>>absPrintInexactlyOn: aStream base: base ... self isInfinite ifTrue: [aStream nextPutAll: 'Float infinity'. ^ self]. ... Apparently the last two methods are never called when number is infinite. I remove the second checks and apparently nothing breaks (all number tests are still green). Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroon "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

1 1

Fwd: [GitHub] Deprecation Notice
by ducasse Jan. 22, 2020

Jan. 22, 2020

what will be the implication? > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [GitHub] Deprecation Notice > Date: 21 January 2020 at 21:03:28 CET > To: StÃ©phaneDucasse <stephane.ducasse(a)inria.fr> > > Hi @Ducasse, > > You recently used a password to access an endpoint through the GitHub API using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate basic authentication using password to this endpoint soon: > > https://api.github.com/repositories/169849137 <https://api.github.com/repositories/169849137> > > We recommend using a personal access token (PAT) with the appropriate scope to access this endpoint instead. Visit https://github.com/settings/tokens <https://github.com/settings/tokens> for more information. > > Thanks, > The GitHub Team

6 9