February 2016 - Pharo-dev - lists.pharo.org

Simple versus Recursive Mutexes

by Ben Coman

While we are in the process of revising the Mutex infrastructure [1] to use dedicated primitives rather than rely on counting via a semaphore, I want to raise the question of simple versus recursive mutexes. This isn't something I know much about, except that some people strongly believe recursive mutexes are evil, including David Butenhof who apparently was the guy who added recursive mutexes to POSIX "on a dare [...] but nobody was supposed to use recursive mutexes." [1]. There are two interesting discussion on stockoverflow [2][3]. But btw I disagree with Tall Jeff [3] says "The difference between a recursive and non-recursive mutex has to do with ownership. " I think he confuses a simple-mutex and binary-semaphore, as do a some commenters. "Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some performance considerations and advises "a recursive mutex is dangerous because you lose sense of locking scope. It costs more than a simple mutex." "Recursive Locks Will Kill You!" [5] provides some thread safety guidelines. Finally, there is a paper "Ad Hoc Synchronization Considered harmful" [6], which I haven't read yet since I wanted to get this post out before heading to bed, but I hope to tomorrow. [1] http://www.zaval.org/resources/library/butenhof1.html [2] http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex [3] http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recur… [4] http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ [5] http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ [6] https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf So our existing Mutex implementation happens to be recursive, and I'm not suggesting we change that. However if we should consider *not* baking the *assumption* of recursion into the primitives, so the same primitives could *also* be used for a SimpleMutex class. The logic to provide recursion for Mutex is only [ owner = activeProcess ] which is easily done in-image. So I propose introducing aquire/release primitives based off the existing critical section primitives with the recursion removed. cheers -ben

Feb. 2, 2016

[pharo-project/pharo-core] f4f863: 50564

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f4f863290b523e16e752edd74d9b4e1e133ea9f9 https://github.com/pharo-project/pharo-core/commit/f4f863290b523e16e752edd7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-02 (Tue, 02 Feb 2016) Changed paths: M NautilusRefactoring.package/NautilusRefactoring.class/instance/performing/performRefactorings_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50563.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50564.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50563.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50564.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50564 17366 wrong TempsNamesQCompress method trailer ? https://pharo.fogbugz.com/f/cases/17366 17406 Renaming a class using the class menu "rename" option allows for non-capitalized class name https://pharo.fogbugz.com/f/cases/17406 http://files.pharo.org/image/50/50564.zip

Feb. 2, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 2, 2016

Now issues which are hanging on Monkey checking resumes automatically

by Denis Kudriashov

Hi. We added little job to automatically resume issues which are stuck on monkey checking more than one hour. Such issues will be returned to previous status "Fix review needed"

Feb. 2, 2016

Re: [Pharo-dev] CI is down?

by Christophe Demarey

yes, good idea Le 2 fÃ©vr. 2016 Ã 14:08, Ben Coman a Ã©crit : > Perhaps pharo-dev can be subscribed to the annoucements? > cheers -ben > > On Tue, Feb 2, 2016 at 8:34 PM, Christophe Demarey > <Christophe.Demarey(a)inria.fr> wrote: >> Yes, there is a maintenance. >> You should have received this message (if you did not unregister from >> communication lists): >> >> Dear users, >> >> A maintenance is planned tomorrow (2/2) to upgrade the storage of the CI >> servers. Thus, the service will be stopped between 1pm and 2pm. >> >> Thank you for your understanding, >> Emmanuel >> >> >> Le 2 fÃ©vr. 2016 Ã 13:14, Aliaksei Syrel a Ã©crit : >> >> Hi >> >> https://ci.inria.fr/pharo is not responding >> Has any one the same problem? >> >> Cheers, >> Alex >> >> >

Feb. 2, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 2, 2016

