- Pharo-dev - lists.pharo.org

GLMPresentation >> window looks strange

by Guille Polito

Hi! We were browsing with Steph users of #announce: and we arrived to the following method: GLMPresentation >> window self announce: (GLMWindowRequest new action: [ :aWindow | ^ aWindow ]). ^ nil And we could not stop noticing that, while the announcement, probably originally meant to decouple the Presentation and the window, is now coupling them in a non-clear way... I mean, the coupling is there, but is now hidden in an announcement. Also, the usage of the non-local return makes the assumption that the announcement will be executed on the same process... And that is at most strange, but also looks buggy. Why is this method not a normal accessor? Guille

June 7, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60065 Home: https://github.com/pharo-project/pharo-core

June 7, 2016

[pharo-project/pharo-core] c03d19: 60065

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: c03d194384c8d581f6edf9ff72723b12c2277c00 https://github.com/pharo-project/pharo-core/commit/c03d194384c8d581f6edf9ff… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline23_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2194_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2201_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version220_.st M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F20%5F2_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60064.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60065.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60064.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60065.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60065 18415 Fix Regex-Core extensions capitalization https://pharo.fogbugz.com/f/cases/18415 18404 ConfigurationOfUnifiedFFI not in sync with current Pharo package versions https://pharo.fogbugz.com/f/cases/18404 18401 The ConfigurationOfRubric is not in sync https://pharo.fogbugz.com/f/cases/18401 http://files.pharo.org/image/60/60065.zip

June 7, 2016

[pharo-project/pharo-core] 1838ea: 60064

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 1838ea43bf2a0d7d0c6e5f552f2d295d96b4d359 https://github.com/pharo-project/pharo-core/commit/1838ea43bf2a0d7d0c6e5f55… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: M CodeImportCommandLineHandlers.package/STCommandLineHandler.class/instance/installing/installSourceFile_.st A CodeImportCommandLineHandlers.package/STCommandLineHandler.class/instance/installing/skipShebangFrom_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/README.md A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/catalog/catalogContactInfo.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/catalog/catalogDescription.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/catalog/catalogKeyClassesAndExample.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/catalog/catalogKeywords.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/mc-manipulation/currentVersions.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/mc-manipulation/currentVersionsOf_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/mc-manipulation/mainRepo.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/mc-manipulation/versionFromWC_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/properties/projectName.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/properties/publicRepoLocations.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/properties/rootConfNamesForLookup.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/properties/supportedVersions.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting-codegen/confSourceFor_with_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting-codegen/symbolicSourceFor_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting/commitSelfWithVersion_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting/commitToPublicRepos_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting/copyVersions_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting/createConfFor_with_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting/createSymbolicFor_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/snapshotting/makeVersion_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/definition.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F0%5F2_.st A QualityAssistant-Test.package/QACritiqueTest.class/README.md A QualityAssistant-Test.package/QACritiqueTest.class/definition.st A QualityAssistant-Test.package/QACritiqueTest.class/instance/accessing/testFixAction.st A QualityAssistant-Test.package/QACritiqueTest.class/instance/as yet unclassified/runWithDidalogPopping_.st A QualityAssistant-Test.package/QACritiqueTest.class/instance/as yet unclassified/runWithMorphicDidalogPopping_.st A QualityAssistant-Test.package/QACritiqueTest.class/instance/as yet unclassified/testGuidedBan.st M QualityAssistant.package/extension/ReSystemAnnouncer/instance/notifyViewedDiffFor_of_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60063.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60064.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60063.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60064.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-CommandLineHandler.package/extension/CodeImporter/instance/shebang.st R System-CommandLineHandler.package/extension/CodeImporter/instance/skipShebang.st A Tool-Base.package/PharoShortcuts.class/instance/as yet unclassified/delWordShortcut.st M Tool-Base.package/PharoShortcuts.class/instance/keymaps - code/displayIfFalseShortcut.st M Tool-Base.package/PharoShortcuts.class/instance/keymaps - editor edit/backwardWordDeleteShortcut.st M Tool-Base.package/PharoShortcuts.class/instance/keymaps - editor navigation/forwardWordShortcut.st Log Message: ----------- 60064 18427 System-CommandLineHandler should be abstract and not extend particular command line handlers https://pharo.fogbugz.com/f/cases/18427 18394 change some more keymapping definitions in PharoShortcuts https://pharo.fogbugz.com/f/cases/18394 18412 QAViewedDiff(Object)>>doesNotUnderstand: #critic: https://pharo.fogbugz.com/f/cases/18412 http://files.pharo.org/image/60/60064.zip

June 7, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60064 Home: https://github.com/pharo-project/pharo-core

June 7, 2016

