- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Playground and text evaluation printing result default.

by stepharo

Le 5/6/16 Ã 23:00, Tudor Girba a Ã©crit : > Hi Stef, > > The quotes appear only when you add the result in the playground. No need to explain I'm not idiot and I know it. > The typical use case for this is to keep track of several results. No need to explain I'm not idiot and I know it. > In this situation you do not want to modify the code to not affect the highlighting and this is why it gets in a comment. This is fun because I never ever needed it. But this is probably what everybody else is doing that since this is the default. I just write simple code and tests. Indeed I'm not that smart. But your tools only embedd your scenario and let the other users forced to adapt. Well you do not want but I do. I spent my evening removing quotes while writing tests. What I hate with the GTTools is that you want to teach me how I should work. Sorry but good tools do not do that. Good tools empower the users and not constraint them. I work a lot faster when I do not have to remove the wonderful comments or when I have to copy and paste. This commenting is breaking the flow of efficient people. May be GT team do not work write tests in the debugger but I do most of the time and I'm forced by the environment to remove quotes all over the places. > If you want to copy the content without quotes, you can do: > Cmd+p -> popup > Cmd+c -> selects the current line and copies the text > Esc > Cmd+v Sorry but I do not want. I just want to print and modify directly. 7 keystrokes vs 2 > Perhaps we can add another keybinding like Shift+Enter for adding the text without quotes. And why not the inverse. By default printing is printing and if you want to do something else then you have a special binding. Now I'm upset with this general attitude (Oh I will teach how you can be a nice user) that I will turn them off or go and hack my own settings. Still I'm amazingly sad about this state of affair. All these story about GT is hurting me because of this attitude: we are so smart and we thought a lot and we will teach you how you should work... and at the end I the end-user has to adapt. Look at the Spotter discussions: you looked for the graal and I was just telling to you that I cannot find simple information such as class refs! So what saddens me the most is that - you pretend to have end-user trying your tools but I have impression that they are not real power users or this is yourself and it means that you are never exposed to other people. I can still not use Spotter because the way I put my hand on my keyboard. So should change - 1 my hands - 2 my brain - 3 my keyboard - 4 do not use the tools? - funnily enough if I would not have complain aggressively then it looks like we would have the same than before. Your flow is not mine and I go faster my way but your tools force me to get slow. I do not have the time to produce a video but I would even if it would give a bad press to Pharo. I will do a presentation in the rmod team. Because people do not watch themselves why acting. Good tools empower the users not constraint them. GTTools feel often like an overengineer guitar that would have hampered Jimmy Hendrix to do crazy solos. > > Cheers, > Doru > > > >> On Jun 5, 2016, at 10:20 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> I would like to know if there is a setting to remove the "" when printing the result of an expression. >> >> I know that playground has been thought to help me, but today I watched myself removing the comments >> >> code so often that I would like to get a setting because such wrapping of results is really boring for me. >> >> I'm spending my time removing them and I start to wonder why they are any useful. >> >> I would help me to write fast tests for example in the debugger. >> >> Stef >> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > > >

June 7, 2016

Re: [Pharo-dev] atomicity of non-local returns

by ClÃ©ment Bera