[pharo-project/pharo-core] d5f211: 50563

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d5f211e9bbe8bcaa74f087bebae421e0c7a84a41 https://github.com/pharo-project/pharo-core/commit/d5f211e9bbe8bcaa74f087be… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-02 (Tue, 02 Feb 2016) Changed paths: A Deprecated50.package/extension/Morph/instance/submorphNamed_.st A Deprecated50.package/extension/Morph/instance/submorphNamed_ifNone_.st M Flashback-Decompiler.package/FBDDecompiler.class/instance/private/interpretMethod_.st A Flashback-Decompiler.package/FBDDecompiler.class/instance/private/maybeSkipCallPrimitiveBytecode_.st R Morphic-Core.package/Morph.class/instance/submorphs-accessing/submorphNamed_.st R Morphic-Core.package/Morph.class/instance/submorphs-accessing/submorphNamed_ifNone_.st A OpalCompiler-Core.package/OCClassScope.class/instance/accessing/class_.st A OpalCompiler-Core.package/OCClassScope.class/instance/accessing/getClass.st R OpalCompiler-Core.package/OCClassScope.class/instance/initializing/class_.st A OpalCompiler-Core.package/OCLiteralVariable.class/instance/testing/isFromSharedPool.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50562.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50563.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50562.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50563.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50563 17516 add #isFromSharedPool to OCLItteralVariable https://pharo.fogbugz.com/f/cases/17516 17495 Decompiler cant decompile Object>>#instVarAt: due to error code https://pharo.fogbugz.com/f/cases/17495 17508 Deprecate Unused Morph methods: submorphNamed: and submorphNamed: aName ifNone: aBlock https://pharo.fogbugz.com/f/cases/17508 http://files.pharo.org/image/50/50563.zip

Feb. 2, 2016

Re: [Pharo-dev] GTInspector and PointerExplorer

by Ben Coman

On Tue, Feb 2, 2016 at 10:38 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, Feb 2, 2016 at 4:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> Anyone working with GTInspector and inspecting "pointers to" (menu Item >> "Open pointers to"). >> Either I make something wrong or it just does not work. The only references >> I can >> see in this pointer inspector are the references *from* the inspector >> itself. >> >> I put an EllipseMorph in a Morph and choosed "Open Pointers to" in the >> inspector of >> the EllipseMorph. >> I would expect something like >> EllipseMorph <- array (submorphs) <- Morph >> >> But instead I only see this: >> > > I agree it seems really hard to chase pointersTo. > > Doing "EllipseMorph new openInWorld. World inspect." > I can see the EllipseMorph in the "submorphs" ivar at (for me) array > item 4. In the raw tab, right-clicking on item 4 > Open Pointers To, > I would hope to see the WorldMorph its not there. > > Now in the WorldMorph, right-clicking on "submorphs" > Open Pointers To > at item 3 (for me) shows... "an Array [40 items] ( > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > nil > 'self'->a WorldMorph(562956288) [world] > #backgroundMorph->nil > #borderColor->(Color r: 0.861 g: 1.0 b: 0.722 alpha: 1.0) > #borderWidth->0 > #bounds->(0@0) corner: (1920@1172) > #color->(Color r: 0.937 g: 0.937 b: 0.937 alpha: 1.0) > #extension->a MorphExtension (287899392) [other: (dragEnabled -> > true) (dropEnabled -> true) (lastKeystroke -> '<down>') (kmDispatcher > -> a KMDispatcher)] > #fullBounds->(0@0) corner: (1920@1172) > #griddingOn->nil > #osWindow->nil > #owner->nil > #session->nil > #submorphs->an Array(a TaskbarMorph(804941056) a > GLMSystemWindow(9541632) a GLMSystemWindow(614298112) an > EllipseMorph(763635712) an ImageMorph(342771456)) > #worldState->a WorldState > nil > nil > nil > nil > nil > nil > nil)" > > ...so WorldMorph's ivars start at item 21, with its self at item 20. Strange? > > > Another thing, World > Tools > Finder > Source > "Open pointers to" > lists only two locations. Inserting a "self halt" at both locations like this > selectionAct: [:list | self halt. > ((list selection pointersToExcept: { list selection }) > reject: [ :each | each pointsOnlyWeaklyTo: list selection > ]) inspect ] > on: $t > entitled: 'Open pointers to' > > would I expect trigger a debugger when I invoke the menu item, but it > doesn't, wtf??? > > cheers -ben >> I would expect something like >> EllipseMorph <- array (submorphs) <- Morph Trying to avoid the fluff added by the UI inspectors, trying this I would expect(?) the following would display the WorldMorph twice... morph := EllipseMorph new openInWorld. refs := morph pointersTo. refs do: [ :ref | ref pointersTo inspect ]. refs inspect. World inspect. but it doesn't. I'm lost. cheers -ben