[pharo-project/pharo-core] 33ed32: 60063

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 33ed32f27e6dee56c7b9df21ebb2ee1ec0392407 https://github.com/pharo-project/pharo-core/commit/33ed32f27e6dee56c7b9df21… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: M Keymapping-Tests.package/AbstractKeymappingTest.class/README.md R Keymapping-Tests.package/AbstractKeymappingTest.class/instance/as yet unclassified/eventKey_.st R Keymapping-Tests.package/AbstractKeymappingTest.class/instance/as yet unclassified/eventKey_alt_.st R Keymapping-Tests.package/AbstractKeymappingTest.class/instance/as yet unclassified/eventKey_alt_ctrl_command_shift_.st R Keymapping-Tests.package/AbstractKeymappingTest.class/instance/as yet unclassified/eventKey_command_.st R Keymapping-Tests.package/AbstractKeymappingTest.class/instance/as yet unclassified/eventKey_ctrl_.st R Keymapping-Tests.package/AbstractKeymappingTest.class/instance/as yet unclassified/eventKey_shift_.st A Keymapping-Tests.package/AbstractKeymappingTest.class/instance/utilities/eventKey_.st A Keymapping-Tests.package/AbstractKeymappingTest.class/instance/utilities/eventKey_alt_.st A Keymapping-Tests.package/AbstractKeymappingTest.class/instance/utilities/eventKey_alt_ctrl_command_shift_.st A Keymapping-Tests.package/AbstractKeymappingTest.class/instance/utilities/eventKey_command_.st A Keymapping-Tests.package/AbstractKeymappingTest.class/instance/utilities/eventKey_ctrl_.st A Keymapping-Tests.package/AbstractKeymappingTest.class/instance/utilities/eventKey_shift_.st M Keymapping-Tests.package/KMDispatcherTestCase.class/instance/tests/testNoMultiTrigger.st M Keymapping-Tests.package/KMKeymapTest.class/instance/tests/testExecute.st R Keymapping-Tests.package/KMMockMorph.class/README.md R Keymapping-Tests.package/KMMockMorph.class/definition.st M Keymapping-Tests.package/KMPerInstanceTests.class/instance/tests/testAddMoreThanOneHandler.st M Keymapping-Tests.package/KeymapBuilderTest.class/instance/tests/testAttachKeymapAndExecuteExecutes.st M Multilingual-Languages.package/LanguageEnvironment.class/class/accessing/localeID_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60062.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60063.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60062.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60063.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Finalization.package/extension/Object/instance/mourn.st A System-Localization.package/LocaleID.class/class/accessing-defaults/default.st M System-Support.package/SmalltalkImage.class/instance/miscellaneous/metacelloPlatformAttributes.st M System-Support.package/SmalltalkImage.class/instance/system attributes/supportsQueueingFinalization.st A Tests.package/EphemeronTests.class/README.md A Tests.package/EphemeronTests.class/definition.st A Tests.package/EphemeronTests.class/instance/tests/testEphemeronAreNotFinalizedIfCollected.st A Tests.package/EphemeronTests.class/instance/tests/testEphemeronIsNotRemovedFromRegistryUponFinalizationIfKeyIsReferenced.st A Tests.package/EphemeronTests.class/instance/tests/testEphemeronIsRemovedFromRegistryUponFinalization.st A Tests.package/EphemeronTests.class/instance/tests/testEphemeronKeyIsFinalizedWhenKeyIsNotHoldStrongly.st A Tests.package/EphemeronTests.class/instance/tests/testEphemeronKeyIsNotFinalizedWhenKeyIsHoldStrongly.st A Tests.package/EphemeronTests.class/instance/tests/testInterconnectedEphemeronsAreCollectedIfKeysAreNotReferencedFromTheOutside.st A Tests.package/EphemeronTests.class/instance/tests/testInterconnectedEphemeronsAreNotCollectedIfAKeyIsReferencedFromTheOutside.st A Tests.package/EphemeronTests.class/instance/tests/testInterconnectedEphemeronsAreNotCollectedIfTheOtherKeyIsReferencedFromTheOutside.st Log Message: ----------- 60063 18410 Remove KMMockMorph https://pharo.fogbugz.com/f/cases/18410 18398 LanguageEnvironment class>>#localeID: can cause endless loop https://pharo.fogbugz.com/f/cases/18398 18406 Add EphemeronTests https://pharo.fogbugz.com/f/cases/18406 18400 Add Pharo 6 to #metacelloPlatformAttributes (but keep Pharo 5 for now) https://pharo.fogbugz.com/f/cases/18400 http://files.pharo.org/image/60/60063.zip

June 7, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60063 Home: https://github.com/pharo-project/pharo-core

June 7, 2016

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