On Tue, Jun 7, 2016 at 1:55 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, Jun 7, 2016 at 2:39 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Yeah anyway the non local return happens after the ensure: send, so > nothing > > to worry about. > > > > In your analysis, you need to see that the #returnTop bytecode means NLR > in > > a block but method return in a method. Even if it looks the same, in one > > case the #returnTop belongs to a block closure bytecode, hence is a NLR, > > whereas in the othercase, it belongs to the method bytecode, hence it's a > > method return. > > > > See StackInterpreter>>commonReturn, this code: > > > > "If this is a method simply return to the sender/caller." > > (self iframeIsBlockActivation: localFP) ifFalse: > > [^self commonCallerReturn]. > > > > Ahhh, got it. Quite a subtle semantic when the source code looks much the > same. > > > > test if the return top is a method return or block NLR. I don't know why > > Eliot decided to share the bytecode between method return and block NLR, > but > > there are 3 returns in Smalltalk, method return, block return and block > NLR > > and they're all quite different. > > > > About your example, the normal closure bytecode creates the closure, > pushes > > it on top of the stack, then skips over the closure bytecode (jump > forward). > > About the jump instructions generated by ifTrue:ifFalse:, the jump > forward > > instruction has no interrupt point, while the conditional jump have an > > interrupt point only in the case of a must be boolean. Does this make > sense > > ? > > Just to confirm in my own words... > the jumpFalse: > * sent to a boolean has no interrupt point > * sent to a non-boolean has an interrupt point > yes. > > In Squeak there's indentation in bytecode printing to ease control flow > > understanding, that may help you. You are using a Squeak image for VM > > simulation and Pharo image to implement the primitives and experiment > with > > the primitives, aren't you ? > > The purpose of the primitives is for Pharo, but right this moment I'm > using Squeak for both the simulator and the image being simulated (my > changeset only needed a few changes to split Context back to its > earlier components). While learning the simulator it was the path of > least resistance using the supplied scripts to build the reader image, > and I hadn't swapped to simulating a Pharo image yet. > cheers -ben > > > > > Cheers > > > > On Mon, Jun 6, 2016 at 6:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> On Mon, Jun 6, 2016 at 9:34 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > >> wrote: > >> > Hi Ben, > >> > > >> > Firstly be careful because atomic usually means that the thread cannot > >> > be > >> > interrupted by a concurrent native thread, so an atomic operation has > to > >> > be > >> > guaranteed at processor level. > >> > > >> > Assuming that by atomic you mean that the operation's process cannot > be > >> > preempted by another green thread, yes there is big problems with non > >> > local > >> > returns. > >> > >> Yes, I meant at the image level, run by the single-thread VM. > >> > >> > > >> > Two main issues: > >> > - NLR can trigger unwind blocks, which can switch to another process. > >> > - NLR can fail, triggering the cannotReturn: call-back, which can > switch > >> > to > >> > another process. > >> > >> These would presumably could only occur after the #ensure: had been > >> invoked? . > >> > >> > > >> > I understand generally that an inlined #ifTrue is atomic. For > >> > example, here after the primitive returns, no interruption can occur > >> > before the #ensure is invoked... > >> > self primitiveWaitAcquire ifTrue: > >> > [mutuallyExclusiveBlock ensure: [self release]]. > >> > > >> > The exact answer is that #ifTrue: can be interrupted if self > >> > primitiveWaitAcquire is not a boolean, and can't be interrupted if > it's > >> > a > >> > boolean. It's nice to mark in a comment if part of the method's code > has > >> > not > >> > to be interrupted to avoid issues years later. > >> > >> Good tip. > >> > >> > > >> > But I want to know whether a non-local return could have an impact on > >> > that atomicity. For example ... > >> > self primitiveWaitAcquire ifTrue: > >> > [ ^ mutuallyExclusiveBlock ensure: [self release]] > >> > > >> > In your code there is no non local return because ifTrue: is inlined > by > >> > the > >> > Bytecode compiler. > >> > >> I'm not clear on your meaning. If there were additional code > >> following those two lines, then they would not be executed, so it > >> would still be a NLR ? I took my understanding from [1]. And in the > >> bytecode below it seems #returnTop is associated with the NLRs - so > >> the NLR is still there(?), but having looked at the bytecode I can now > >> see it has no impact, I think either with or without inlining makes no > >> difference wrt NLR. > >> > >> > >> [1] > >> > https://silversmalltalk.wordpress.com/2011/02/02/implementing-smalltalks-no… > >> > >> > Try to compile it and look at the bytecode you will see. > >> > >> Good idea. So I share a little analysis... > >> > >> > >> The bytecode for these two lines is identical, > >> a blah: [ [ self foo ] ensure: [ self bar ] ] > >> a blah: [ ^ [ self foo ] ensure: [ self bar ] ] > >> except for bytecode 49, respectively... > >> "49 <7D> blockReturn" > >> "49 <7C> returnTop" > >> > >> "29 <10> pushTemp: 0" > >> "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" > >> "34 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 38 to 40" > >> "38 <70> self" > >> "39 <D0> send: foo" > >> "40 <7D> blockReturn" > >> "41 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 45 to 47" > >> "45 <70> self" > >> "46 <D1> send: bar" > >> "47 <7D> blockReturn" > >> "48 <E2> send: ensure:" > >> "49 <7C> returnTop" > >> "50 <E3> send: blah:" > >> "51 <87> pop" > >> "52 <78> returnSelf" > >> > >> > >> Changing #blah: to #ifTrue: these two lines > >> a ifTrue: [ [ self foo ] ensure: [ self bar ] ] > >> a ifTrue: [ ^ [ self foo ] ensure: [ self bar ] ] > >> are the same except for bytecode 49, respectively... > >> "47 <87> pop" > >> "47 <7C> returnTop" > >> > >> "29 <10> pushTemp: 0" > >> "30 <AC 10> jumpFalse: 48" > >> "32 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 36 to 38" > >> "36 <70> self" > >> "37 <D0> send: foo" > >> "38 <7D> blockReturn" > >> "39 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 43 to 45" > >> "43 <70> self" > >> "44 <D1> send: bar" > >> "45 <7D> blockReturn" > >> "46 <E2> send: ensure:" > >> "47 <87> pop" > >> "48 <78> returnSelf" > >> > >> And between #blah: and #ifTrue: the difference is > >> removal of... > >> "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" > >> "49 <7D> blockReturn" > >> "50 <E3> send: blah:" > >> and replaced them with... > >> "30 <AC 10> jumpFalse: 48" > >> > >> It took me a while to guess how to follow the execution path. I had > >> assumed it would just go top to bottom, but that didn't make sense for > >> foo to be executed before blah. Can you confirm.. I guess the trick > >> (for #blah) is... > >> > >> 1. At 29, push the temp > >> 2. skip the closureNumCopied bytes 34 to 49, > >> 3. At 50, send #blah. > >> 4. next is bytecode 34 skips bytecodes 38 to 40, > >> 5. and bytecode 41 skips bytecodes 45 to 47 > >> 6. At 48 send #ensure:. > >> > >> versus #ifTrue: bytecocde... > >> > >> 1. At 29, push the temp > >> 2. skip closureNumCopied bytes 36 to 38" > >> 3. skip closureNumCopied: bytes 43 to 45" > >> 4. At 46, send #ensure: > >> > >> So its clear (IIUC) that with #IfTrue: the #ensure is the first send: > >> after the push temp, but the non-inlined #blah: is an extra send > >> between which could be interrupted and prevent the #ensure from being > >> executed. > >> > >> > > >> > Else as I said at the beginning of the mail, a non local return can > >> > imply a > >> > process switch if that was your question. > >> > >> Yes, but a process switch is okay after the send of #ensure: > >> just not before. > >> > >> thx. cheers -ben > >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Mon, Jun 6, 2016 at 2:46 PM, Ben Coman <btc(a)openinworld.com> > wrote: > >> >> > >> >> I understand generally that an inlined #ifTrue is atomic. For > >> >> example, here after the primitive returns, no interruption can occur > >> >> before the #ensure is invoked... > >> >> self primitiveWaitAcquire ifTrue: > >> >> [mutuallyExclusiveBlock ensure: [self release]]. > >> >> > >> >> But I want to know whether a non-local return could have an impact on > >> >> that atomicity. For example ... > >> >> self primitiveWaitAcquire ifTrue: > >> >> [ ^ mutuallyExclusiveBlock ensure: [self release]] > >> >> > >> >> cheers -ben > >> >> > >> > > >> > > > >

