November 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Nov. 20, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Thierry Goubier

2015-11-20 12:46 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > Hi! > > With Guille and Pablo this morning we found what is the problem and > apparently fixed it. The problem is that there is a process in priority 10 > that takes the delay lock (accessProtect semaphore) and go to sleep. Then > the #benchFor: launches another process in priority 79 that tries to take > the delay lock but, since it's taken by the other process, it goes to > sleep. But the UI process is in priority 40 so it will always have priority > over the one that has the lock. Consequence: the process in priority 10 has > the delay lock and will never be awaken until the UI process gets > suspended. > I believe this is a text book example of priority inversion. Kudo's for finding it! Thierry > > More in detail, the following method makes the assumption that once the > delay process finishes the handling of the delay to schedule, it will > return to same process. But that is not true if there is another process > with more priority. > > schedule: aDelay > | scheduled | > scheduled := false. > aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has > already been scheduled.']. > accessProtect critical: [ > scheduledDelay := aDelay. > timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" > scheduled := (scheduledDelay == nil). > ]. > ^scheduled. > > Our solution is to run the critical section in a higher priority to ensure > that always comes back to the same process to release the delay lock. > > schedule: aDelay | scheduled | scheduled := false. aDelay > schedulerBeingWaitedOn ifTrue: [ ^ self error: 'This Delay has already been > scheduled.' ]. [ accessProtect critical: [ scheduledDelay := aDelay. > timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" > scheduled := scheduledDelay == nil ]. ^ scheduled ] valueAt: Processor > timingPriority - 1 > > Also, to not have interference with the benchmarking process we reduce the > priority of the process used in benchFor: > > benchFor: duration > "Run me for duration and return a BenchmarkResult" > "[ 100 factorial ] benchFor: 2 seconds" > | count run started | > count := 0. > run := true. > [ duration wait. run := false ] forkAt: Processor timingPriority *- 2*. > started := Time millisecondClockValue. > [ run ] whileTrue: [ self value. count := count + 1 ]. > ^ BenchmarkResult new > iterations: count; > elapsedTime: (Time millisecondsSince: started) milliSeconds; > yourself > > > We will create an entry in fogbugz and submit the change. > > Regards, > Martin, Guille and Pablo > > > > On Wed, Nov 18, 2015 at 8:33 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> I went ahead and implemented a simple fix for the styler. Not sure how >> well it performs but in my simple experiments it seems to work fine. Please >> test it and let me know what you think. >> >> >> https://pharo.fogbugz.com/f/cases/17050/SHTextStyler-styleInBackgroundProce… >> >> Cheers, >> Max >> >> >> > On 18 Nov 2015, at 19:02, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: >> > >> > >> > >> > Am 18.11.15 um 11:48 schrieb Andrei Chis: >> >> Can you try the script below in the latest Pharo image and let me know >> how much does it take to execute on your machine: >> >> >> >> |duration benchmarkResult| >> >> 100 timesRepeat: [ >> >> RubScrolledTextMorph new >> >> model: (RubScrolledTextModel new setInitialText: '1+1'; yourself); >> >> beForSmalltalkScripting; >> >> yourself >> >> ] . >> >> >> >> duration := 100 milliSeconds. >> >> benchmarkResult := [ 100 factorial ] benchFor: duration. >> >> >> >> In my case it takes around 1 minute. The inner loop finishes >> immediately and then most time is spend executing the benchmark. >> >> >> >> At the end I get the following result: >> >> "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 >> milliseconds. 30,525 per second)" >> >> >> >> So the benchmark is executed for over one minute before the delay >> expires. >> >> >> >> >> >> >> > "a BenchmarkResult(1,263,573 iterations in 37 seconds 689 milliseconds. >> 33,526 per second)" >> > (HP Z420 with Xeon E5-1620 under OpenIndiana). >> > >> > Regards >> > Andreas >> >> >> >

Nov. 20, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Martin Dias

