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

Re: [Pharo-dev] Fed up

by Ronie Salgado

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. 2) the lack of inline caches for #perform: (again, I am just guessing in this case). 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 > > > > >

Jan. 22, 2020

Re: [Pharo-dev] Processor>>activeProcess is wrong when a process is stepped by a forked process

by Denis Kudriashov

Hi Thomas. I think the problem is with concurrent code in your test. I do not see what wrong is going on but test passes when full stepping loop is extracted into single process: s := Semaphore new. done := false. "Create debugged process" debuggedProcess := [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. debuggedProcess == p Ð²Ñ, 21 ÑÐ½Ð². 2020 Ð³. Ð² 15:19, Thomas Dupriez <tdupriez(a)ens-paris-saclay.fr>: > 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 > [image: 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 > [image: 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 > [image: 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* > [image: 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 *[image: a] > > >

Jan. 21, 2020

Re: [Pharo-dev] Fwd: [GitHub] Deprecation Notice

by Gabriel Cotelli

You can create a personal access token and use it instead of the password. For example when setting the iceberg credentials. So, I think there's no problem per se. On Tue, Jan 21, 2020, 17:06 ducasse <stepharo(a)netcourrier.com> wrote: > 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 > > We recommend using a personal access token (PAT) with the appropriate > scope to access this endpoint instead. Visit > https://github.com/settings/tokens for more information. > > Thanks, > The GitHub Team > > > >

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Sven Van Caekenberghe

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 >

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Esteban Maringolo

I also like the polymorphism of the #value: message, not only with Symbols but also with MADescriptions and many other uses. If that feds you up, and others too, maybe that "convention" (to use blocks only) might be scoped to Pharo core (whatever that is) methods. Regards, El mar., 21 de enero de 2020 19:35, Sean P. DeNigris <sean(a)clipperadams.com> escribiÃ³: > 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 > >

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Sean P. DeNigris

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

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Aliaksei Syrel

Hi Indeed, iterating over a collection using symbols is somewhat ~20% slower :) Here are some numbers: aCol := (1 to: 100000000). > [ 10 timesRepeat: [ aCol *do: #yourself* ] ] timeToRunWithoutGC / 10.0. > *"1110.8"* > [ 10 timesRepeat: [ aCol *do: [ :each | each yourself ]* ] ] > timeToRunWithoutGC / 10.0. *"898.1"*. > (1110.8 - 898.1) / 1110.8 * 100 "*19.14836154123154*" Cheers, Alex On Tue, 21 Jan 2020 at 21:11, ducasse <stepharo(a)netcourrier.com> wrote: > 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. > > > >

Jan. 21, 2020

Re: [Pharo-dev] Short Survey about automatic deprecation rewrites

by ducasse

Thanks! Martin milton juraj should do it too :) S. > On 21 Jan 2020, at 21:34, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > From: Alexandre Bergel <alexandre.bergel(a)me.com> > Subject: Re: [Pharo-dev] Short Survey about automatic deprecation rewrites > Date: 21 January 2020 at 21:34:58 CET > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Just answered! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On 21-01-2020, at 13:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> 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 >> >> Thanks a lot! >> Guille, in behalf of the Pharo consortium > > > >

Jan. 21, 2020

Re: [Pharo-dev] Short Survey about automatic deprecation rewrites

by Alexandre Bergel

Just answered! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On 21-01-2020, at 13:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > 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 > > Thanks a lot! > Guille, in behalf of the Pharo consortium

Jan. 21, 2020

Fed up

by ducasse

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.

Jan. 21, 2020