June 7, 2016

Re: [Pharo-dev] atomicity of non-local returns

by Ben Coman

On Tue, Jun 7, 2016 at 2:39 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Yeah anyway the non local return happens after the ensure: send, so nothing > to worry about. > > In your analysis, you need to see that the #returnTop bytecode means NLR in > a block but method return in a method. Even if it looks the same, in one > case the #returnTop belongs to a block closure bytecode, hence is a NLR, > whereas in the othercase, it belongs to the method bytecode, hence it's a > method return. > > See StackInterpreter>>commonReturn, this code: > > "If this is a method simply return to the sender/caller." > (self iframeIsBlockActivation: localFP) ifFalse: > [^self commonCallerReturn]. > Ahhh, got it. Quite a subtle semantic when the source code looks much the same. > test if the return top is a method return or block NLR. I don't know why > Eliot decided to share the bytecode between method return and block NLR, but > there are 3 returns in Smalltalk, method return, block return and block NLR > and they're all quite different. > > About your example, the normal closure bytecode creates the closure, pushes > it on top of the stack, then skips over the closure bytecode (jump forward). > About the jump instructions generated by ifTrue:ifFalse:, the jump forward > instruction has no interrupt point, while the conditional jump have an > interrupt point only in the case of a must be boolean. Does this make sense > ? Just to confirm in my own words... the jumpFalse: * sent to a boolean has no interrupt point * sent to a non-boolean has an interrupt point In Squeak there's indentation in bytecode printing to ease control flow > understanding, that may help you. You are using a Squeak image for VM > simulation and Pharo image to implement the primitives and experiment with > the primitives, aren't you ? The purpose of the primitives is for Pharo, but right this moment I'm using Squeak for both the simulator and the image being simulated (my changeset only needed a few changes to split Context back to its earlier components). While learning the simulator it was the path of least resistance using the supplied scripts to build the reader image, and I hadn't swapped to simulating a Pharo image yet. cheers -ben > > Cheers > > On Mon, Jun 6, 2016 at 6:34 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Mon, Jun 6, 2016 at 9:34 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> > Hi Ben, >> > >> > Firstly be careful because atomic usually means that the thread cannot >> > be >> > interrupted by a concurrent native thread, so an atomic operation has to >> > be >> > guaranteed at processor level. >> > >> > Assuming that by atomic you mean that the operation's process cannot be >> > preempted by another green thread, yes there is big problems with non >> > local >> > returns. >> >> Yes, I meant at the image level, run by the single-thread VM. >> >> > >> > Two main issues: >> > - NLR can trigger unwind blocks, which can switch to another process. >> > - NLR can fail, triggering the cannotReturn: call-back, which can switch >> > to >> > another process. >> >> These would presumably could only occur after the #ensure: had been >> invoked? . >> >> > >> > I understand generally that an inlined #ifTrue is atomic. For >> > example, here after the primitive returns, no interruption can occur >> > before the #ensure is invoked... >> > self primitiveWaitAcquire ifTrue: >> > [mutuallyExclusiveBlock ensure: [self release]]. >> > >> > The exact answer is that #ifTrue: can be interrupted if self >> > primitiveWaitAcquire is not a boolean, and can't be interrupted if it's >> > a >> > boolean. It's nice to mark in a comment if part of the method's code has >> > not >> > to be interrupted to avoid issues years later. >> >> Good tip. >> >> > >> > But I want to know whether a non-local return could have an impact on >> > that atomicity. For example ... >> > self primitiveWaitAcquire ifTrue: >> > [ ^ mutuallyExclusiveBlock ensure: [self release]] >> > >> > In your code there is no non local return because ifTrue: is inlined by >> > the >> > Bytecode compiler. >> >> I'm not clear on your meaning. If there were additional code >> following those two lines, then they would not be executed, so it >> would still be a NLR ? I took my understanding from [1]. And in the >> bytecode below it seems #returnTop is associated with the NLRs - so >> the NLR is still there(?), but having looked at the bytecode I can now >> see it has no impact, I think either with or without inlining makes no >> difference wrt NLR. >> >> >> [1] >> https://silversmalltalk.wordpress.com/2011/02/02/implementing-smalltalks-no… >> >> > Try to compile it and look at the bytecode you will see. >> >> Good idea. So I share a little analysis... >> >> >> The bytecode for these two lines is identical, >> a blah: [ [ self foo ] ensure: [ self bar ] ] >> a blah: [ ^ [ self foo ] ensure: [ self bar ] ] >> except for bytecode 49, respectively... >> "49 <7D> blockReturn" >> "49 <7C> returnTop" >> >> "29 <10> pushTemp: 0" >> "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" >> "34 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 38 to 40" >> "38 <70> self" >> "39 <D0> send: foo" >> "40 <7D> blockReturn" >> "41 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 45 to 47" >> "45 <70> self" >> "46 <D1> send: bar" >> "47 <7D> blockReturn" >> "48 <E2> send: ensure:" >> "49 <7C> returnTop" >> "50 <E3> send: blah:" >> "51 <87> pop" >> "52 <78> returnSelf" >> >> >> Changing #blah: to #ifTrue: these two lines >> a ifTrue: [ [ self foo ] ensure: [ self bar ] ] >> a ifTrue: [ ^ [ self foo ] ensure: [ self bar ] ] >> are the same except for bytecode 49, respectively... >> "47 <87> pop" >> "47 <7C> returnTop" >> >> "29 <10> pushTemp: 0" >> "30 <AC 10> jumpFalse: 48" >> "32 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 36 to 38" >> "36 <70> self" >> "37 <D0> send: foo" >> "38 <7D> blockReturn" >> "39 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 43 to 45" >> "43 <70> self" >> "44 <D1> send: bar" >> "45 <7D> blockReturn" >> "46 <E2> send: ensure:" >> "47 <87> pop" >> "48 <78> returnSelf" >> >> And between #blah: and #ifTrue: the difference is >> removal of... >> "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" >> "49 <7D> blockReturn" >> "50 <E3> send: blah:" >> and replaced them with... >> "30 <AC 10> jumpFalse: 48" >> >> It took me a while to guess how to follow the execution path. I had >> assumed it would just go top to bottom, but that didn't make sense for >> foo to be executed before blah. Can you confirm.. I guess the trick >> (for #blah) is... >> >> 1. At 29, push the temp >> 2. skip the closureNumCopied bytes 34 to 49, >> 3. At 50, send #blah. >> 4. next is bytecode 34 skips bytecodes 38 to 40, >> 5. and bytecode 41 skips bytecodes 45 to 47 >> 6. At 48 send #ensure:. >> >> versus #ifTrue: bytecocde... >> >> 1. At 29, push the temp >> 2. skip closureNumCopied bytes 36 to 38" >> 3. skip closureNumCopied: bytes 43 to 45" >> 4. At 46, send #ensure: >> >> So its clear (IIUC) that with #IfTrue: the #ensure is the first send: >> after the push temp, but the non-inlined #blah: is an extra send >> between which could be interrupted and prevent the #ensure from being >> executed. >> >> > >> > Else as I said at the beginning of the mail, a non local return can >> > imply a >> > process switch if that was your question. >> >> Yes, but a process switch is okay after the send of #ensure: >> just not before. >> >> thx. cheers -ben >> >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Jun 6, 2016 at 2:46 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> I understand generally that an inlined #ifTrue is atomic. For >> >> example, here after the primitive returns, no interruption can occur >> >> before the #ensure is invoked... >> >> self primitiveWaitAcquire ifTrue: >> >> [mutuallyExclusiveBlock ensure: [self release]]. >> >> >> >> But I want to know whether a non-local return could have an impact on >> >> that atomicity. For example ... >> >> self primitiveWaitAcquire ifTrue: >> >> [ ^ mutuallyExclusiveBlock ensure: [self release]] >> >> >> >> cheers -ben >> >> >> > >> >