Hi! With Guille and Pablo this morning we found what is the problem and apparently fixed it. The problem is that there is a process in priority 10 that takes the delay lock (accessProtect semaphore) and go to sleep. Then the #benchFor: launches another process in priority 79 that tries to take the delay lock but, since it's taken by the other process, it goes to sleep. But the UI process is in priority 40 so it will always have priority over the one that has the lock. Consequence: the process in priority 10 has the delay lock and will never be awaken until the UI process gets suspended. More in detail, the following method makes the assumption that once the delay process finishes the handling of the delay to schedule, it will return to same process. But that is not true if there is another process with more priority. schedule: aDelay | scheduled | scheduled := false. aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has already been scheduled.']. accessProtect critical: [ scheduledDelay := aDelay. timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" scheduled := (scheduledDelay == nil). ]. ^scheduled. Our solution is to run the critical section in a higher priority to ensure that always comes back to the same process to release the delay lock. schedule: aDelay | scheduled | scheduled := false. aDelay schedulerBeingWaitedOn ifTrue: [ ^ self error: 'This Delay has already been scheduled.' ]. [ accessProtect critical: [ scheduledDelay := aDelay. timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" scheduled := scheduledDelay == nil ]. ^ scheduled ] valueAt: Processor timingPriority - 1 Also, to not have interference with the benchmarking process we reduce the priority of the process used in benchFor: benchFor: duration "Run me for duration and return a BenchmarkResult" "[ 100 factorial ] benchFor: 2 seconds" | count run started | count := 0. run := true. [ duration wait. run := false ] forkAt: Processor timingPriority *- 2*. started := Time millisecondClockValue. [ run ] whileTrue: [ self value. count := count + 1 ]. ^ BenchmarkResult new iterations: count; elapsedTime: (Time millisecondsSince: started) milliSeconds; yourself We will create an entry in fogbugz and submit the change. Regards, Martin, Guille and Pablo On Wed, Nov 18, 2015 at 8:33 PM, Max Leske <maxleske(a)gmail.com> wrote: > I went ahead and implemented a simple fix for the styler. Not sure how > well it performs but in my simple experiments it seems to work fine. Please > test it and let me know what you think. > > > https://pharo.fogbugz.com/f/cases/17050/SHTextStyler-styleInBackgroundProce… > > Cheers, > Max > > > > On 18 Nov 2015, at 19:02, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > > > > > Am 18.11.15 um 11:48 schrieb Andrei Chis: > >> Can you try the script below in the latest Pharo image and let me know > how much does it take to execute on your machine: > >> > >> |duration benchmarkResult| > >> 100 timesRepeat: [ > >> RubScrolledTextMorph new > >> model: (RubScrolledTextModel new setInitialText: '1+1'; yourself); > >> beForSmalltalkScripting; > >> yourself > >> ] . > >> > >> duration := 100 milliSeconds. > >> benchmarkResult := [ 100 factorial ] benchFor: duration. > >> > >> In my case it takes around 1 minute. The inner loop finishes > immediately and then most time is spend executing the benchmark. > >> > >> At the end I get the following result: > >> "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 > milliseconds. 30,525 per second)" > >> > >> So the benchmark is executed for over one minute before the delay > expires. > >> > >> > >> > > "a BenchmarkResult(1,263,573 iterations in 37 seconds 689 milliseconds. > 33,526 per second)" > > (HP Z420 with Xeon E5-1620 under OpenIndiana). > > > > Regards > > Andreas > > >

Nov. 20, 2015

Re: [Pharo-dev] Kernel-Tests and SystemAnnouncer

by Peter UhnÃ¡k

And not just announcers, some of the tests there leave quite a footprint. I've recently discussed something similar with regards to performance of subclassing in tests http://forum.world.st/fast-subclassing-class-creation-in-tests-td4857779.ht… So Kernel-Tests might also benefit from it. Right now I've also encountered this thread http://forum.world.st/New-class-factory-for-tests-and-other-use-cases-td129… , it's quite old (2009), but maybe it could be used instead of directly manipulating the env. On the other hand, how often do you manually trigger Kernel-Tests? CI doesn't care that much about it. Peter On Fri, Nov 20, 2015 at 12:21 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > Ideally shouldn't Kernel-Tests, or tests in general, be silent and not > trigger a lot of system announcers? > Right now Kernel-Tests trigger around 250 announcements through the > SystemAnnouncer. > > Cheers, > Andrei

Nov. 20, 2015

Kernel-Tests and SystemAnnouncer

by Andrei Chis

Hi, Ideally shouldn't Kernel-Tests, or tests in general, be silent and not trigger a lot of system announcers? Right now Kernel-Tests trigger around 250 announcements through the SystemAnnouncer. Cheers, Andrei

Nov. 20, 2015

Re: [Pharo-dev] ConfigurationOfIDE working again

by stepharo

