- Pharo-dev - lists.pharo.org

[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

Processor>>activeProcess is wrong when a process is stepped by a forked process
by Thomas Dupriez Jan. 21, 2020

Jan. 21, 2020

Hello Some time ago, I've stumbled upon a challenging bug in pharo. I tried some things, but this bug still eludes me. Maybe someone here has an idea? The bug is that the value of `Processor activeProcess` is wrong inside a process being stepped by a forked process. In other words, let's say process D is the (frozen) process I am debugging, and its code is to store the active process into some variable with `p := Processor activeProcess`: - If I step process D normally (with `D step`), then p is correct and worth process D - If I fork to create a process F that steps process D, then p is incorrect and worth process F You will find below the code of the two tests I am using to show the bug, as well as a condensed version of my findings so far. If you have any idea or lead as to where this bug could come from, I would be very grateful. Thomas Dupriez ----- Here is the code of the failing test, where process F steps process D: ``` /testActiveProcessInProcessSteppedInForkedProcess// //| s p D done |// //Â Â Â s := Semaphore new. done := false.// //Â Â Â "Create debugged process"// //Â Â Â D := [p := Processor activeProcess. done := true] newProcess name: 'D'; yourself.// //Â Â Â "Until the execution of the debugged process is over, create a forked process to step it"// //Â Â Â [done]// //Â Â Â Â Â Â whileFalse: [ // //Â Â Â Â Â Â Â Â Â [debuggedProcess step. s signal] forkNamed: 'F'.// //Â Â Â Â Â Â Â Â Â s wait.// //Â Â Â Â Â Â ].// //Â Â Â self assert: D identicalTo: p/ ``` And here is the passing test, where we step process D directly: ``` /testActiveProcessInProcessDirectlyStepped// //| s p D done |// //Â Â Â s := Semaphore new. done := false.// //Â Â Â "Create debugged process"// //Â Â Â D := [p := Processor activeProcess. done := true] newProcess name: 'D'; yourself.// //Â Â Â "Until the execution of the debugged process is over, step it directly"// //Â Â Â [done]// //Â Â Â Â Â Â whileFalse: [ // //Â Â Â Â Â Â Â Â Â debuggedProcess step.// //Â Â Â Â Â Â ].// //Â Â Â self assert: D identicalTo: p/ ``` ----- Here are my findings so far: The call chain of Process>>step is: - Process>>step - which calls Process>>evaluate:onBehalfOf: - which calls BlockClosure>>ensure: - which calls BlockClosure>>valueNoContextSwitch 1) Replacing the call to BlockClosure>>valueNoContextSwitch with a call to BlockClosure>>value does not affect the results of the test 2) Since #valueNoContextSwitch is a primitive, it cannot be instrumented easily. I instrumented right before and after it gets called in the code of BlockClosure>>ensure to check the value of active process. No wrong value there, so the problem appears inside the execution of #valueNoContextSwitch, and it disappears before this method call returns. 3) The block being evaluated by #valueNoContextSwitch contains a call to Context>>step, which ultimately calls InstructionStream>>interpretNextV3PlusClosureInstructionFor: (the method that read what the next bytecode is and applies it to the execution it is stepping. I instrumented this method to log the name of the active process, and the context being stepped during the execution of both tests. The log show a difference between the passing and failing test: - Passing test: the active process is D for a long time, then 'Test execution watch dog" for a bit, and finally, it is "Morphic UI Process". So everything looks in order: the active process is D until the test ends and the UI process takes control back - Failing test: The logged active process alternates between F and D, and looks like this: (I put some F D patterns in bold for readability) *F D* F D *F D*.....*F D* F F D F F *F D* F D *F D*...*F D* D D D D r M M M M... "M" is the morphic UI Process, "r" is a seemingly random process whose name is "1006977792" in the log. I also logged the ast nodes being stepped, but I don't really know how to exploit it. 4) I did some experiments by tweaking the tests and changing which process creates D, which process steps F...and had surprising results: 4-1) Original failing test a In the original failing test, the test process creates the debugged process and a fork, and the fork steps the debugged process (blue arrow). This test fails. 4-2) Original passing test a In the original passing test, the test process creates the debugged process and steps it. This test passes. 4-3) Forked process creates AND steps the debugged process a If the forked process is the one to create the debugged process, the test passes! 4-4) /Forked process creates the debugged process, and TestProcess steps it/ a So maybe the test passes whenever the debugged process is a descendant of the process stepping it? No, 4-5) shows that it is not necessary. 4-5) /A forked process creates the debugged process. Another forked process steps the debugged process /a

2 1

Short Survey about automatic deprecation rewrites
by Guillermo Polito Jan. 21, 2020

Jan. 21, 2020

Hi all, We would like to share with you a short survey about the automatic deprecation rewrites that have been around since Pharo 6. It will be super useful for us to enhance the support for migrations. We estimate it will take ~< 3 minutes to fill. This survey is aimed at people both *using* Pharo, or writing libraries and frameworks for Pharo. If youâre a library/framework maintainer and you know people using your library, would you mind share it with them? Link to the survey: https://sondages.inria.fr/index.php/133442?lang=en <https://sondages.inria.fr/index.php/133442?lang=en> Thanks a lot! Guille, in behalf of the Pharo consortium

4 3