June 6, 2016

Privacy sendDiagnosticsAndUsageData should be ternary, not binary

by Peter Uhnak

Hi, Privacy>>sendDiagnosticsAndUsageData should be ternary, not binary. Because right now if I refuse sending the data I will be asked again every single time. So the proper behavior (imho) should be: ask Privacy for the settingâ¦ if the setting is not defined, then show a popup. If the setting is defined then respect it and do not show another popup. Also it would be nice to know what happens with the data. I mean my projects are open source so "sendSourceCode" shouldn't be an issueâ¦ but what you can possibly learn from it? Why not just analyze the content of SmalltalkHub/GitHub? Peter

June 6, 2016

Re: [Pharo-dev] [Ann] ObjectStatistics

by phil＠highoctane.be

Nice thing! On Mon, Jun 6, 2016 at 4:56 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > And you can load it by > > Gofer it smalltalkhubUser: 'Pharo' project: 'ObjectStatistics'; > configuration; loadStable > > And play with examples on ObjectStatistics class side > > 2016-06-06 16:53 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hello. >> >> I just publish new tool ObjectStatistics to analyze objects set. >> I first created it to analyze network communication during remote >> debugging. And then I realize how general it could be. >> Now it is ready to use package. It could be good foundation to improve >> and simplify our profiler tools. >> >> You can see details and examples on my blog >> http://dionisiydk.blogspot.fr/2016/06/objectstatistics-simple-objects.html >> . >> >> Here is little abstract: >> ObjectStatistics tool to analyse set of objects by computing different >> kind of metrics and look at them from different angles. It implements >> simplistic OLAP Cube approach for data analysis but in objects space. >> Imaging that we have collection of message sends and we want to know >> number of message sends in dimension of receiver, receiver class and >> message selector. We have different angles to look at this data: from >> receiver class to selector and receiver or from selector to receiver class >> and receiver or any other combination. >> We also could analyze different kind of metrics which could be computed >> on given objects. It could be number of unique receivers, execution time, >> executed lines of code, etc. >> This package implements computation of object statistics over declared >> metrics and dimensions space. >> >> Best regards, >> Denis >> > >