Feb. 2, 2016

Re: [Pharo-dev] GTInspector and PointerExplorer

by Ben Coman

On Tue, Feb 2, 2016 at 4:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Anyone working with GTInspector and inspecting "pointers to" (menu Item > "Open pointers to"). > Either I make something wrong or it just does not work. The only references > I can > see in this pointer inspector are the references *from* the inspector > itself. > > I put an EllipseMorph in a Morph and choosed "Open Pointers to" in the > inspector of > the EllipseMorph. > I would expect something like > EllipseMorph <- array (submorphs) <- Morph > > But instead I only see this: > I agree it seems really hard to chase pointersTo. Doing "EllipseMorph new openInWorld. World inspect." I can see the EllipseMorph in the "submorphs" ivar at (for me) array item 4. In the raw tab, right-clicking on item 4 > Open Pointers To, I would hope to see the WorldMorph its not there. Now in the WorldMorph, right-clicking on "submorphs" > Open Pointers To at item 3 (for me) shows... "an Array [40 items] ( nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 'self'->a WorldMorph(562956288) [world] #backgroundMorph->nil #borderColor->(Color r: 0.861 g: 1.0 b: 0.722 alpha: 1.0) #borderWidth->0 #bounds->(0@0) corner: (1920@1172) #color->(Color r: 0.937 g: 0.937 b: 0.937 alpha: 1.0) #extension->a MorphExtension (287899392) [other: (dragEnabled -> true) (dropEnabled -> true) (lastKeystroke -> '<down>') (kmDispatcher -> a KMDispatcher)] #fullBounds->(0@0) corner: (1920@1172) #griddingOn->nil #osWindow->nil #owner->nil #session->nil #submorphs->an Array(a TaskbarMorph(804941056) a GLMSystemWindow(9541632) a GLMSystemWindow(614298112) an EllipseMorph(763635712) an ImageMorph(342771456)) #worldState->a WorldState nil nil nil nil nil nil nil)" ...so WorldMorph's ivars start at item 21, with its self at item 20. Strange? Another thing, World > Tools > Finder > Source > "Open pointers to" lists only two locations. Inserting a "self halt" at both locations like this selectionAct: [:list | self halt. ((list selection pointersToExcept: { list selection }) reject: [ :each | each pointsOnlyWeaklyTo: list selection ]) inspect ] on: $t entitled: 'Open pointers to' would I expect trigger a debugger when I invoke the menu item, but it doesn't, wtf??? cheers -ben

Feb. 2, 2016

Re: [Pharo-dev] QualityAssistant feedback

by Marcus Denker

> On 02 Feb 2016, at 14:55, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-02-02 14:46 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > Hello, > > Yes. Another side effect is that you do not get all these âtempX is not used should it be removeâ > messages when saving a method. > > Instead, semantic analysis tags the variable as not used and the editor shows an icon/highlight. > > What we need to do is to integrate this more with the code critique. > > It would be good to have an action associated with the highlighted temp var for > removing the unused var. Or does this already work ? > No, but it should be easy to addâ¦ Marcus

Feb. 2, 2016