Le 19/11/15 22:45, Pavel Krivanek a Ã©crit : > Hi Stef, > > 2015-11-19 21:44 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Pavel > > may be you want to sync with christophe because he is working hard > on getting the bootstrap working for real :) > > > I already talked to him about a month ago to find out where can I help. excellent! > > Then after we really want to load Pharo using configurations or > cargo package manager. > Once we will get done the configurations will be always checked. > > > Some time ago I added a simple test that checked if the amount of > unimplemented calls was increased in the minimal Pharo. If yes it > cased the job failure. I expected that it will fail about once per > month or two but in real Marcus complained up to two times per day > that it generation of the minimal Pharo failed because of this check. > It illustrates how sometimes hard is to keep things working in this > area. We need to focus on it more to start to use the image building > process based on configurations in production because with the current > way we will have only very small progress with a lot of spent energy. Yes :) This is why we want to arrive to a bootstrap point. Stef > > Cheers, > -- Pavel > > Stef > > Le 19/11/15 11:16, Pavel Krivanek a Ã©crit : > > Hi, > > the job for ConfigurationOfIDE that loads GUI and tools (not > all for now) to minimal Pharo is now producing usable image > again.: > > https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE/ > > We definitely need to find a way how to keep it green and > improve and clean it instead of spending one forenoon once in > a while by fixing it ;-) > > Cheers, > -- Pavel > > > >

Nov. 20, 2015

Cleanup of debug requests API

by Denis Kudriashov

Hi I try to investigate how debugger opens and who initiates it. I want to cleanup this logic and simplify current debugger API. I found that basic error debugging starts with UIManager then UIManager calls SpecDebugger, then SpecDebugger calls UIManager and again... At the end of this chain debugger is opened by #openFullSuspendLabel: or #openNotifierContents:label: There are two places where opening debugger initiated differently: - Low space watcher calls SpecDebugger class>>openInterrupt:onProcess: - Warning default action calls SpecDebugger class>>openContext:label:contents: (And it not uses UIManager. I guess non interactive mode not working here). In latest Pharo image it is only users of this methods. Is anybody know anyone else? I almost cleaned basic errors debugging. And I want use it for this two cases too. But they implements very specific logic. They both contains primitive simulation guard 19 and some kind of recursion tracking. I understand that low space watcher requires something clever. But why Warning not opens debugger with way Error does it? Any suggestions? Best regards, Denis

Nov. 20, 2015

Re: [Pharo-dev] About being a real Pharo Jedi developer

by Dimitris Chloupis

Thanks for the info. I think i am on safe side of things since I dont mess with pharo internals. You say if I override an existing method, that method cannot be recovered, but that is strange since the system does have versions for each method , so I assume here that is not that is not possible rather than none actually implemented this in a convenient way. How you can have class collision , I assumed so far that the system does not allow you to have two classes with the same name. If you have subclasses in another package then I would let them MNU. I think its kinda insane to try to protect the user from all scenarios, at least not before you deal with more pressing issues / bugs. One thing that could help here is to have something similar to when we install a project that warns us that a project depends on other projects/ classes we could have the same warning for when we remove classes. I think also its a good idea to allow user some control, for example maybe the user want to keep those subclasses and make them subclass another class instead. Yeah I will look into unloading with metacello that sounds cleaner this is an issue that really interests me. How to make my project uninstallable and automatically update-able is two areas that deeply interest me. On Fri, Nov 20, 2015 at 12:56 AM Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > To unload a package you can do it from Monticello Browser..Select the > package (left column), right click, "Unload Package". > But not that it will not work properly in cases where you have method > overrides (the original methods you override will NOT be recovered), or > class collisions (imagine your package has a class name collision with a > class name of another package)... > Then you can have instances of classes you unload...hence the Obsolete > thingy (instances are now instance of an obsolete class). > Then you can also have subclasses in ANOTHER package of classes of the > package you unload. What you do with the subclasses? and with the instances > of such subclasses? > So... order of unloading does matter across packages (in the same way that > loading does). So for unloading multiple packages you should be using > Meacello or similar. > > As you can see, it's not an easy task. > > > > > On Thu, Nov 19, 2015 at 7:23 PM, milton mamani <akevalion(a)gmail.com> > wrote: > >> +1 >> By the way so how one can unload a project from the pharo image ? I never >> tried that one before. >> >> Use the Force Dimitris >> >> Sorry I dont have the answer for this now, but I am interested on this >> issue. >> >> 2015-11-19 18:05 GMT-04:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> I prefer being a technomage to a jedi, jedies are too, well naive and >>> purists. >>> >>> By the way so how one can unload a project from the pharo image ? I >>> never tried that one before. >>> >>> On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo(a)free.fr> wrote: >>> >>>> When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me >>>> the following (yes back in 96) >>>> >>>> translated from Yoda language: >>>> >>>> you will be a real Jedi when your code will load in one click! >>>> you will be a real Jedi when your code will unload in one click and >>>> do not let shit behind it! >>>> >>>> Simple no. So when do we get real Jedi knights? >>>> >>>> Stef >>>> >>>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 20, 2015