June 6, 2016

Re: [Pharo-dev] atomicity of non-local returns

by ClÃ©ment Bera

Yeah anyway the non local return happens after the ensure: send, so nothing to worry about. In your analysis, you need to see that the #returnTop bytecode means NLR in a block but method return in a method. Even if it looks the same, in one case the #returnTop belongs to a block closure bytecode, hence is a NLR, whereas in the othercase, it belongs to the method bytecode, hence it's a method return. See StackInterpreter>>commonReturn, this code: "If this is a method simply return to the sender/caller." (self iframeIsBlockActivation: localFP) ifFalse: [^self commonCallerReturn]. test if the return top is a method return or block NLR. I don't know why Eliot decided to share the bytecode between method return and block NLR, but there are 3 returns in Smalltalk, method return, block return and block NLR and they're all quite different. About your example, the normal closure bytecode creates the closure, pushes it on top of the stack, then skips over the closure bytecode (jump forward). About the jump instructions generated by ifTrue:ifFalse:, the jump forward instruction has no interrupt point, while the conditional jump have an interrupt point only in the case of a must be boolean. Does this make sense ? In Squeak there's indentation in bytecode printing to ease control flow understanding, that may help you. You are using a Squeak image for VM simulation and Pharo image to implement the primitives and experiment with the primitives, aren't you ? Cheers On Mon, Jun 6, 2016 at 6:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Jun 6, 2016 at 9:34 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Hi Ben, > > > > Firstly be careful because atomic usually means that the thread cannot be > > interrupted by a concurrent native thread, so an atomic operation has to > be > > guaranteed at processor level. > > > > Assuming that by atomic you mean that the operation's process cannot be > > preempted by another green thread, yes there is big problems with non > local > > returns. > > Yes, I meant at the image level, run by the single-thread VM. > > > > > Two main issues: > > - NLR can trigger unwind blocks, which can switch to another process. > > - NLR can fail, triggering the cannotReturn: call-back, which can switch > to > > another process. > > These would presumably could only occur after the #ensure: had been > invoked? . > > > > > I understand generally that an inlined #ifTrue is atomic. For > > example, here after the primitive returns, no interruption can occur > > before the #ensure is invoked... > > self primitiveWaitAcquire ifTrue: > > [mutuallyExclusiveBlock ensure: [self release]]. > > > > The exact answer is that #ifTrue: can be interrupted if self > > primitiveWaitAcquire is not a boolean, and can't be interrupted if it's a > > boolean. It's nice to mark in a comment if part of the method's code has > not > > to be interrupted to avoid issues years later. > > Good tip. > > > > > But I want to know whether a non-local return could have an impact on > > that atomicity. For example ... > > self primitiveWaitAcquire ifTrue: > > [ ^ mutuallyExclusiveBlock ensure: [self release]] > > > > In your code there is no non local return because ifTrue: is inlined by > the > > Bytecode compiler. > > I'm not clear on your meaning. If there were additional code > following those two lines, then they would not be executed, so it > would still be a NLR ? I took my understanding from [1]. And in the > bytecode below it seems #returnTop is associated with the NLRs - so > the NLR is still there(?), but having looked at the bytecode I can now > see it has no impact, I think either with or without inlining makes no > difference wrt NLR. > > > [1] > https://silversmalltalk.wordpress.com/2011/02/02/implementing-smalltalks-no… > > > Try to compile it and look at the bytecode you will see. > > Good idea. So I share a little analysis... > > > The bytecode for these two lines is identical, > a blah: [ [ self foo ] ensure: [ self bar ] ] > a blah: [ ^ [ self foo ] ensure: [ self bar ] ] > except for bytecode 49, respectively... > "49 <7D> blockReturn" > "49 <7C> returnTop" > > "29 <10> pushTemp: 0" > "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" > "34 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 38 to 40" > "38 <70> self" > "39 <D0> send: foo" > "40 <7D> blockReturn" > "41 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 45 to 47" > "45 <70> self" > "46 <D1> send: bar" > "47 <7D> blockReturn" > "48 <E2> send: ensure:" > "49 <7C> returnTop" > "50 <E3> send: blah:" > "51 <87> pop" > "52 <78> returnSelf" > > > Changing #blah: to #ifTrue: these two lines > a ifTrue: [ [ self foo ] ensure: [ self bar ] ] > a ifTrue: [ ^ [ self foo ] ensure: [ self bar ] ] > are the same except for bytecode 49, respectively... > "47 <87> pop" > "47 <7C> returnTop" > > "29 <10> pushTemp: 0" > "30 <AC 10> jumpFalse: 48" > "32 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 36 to 38" > "36 <70> self" > "37 <D0> send: foo" > "38 <7D> blockReturn" > "39 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 43 to 45" > "43 <70> self" > "44 <D1> send: bar" > "45 <7D> blockReturn" > "46 <E2> send: ensure:" > "47 <87> pop" > "48 <78> returnSelf" > > And between #blah: and #ifTrue: the difference is > removal of... > "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" > "49 <7D> blockReturn" > "50 <E3> send: blah:" > and replaced them with... > "30 <AC 10> jumpFalse: 48" > > It took me a while to guess how to follow the execution path. I had > assumed it would just go top to bottom, but that didn't make sense for > foo to be executed before blah. Can you confirm.. I guess the trick > (for #blah) is... > > 1. At 29, push the temp > 2. skip the closureNumCopied bytes 34 to 49, > 3. At 50, send #blah. > 4. next is bytecode 34 skips bytecodes 38 to 40, > 5. and bytecode 41 skips bytecodes 45 to 47 > 6. At 48 send #ensure:. > > versus #ifTrue: bytecocde... > > 1. At 29, push the temp > 2. skip closureNumCopied bytes 36 to 38" > 3. skip closureNumCopied: bytes 43 to 45" > 4. At 46, send #ensure: > > So its clear (IIUC) that with #IfTrue: the #ensure is the first send: > after the push temp, but the non-inlined #blah: is an extra send > between which could be interrupted and prevent the #ensure from being > executed. > > > > > Else as I said at the beginning of the mail, a non local return can > imply a > > process switch if that was your question. > > Yes, but a process switch is okay after the send of #ensure: > just not before. > > thx. cheers -ben > > > > > > > > > > > > > > > > > On Mon, Jun 6, 2016 at 2:46 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> I understand generally that an inlined #ifTrue is atomic. For > >> example, here after the primitive returns, no interruption can occur > >> before the #ensure is invoked... > >> self primitiveWaitAcquire ifTrue: > >> [mutuallyExclusiveBlock ensure: [self release]]. > >> > >> But I want to know whether a non-local return could have an impact on > >> that atomicity. For example ... > >> self primitiveWaitAcquire ifTrue: > >> [ ^ mutuallyExclusiveBlock ensure: [self release]] > >> > >> cheers -ben > >> > > > >

