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

Re: [Pharo-dev] Does Pharo stores original author of methods?

by Marcus Denker

> On 20 Nov 2015, at 10:03, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Maybe we should include this information in new changes system (Epicea?) epicea data is not stored forever. It is seasion based and the shipped image is clean. This information needs to be in the repository. That is why one has a repository of code. > > 2015-11-20 13:50 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > > Hi. > > > > Is information about original authors of methods exists in sources of image? > No. > > > I found only authors of last methods modification. Nautilus combobox source/timestamp. > > > > It will be useful to know who introduce some particular method to ask him questions directly. Now when we doing refactoring many methods become touched and this information become lost (searching repositories is not very easy now). > > Yes, repository search needs to be better. But we know that since 10 years. > > Marcus >

Nov. 20, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by Dimitris Chloupis

or just use git *run and hides* On Fri, Nov 20, 2015 at 3:04 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Maybe we should include this information in new changes system (Epicea?) > > 2015-11-20 13:50 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> > On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > >> > Hi. >> > >> > Is information about original authors of methods exists in sources of >> image? >> No. >> >> > I found only authors of last methods modification. Nautilus combobox >> source/timestamp. >> > >> > It will be useful to know who introduce some particular method to ask >> him questions directly. Now when we doing refactoring many methods become >> touched and this information become lost (searching repositories is not >> very easy now). >> >> Yes, repository search needs to be better. But we know that since 10 >> years. >> >> Marcus >> > >

Nov. 20, 2015

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

by Martin Dias

On Fri, Nov 20, 2015 at 2:00 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-11-20 13:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> > On 20 Nov 2015, at 13:03, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> > >> > >> > >> > 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! >> >> Great work, great team ! >> >> Also a bit scary. >> > > No. And yes. > > No, because its inherent to the Pharo scheduler. > > Yes, because anywhere you acquire a non-local lock in Pharo in a process > with less that max priority, it may happen. And that the cooperative nature > of the Pharo scheduler increase the risks. > Ah! DelayMillisecondScheduler should be fixed too.

Nov. 20, 2015

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

by Martin Dias

https://pharo.fogbugz.com/f/cases/17066/Problem-scheduling-delay-from-a-low… On Fri, Nov 20, 2015 at 12:46 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > 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] Does Pharo stores original author of methods?

by Denis Kudriashov

Maybe we should include this information in new changes system (Epicea?) 2015-11-20 13:50 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Hi. > > > > Is information about original authors of methods exists in sources of > image? > No. > > > I found only authors of last methods modification. Nautilus combobox > source/timestamp. > > > > It will be useful to know who introduce some particular method to ask > him questions directly. Now when we doing refactoring many methods become > touched and this information become lost (searching repositories is not > very easy now). > > Yes, repository search needs to be better. But we know that since 10 years. > > Marcus >

Nov. 20, 2015

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

by Thierry Goubier

2015-11-20 13:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 20 Nov 2015, at 13:03, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > > > 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! > > Great work, great team ! > > Also a bit scary. > No. And yes. No, because its inherent to the Pharo scheduler. Yes, because anywhere you acquire a non-local lock in Pharo in a process with less that max priority, it may happen. And that the cooperative nature of the Pharo scheduler increase the risks. Thierry

Nov. 20, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by Marcus Denker

> On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Is information about original authors of methods exists in sources of image? No. > I found only authors of last methods modification. Nautilus combobox source/timestamp. > > It will be useful to know who introduce some particular method to ask him questions directly. Now when we doing refactoring many methods become touched and this information become lost (searching repositories is not very easy now). Yes, repository search needs to be better. But we know that since 10 years. Marcus

Nov. 20, 2015

Does Pharo stores original author of methods?

by Denis Kudriashov

Hi. Is information about original authors of methods exists in sources of image? I found only authors of last methods modification. Nautilus combobox source/timestamp. It will be useful to know who introduce some particular method to ask him questions directly. Now when we doing refactoring many methods become touched and this information become lost (searching repositories is not very easy now).

Nov. 20, 2015

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

by Sven Van Caekenberghe

> On 20 Nov 2015, at 13:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 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! Great work, great team ! Also a bit scary. > 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

[pharo-project/pharo-core] 8232e5: 50455

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8232e53d28e2f093d85a061890fca43f1178f0a3 https://github.com/pharo-project/pharo-core/commit/8232e53d28e2f093d85a0618… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: A Kernel.package/Integer.class/instance/accessing/as31BitSmallInt.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/accessing/text.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/button behavior/addSelectedPackageInSelectedGroup.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/button behavior/emptySelectedGroup.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/button behavior/removeSelectedPackageFromSelectedGroup.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/buttons behavior/addState.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/buttons behavior/removeLabel.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/buttons behavior/renameLabel.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/buildAddButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/buildRemoveButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/buildRenameButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/centering.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/groupTreeBox.st M Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/initialExtent.st R Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/newContentMorph.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/openInWorld.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/display/selectedElements.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/event handling/itemSelected_.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildAddButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildAddSelectedPackageInSelectedGroupButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildEmptyGroupButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildPackageTree.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildRemoveButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildRemoveSelectedPackageFromSelectedGroupButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildRenameButton.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/groupTreeBox.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/newContentMorph.st A Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/packageTreeBox.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/README.md R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/definition.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/accessing/selectedElements.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/button behavior/addSelectedPackageInSelectedGroup.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/button behavior/emptySelectedGroup.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/button behavior/removeSelectedPackageFromSelectedGroup.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/display/centering.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/display/initialExtent.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/display/openInWorld.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/event handling/itemSelected_.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildAddButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildAddSelectedPackageInSelectedGroupButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildEmptyGroupButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildPackageTree.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildRemoveButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildRemoveSelectedPackageFromSelectedGroupButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/buildRenameButton.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/groupTreeBox.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/newContentMorph.st R Nautilus-GroupManagerUI.package/DialogGroupManagerWithPackagesSelectionUI.class/instance/item creation/packageTreeBox.st M Nautilus-GroupManagerUI.package/PackageCreatorTreeModel.class/instance/display/open.st M Nautilus.package/NautilusUI.class/instance/debugging actions/debugTest_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/toggleBreakOnEntryIn_.st R Reflectivity.package/Breakpoint.class/class/instance creation/in_.st R Reflectivity.package/Breakpoint.class/instance/accessing/condition_.st A Reflectivity.package/Breakpoint.class/instance/accessing/level.st A Reflectivity.package/Breakpoint.class/instance/accessing/link.st A Reflectivity.package/Breakpoint.class/instance/accessing/link_.st M Reflectivity.package/Breakpoint.class/instance/api/always.st A Reflectivity.package/Breakpoint.class/instance/api/condition_.st M Reflectivity.package/Breakpoint.class/instance/api/once.st R Reflectivity.package/Breakpoint.class/instance/api/when_.st R Reflectivity.package/Breakpoint.class/instance/initialization/initialize.st A Reflectivity.package/Breakpoint.class/instance/install/install.st R Reflectivity.package/Breakpoint.class/instance/install/installLink_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50454.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50455.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50454.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50455.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/instance/execution/execute.st M SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/breakpoints/breakpointForCondition.st M SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/execution/execute.st Log Message: ----------- 50455 17053 Merge DialogGroupManagerWithPackagesSelectionUI into DialogGroupManagerUI https://pharo.fogbugz.com/f/cases/17053 17059 builder style API for Breakpoint https://pharo.fogbugz.com/f/cases/17059 17058 recompile whole image after compiler change https://pharo.fogbugz.com/f/cases/17058 http://files.pharo.org/image/50/50455.zip

Nov. 20, 2015