Re: [Pharo-dev] About being a real Pharo Jedi developer

by Craig Latta

Stef writes: > When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told > me the following (yes back in 96) > > translated from Yoda language: > > you will be a real Jedi when your code will load in one click! > you will be a real Jedi when your code will unload in one click > and do not let shit behind it! > > Simple no. So when do we get real Jedi knights? We get them when we have modules that exist as live objects all the time, to which we can delegate the task of unloading. Those modules have access to all versions of methods and class definitions, and every method and class definition is covered by the module system at all times. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Nov. 20, 2015

Re: [Pharo-dev] opal optimize to do limits

by Eliot Miranda

Hi Nicolai, > On Nov 20, 2015, at 12:33 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Thanks eliot, Clement, > > but if the argument for to:do: is not an expression but one of the method argument, this > transformation is not needed. Or still? That's the corollary to what I said. Since method (*) arguments are read-only it is safe to use them directly and avoid the transformation. One could implement this quickly in the Squeak compiler too :-). How many cases have you identified where this matters? Is it very common? (* and with the right preference, block) _,,,^..^,,,_ (phone) > > > > > 2015-11-20 8:31 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> You can use whileTrue: if it's a problem for you not to evaluate the limit at each iteration of the loop. > > I don't need this. I just compared some compiled methods bytecodes after the latest fix for the wrong frame size calculation. > For this, I compared opal compilers result with that of the old compiler. And I noticed that some methods compiled with > opal had some "hidden" temps and couldn't explain way:) > > >> >> If you look at OrderedCollection for example, there are implemented differently in Pharo/VW and Squeak. Pharo and VW use to:do: whereas Squeak uses whileTrue: to iterate over the collection. Hence, if you remove elements from the OrderedCollection while iterating over it, the behavior is different. >> >> >> 2015-11-20 1:34 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Because were to:do: not inlined the expression passed as the to: actual argument would be evaluated exactly once (bound to the formal argument for to:) and so assigning to a temporary preserves the semantics in the most direct way. If the expression has side effects then those side effects must occur only once. >>> >>> Note that were the to: expression merely another variable then the compiler could only substitute the original variable if it's value could not change, e.g. in >>> >>> exampleToDoArgumentLimitIsExpression >>> | count sum | >>> count := 10. >>> sum := 0. >>> 1 to: count do: [ :each | sum := sum + each]. >>> ^sum >>> >>> It is ok to use count directly as the limit variable, but in this it is not: >>> >>> exampleToDoArgumentLimitIsExpression >>> | count sum | >>> count := 10. >>> sum := 0. >>> 1 to: count do: [ :each | sum := sum + each. count := #somethingElseEntirely]. >>> ^sum >>> >>> _,,,^..^,,,_ (phone) >>> >>> > On Nov 19, 2015, at 1:14 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> > >>> > What is the purpose of replacing expressions, used as limits in a >>> > to:do: call with by a new temporary variable? >>> > >>> > For example: >>> > >>> > OCOpalExamples>>#exampleToDoArgumentLimitIsExpression >>> > the code is >>> > >>> > exampleToDoArgumentLimitIsExpression >>> > | count sum | >>> > count := 10. >>> > sum := 0. >>> > 1 to: count - 1 do: [ :each | sum := sum + each]. >>> > ^sum >>> > >>> > the decompiled bytecode : >>> > >>> > exampleToDoArgumentLimitIsExpression >>> > | tmp1 tmp2 tmp3 | >>> > tmp1 := 10. >>> > tmp2 := 0. >>> > tmp3 := tmp1 - 1. >>> > 1 to: tmp3 do: [ :tmp4 | tmp2 := tmp2 + tmp4 ]. >>> > ^ tmp2 >>> > >>> > So, the expression (count - 1) in the to:do: loop is replaced by a new >>> > temporay (tmp3). >>> > >>> > Ok, but why ? >

Nov. 20, 2015