June 6, 2016

Re: [Pharo-dev] atomicity of non-local returns

by Ben Coman

On Mon, Jun 6, 2016 at 9:34 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi Ben, > > Firstly be careful because atomic usually means that the thread cannot be > interrupted by a concurrent native thread, so an atomic operation has to be > guaranteed at processor level. > > Assuming that by atomic you mean that the operation's process cannot be > preempted by another green thread, yes there is big problems with non local > returns. Yes, I meant at the image level, run by the single-thread VM. > > Two main issues: > - NLR can trigger unwind blocks, which can switch to another process. > - NLR can fail, triggering the cannotReturn: call-back, which can switch to > another process. These would presumably could only occur after the #ensure: had been invoked? . > > I understand generally that an inlined #ifTrue is atomic. For > example, here after the primitive returns, no interruption can occur > before the #ensure is invoked... > self primitiveWaitAcquire ifTrue: > [mutuallyExclusiveBlock ensure: [self release]]. > > The exact answer is that #ifTrue: can be interrupted if self > primitiveWaitAcquire is not a boolean, and can't be interrupted if it's a > boolean. It's nice to mark in a comment if part of the method's code has not > to be interrupted to avoid issues years later. Good tip. > > But I want to know whether a non-local return could have an impact on > that atomicity. For example ... > self primitiveWaitAcquire ifTrue: > [ ^ mutuallyExclusiveBlock ensure: [self release]] > > In your code there is no non local return because ifTrue: is inlined by the > Bytecode compiler. I'm not clear on your meaning. If there were additional code following those two lines, then they would not be executed, so it would still be a NLR ? I took my understanding from [1]. And in the bytecode below it seems #returnTop is associated with the NLRs - so the NLR is still there(?), but having looked at the bytecode I can now see it has no impact, I think either with or without inlining makes no difference wrt NLR. [1] https://silversmalltalk.wordpress.com/2011/02/02/implementing-smalltalks-no… > Try to compile it and look at the bytecode you will see. Good idea. So I share a little analysis... The bytecode for these two lines is identical, a blah: [ [ self foo ] ensure: [ self bar ] ] a blah: [ ^ [ self foo ] ensure: [ self bar ] ] except for bytecode 49, respectively... "49 <7D> blockReturn" "49 <7C> returnTop" "29 <10> pushTemp: 0" "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" "34 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 38 to 40" "38 <70> self" "39 <D0> send: foo" "40 <7D> blockReturn" "41 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 45 to 47" "45 <70> self" "46 <D1> send: bar" "47 <7D> blockReturn" "48 <E2> send: ensure:" "49 <7C> returnTop" "50 <E3> send: blah:" "51 <87> pop" "52 <78> returnSelf" Changing #blah: to #ifTrue: these two lines a ifTrue: [ [ self foo ] ensure: [ self bar ] ] a ifTrue: [ ^ [ self foo ] ensure: [ self bar ] ] are the same except for bytecode 49, respectively... "47 <87> pop" "47 <7C> returnTop" "29 <10> pushTemp: 0" "30 <AC 10> jumpFalse: 48" "32 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 36 to 38" "36 <70> self" "37 <D0> send: foo" "38 <7D> blockReturn" "39 <8F 00 00 03> closureNumCopied: 0 numArgs: 0 bytes 43 to 45" "43 <70> self" "44 <D1> send: bar" "45 <7D> blockReturn" "46 <E2> send: ensure:" "47 <87> pop" "48 <78> returnSelf" And between #blah: and #ifTrue: the difference is removal of... "30 <8F 00 00 10> closureNumCopied: 0 numArgs: 0 bytes 34 to 49" "49 <7D> blockReturn" "50 <E3> send: blah:" and replaced them with... "30 <AC 10> jumpFalse: 48" It took me a while to guess how to follow the execution path. I had assumed it would just go top to bottom, but that didn't make sense for foo to be executed before blah. Can you confirm.. I guess the trick (for #blah) is... 1. At 29, push the temp 2. skip the closureNumCopied bytes 34 to 49, 3. At 50, send #blah. 4. next is bytecode 34 skips bytecodes 38 to 40, 5. and bytecode 41 skips bytecodes 45 to 47 6. At 48 send #ensure:. versus #ifTrue: bytecocde... 1. At 29, push the temp 2. skip closureNumCopied bytes 36 to 38" 3. skip closureNumCopied: bytes 43 to 45" 4. At 46, send #ensure: So its clear (IIUC) that with #IfTrue: the #ensure is the first send: after the push temp, but the non-inlined #blah: is an extra send between which could be interrupted and prevent the #ensure from being executed. > > Else as I said at the beginning of the mail, a non local return can imply a > process switch if that was your question. Yes, but a process switch is okay after the send of #ensure: just not before. thx. cheers -ben > > > > > > > > On Mon, Jun 6, 2016 at 2:46 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> I understand generally that an inlined #ifTrue is atomic. For >> example, here after the primitive returns, no interruption can occur >> before the #ensure is invoked... >> self primitiveWaitAcquire ifTrue: >> [mutuallyExclusiveBlock ensure: [self release]]. >> >> But I want to know whether a non-local return could have an impact on >> that atomicity. For example ... >> self primitiveWaitAcquire ifTrue: >> [ ^ mutuallyExclusiveBlock ensure: [self release]] >> >> cheers -ben >> >

June 6, 2016

Re: [Pharo-dev] [Ann] ObjectStatistics

by Denis Kudriashov

And you can load it by Gofer it smalltalkhubUser: 'Pharo' project: 'ObjectStatistics'; configuration; loadStable And play with examples on ObjectStatistics class side 2016-06-06 16:53 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hello. > > I just publish new tool ObjectStatistics to analyze objects set. > I first created it to analyze network communication during remote > debugging. And then I realize how general it could be. > Now it is ready to use package. It could be good foundation to improve and > simplify our profiler tools. > > You can see details and examples on my blog > http://dionisiydk.blogspot.fr/2016/06/objectstatistics-simple-objects.html > . > > Here is little abstract: > ObjectStatistics tool to analyse set of objects by computing different > kind of metrics and look at them from different angles. It implements > simplistic OLAP Cube approach for data analysis but in objects space. > Imaging that we have collection of message sends and we want to know > number of message sends in dimension of receiver, receiver class and > message selector. We have different angles to look at this data: from > receiver class to selector and receiver or from selector to receiver class > and receiver or any other combination. > We also could analyze different kind of metrics which could be computed on > given objects. It could be number of unique receivers, execution time, > executed lines of code, etc. > This package implements computation of object statistics over declared > metrics and dimensions space. > > Best regards, > Denis >

June 6, 2016

[Ann] ObjectStatistics

by Denis Kudriashov

Hello. I just publish new tool ObjectStatistics to analyze objects set. I first created it to analyze network communication during remote debugging. And then I realize how general it could be. Now it is ready to use package. It could be good foundation to improve and simplify our profiler tools. You can see details and examples on my blog http://dionisiydk.blogspot.fr/2016/06/objectstatistics-simple-objects.html. Here is little abstract: ObjectStatistics tool to analyse set of objects by computing different kind of metrics and look at them from different angles. It implements simplistic OLAP Cube approach for data analysis but in objects space. Imaging that we have collection of message sends and we want to know number of message sends in dimension of receiver, receiver class and message selector. We have different angles to look at this data: from receiver class to selector and receiver or from selector to receiver class and receiver or any other combination. We also could analyze different kind of metrics which could be computed on given objects. It could be number of unique receivers, execution time, executed lines of code, etc. This package implements computation of object statistics over declared metrics and dimensions space. Best regards, Denis

June 6, 2016

Re: [Pharo-dev] atomicity of non-local returns

by ClÃ©ment Bera

Hi Ben, Firstly be careful because atomic usually means that the thread cannot be interrupted by a concurrent native thread, so an atomic operation has to be guaranteed at processor level. Assuming that by atomic you mean that the operation's process cannot be preempted by another green thread, yes there is big problems with non local returns. Two main issues: - NLR can trigger unwind blocks, which can switch to another process. - NLR can fail, triggering the cannotReturn: call-back, which can switch to another process. *I understand generally that an inlined #ifTrue is atomic. Forexample, here after the primitive returns, no interruption can occurbefore the #ensure is invoked... self primitiveWaitAcquire ifTrue: [mutuallyExclusiveBlock ensure: [self release]].* The exact answer is that #*ifTrue*: can be interrupted if *self primitiveWaitAcquire *is not a boolean, and can't be interrupted if it's a boolean. It's nice to mark in a comment if part of the method's code has not to be interrupted to avoid issues years later. *But I want to know whether a non-local return could have an impact onthat atomicity. For example ... self primitiveWaitAcquire ifTrue: [ ^ mutuallyExclusiveBlock ensure: [self release]]* In your code there is no non local return because ifTrue: is inlined by the Bytecode compiler. Try to compile it and look at the bytecode you will see. Else as I said at the beginning of the mail, a non local return can imply a process switch if that was your question. On Mon, Jun 6, 2016 at 2:46 PM, Ben Coman <btc(a)openinworld.com> wrote: > I understand generally that an inlined #ifTrue is atomic. For > example, here after the primitive returns, no interruption can occur > before the #ensure is invoked... > self primitiveWaitAcquire ifTrue: > [mutuallyExclusiveBlock ensure: [self release]]. > > But I want to know whether a non-local return could have an impact on > that atomicity. For example ... > self primitiveWaitAcquire ifTrue: > [ ^ mutuallyExclusiveBlock ensure: [self release]] > > cheers -ben > >

June 6, 2016