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

Rubric: spotter with preview leaks some memory
by Nicolai Hess Feb. 1, 2016

Feb. 1, 2016

Open fresh image 50536 Open Spotter, enable preview (cmd+p) search for EllipseMorph dive in instance-methods scroll through the list one item after another. open playground evaluate RubTextLine allInstances size. "553896" case 17421 is related to this, but does not fully solves this. please review and comment on that fix, so we can integrate this soon. The problem sometimes remains even with this fix. The memory (instance count of RubTextLine) just grows in the background

3 8

Unused ugly morph methods...
by stepharo Feb. 1, 2016

Feb. 1, 2016

I really hope that Bloc will forbid such systematic submorphs use because it leads to code like that. Stef submorphNamed: aName ^ self submorphNamed: aName ifNone: [nil] submorphNamed: aName ifNone: aBlock "Find the first submorph with this name, or a button with an action selector of that name" self submorphs do: [:button | | sub args | (button respondsTo: #actionSelector) ifTrue: [button actionSelector == aName ifTrue: [^button]]. ((button respondsTo: #arguments) and: [(args := button arguments) notNil]) ifTrue: [(args at: 2 ifAbsent: [nil]) == aName ifTrue: [^button]]. (button isAlignmentMorph) ifTrue: [(sub := button submorphNamed: aName ifNone: [nil]) ifNotNil: [^sub]]]. ^aBlock value

2 2

Morph should not query Color for nil :(
by stepharo Jan. 31, 2016

Jan. 31, 2016

Morph>>colorString: aColor aColor ifNil: [ ^'nil' ]. ^aColor name ifNil: [ aColor storeString ] ifNotNil: [ :colorName | 'Color ', colorName ] such behavior should be moved to Color. The problem is not Morphic per se. This is that OO design was often not considered. Stef

1 0

ProcessTest>>testSchedulingIsFirstComeFirstServed
by Ben Coman Jan. 31, 2016

Jan. 31, 2016

My general understanding of process scheduling is that it is FIFO within same priority. Indeed Pharo has a test for this ProcessTest>>testSchedulingIsFirstComeFirstServed, which however I thought was a bit fragile and I was looking to revise. But now I'm curious whether same-priority-process FIFO scheduling is an expected guarantee? On both Pharo 5 build 50560 & Squeak 5 build 15113 the following test fails... [ 1 to: 100000 do: [ :n | | ranFirst ranSecond | [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond := 1] ] forkAt: 78. [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond := 2] ] forkAt: 78. ] forkAt: 79. self assert: ranFirst=1. self assert: ranSecond=2. ] ] fork. ... but only after 20k iterations, which seems an "almost" guarantee. Interestingly, it doesn't fail when run without the outer fork. Also if I take an alternate approach with less message calls... faults := OrderedCollection new. done := Semaphore new. [ 1 to: 10000000 do: [ :n | | ranFirst ranSecond | [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond := 1] ] forkAt: 78. [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond := 2] ] forkAt: 78. ] forkAt: 79. (ranFirst=1 and: ranSecond=2) ifFalse: [ faults add: { n . ranFirst . ranSecond } ]. ]. done signal. ] fork. done wait. faults inspect. I only get seven failures in 10 million iterations. "an OrderedCollection( #( 258535 2 1) #(1148605 2 1) #(3502820 2 1) #(4010935 2 1) #(4533713 2 1) #(6301878 2 1) #(8497001 2 1))" So what I'm wondering is if there is a bug to hunt down, or if FIFO scheduling is simply not an expected guarantee? cheers -ben

1 1

Disable assertions (design by contract)
by Aliaksei Syrel Jan. 30, 2016

Jan. 30, 2016

Hi Assertions play an important role in design by contract. It is great to have assertions in Pharo out of box (Object>>#assert:). However in projects with many post- and precondition as also class invariants heavy usage of assertions decreases performance... Would it be possible to have a compiler setting (in setting browser) to enable/disable assertions and not compile them to bytecode? Compiler should ignore the whole assertion statement with removed condition. For example: > self assert: self hugeInvariant. with disabled assertion hugeInvariant must not be sent. Thanks, Alex

12 16

[pharo-project/pharo-core] 2fb151: 50560
by GitHub Jan. 30, 2016

Jan. 30, 2016

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2fb151c3eea6bf2b829178b41fd7b7acb3b664f3 https://github.com/pharo-project/pharo-core/commit/2fb151c3eea6bf2b829178b4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-30 (Sat, 30 Jan 2016) Changed paths: A Deprecated50.package/extension/SmalltalkImage/instance/addDeferredStartupAction_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_after_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_before_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_after_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_before_.st A Deprecated50.package/extension/SmalltalkImage/instance/add_toList_after_.st A Deprecated50.package/extension/SmalltalkImage/instance/add_toList_before_.st A Deprecated50.package/extension/SmalltalkImage/instance/removeFromShutDownList_.st A Deprecated50.package/extension/SmalltalkImage/instance/removeFromStartUpList_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50559.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50560.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50559.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50560.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-BasicCommandLineHandler.package/BasicCommandLineHandler.class/class/system startup/startUp_.st M System-Support.package/SmalltalkImage.class/instance/accessing/session.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changeImagePathTo_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changesFile.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changesName.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changesSuffix.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fileForChangesNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fileForImageNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fullNameForChangesNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fullNameForImageNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imageDirectory.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imageFile.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imagePath.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imagePath_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imageSuffix.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/shortImageName.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourceFileVersionString.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourcesFile.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourcesName.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourcesSuffix.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/vmBinary.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/vmDirectory.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changeImagePathTo_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changesFile.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changesName.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changesSuffix.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fileForChangesNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fileForImageNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fullNameForChangesNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fullNameForImageNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageDirectory.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageFile.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imagePath.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imagePath_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageSuffix.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/shortImageName.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourceFileVersionString.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourcesFile.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourcesName.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourcesSuffix.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/vmBinary.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/vmDirectory.st R System-Support.package/SmalltalkImage.class/instance/snapshot and quit/addDeferredStartupAction_.st M System-Support.package/SmalltalkImage.class/instance/snapshot and quit/snapshot_andQuit_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToShutDownList_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToShutDownList_after_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToShutDownList_before_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToStartUpList_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToStartUpList_after_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToStartUpList_before_.st R System-Support.package/SmalltalkImage.class/instance/startup list/add_toList_after_.st R System-Support.package/SmalltalkImage.class/instance/startup list/add_toList_before_.st R System-Support.package/SmalltalkImage.class/instance/startup list/removeFromShutDownList_.st R System-Support.package/SmalltalkImage.class/instance/startup list/removeFromStartUpList_.st M Zinc-HTTP.package/ZnServer.class/class/system startup/startUp_.st Log Message: ----------- 50560 16735 Replace Startup/Shutdown list with SessionManager https://pharo.fogbugz.com/f/cases/16735 http://files.pharo.org/image/50/50560.zip

1 0

[pharo-project/pharo-core]
by GitHub Jan. 30, 2016

Jan. 30, 2016

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

1 0

ProcessTest>>testHighPriorityOverridesWaitTime intermittent failures
by Ben Coman Jan. 30, 2016

Jan. 30, 2016

Case 17373 had an erroneous failure from ProcessTest>>testHighPriorityOverridesWaitTime and several others seem also to have suffered... * https://pharo.fogbugz.com/default.asp?17373 * https://pharo.fogbugz.com/default.asp?17496 * https://pharo.fogbugz.com/default.asp?17445 * https://pharo.fogbugz.com/default.asp?7444 These have comments that the problem can't be reproduced, which is common of occasional race conditions. So rather than just try to solve this on the issue tracker, I thought I'd share a tip how to isolate and squash such intermittent failures, essentially by stressing that single test a large number of times like this... 1 to: 100 do: [ :n | Transcript crShow: 'Try ' , n printString. ProcessTest debug: #testHighPriorityOverridesWaitTime. ] Since the debugger only focusses on a point in time snapshot of the running system, some Transcript instrumentation was useful to overview the dynamic behaviour, like this... ProcessTest>>testHighPriorityOverridesWaitTime | lowerPriorityWaitingLonger higherPriorityWaitingLess nextReadyProcess | lowerPriorityWaitingLonger := [ ] forkAt: 11 higherPriorityWaitingLess := [ ] forkAt: 12. nextReadyProcess := Processor nextReadyProcess. Transcript cr; tab;show: (lowerPriorityWaitingLonger priority -> lowerPriorityWaitingLonger identityHash); cr; tab;show: (higherPriorityWaitingLess priority -> higherPriorityWaitingLess identityHash); cr; tab;show: (nextReadyProcess priority -> nextReadyProcess identityHash). self assert: nextReadyProcess equals: higherPriorityWaitingLess. which produces... Try 1 11->343137024 12->40659200 12->40659200 Try 2 11->461794304 12->374996992 12->40659200 Observe on the second try nextReadyProcess refers to same process as from the first try. This can be cleaned up just prior to the asset check by adding ... lowerPriorityWaitingLonger terminate. higherPriorityWaitingLess terminate. which produces... Try 1 11->1005688064 12->833273600 12->833273600 ... Try 100 11->764450816 12->807973888 12->807973888 However this is still a little fragile, since some process with priority greater than the running test could slip in before the call to nextReadyProcess, as can be seen by pushing the #to:do: loop out to 100000, which produces... Try 32044 11->784361216 12->431928576 40->397533952 or wrapping it by [ ]forkAt:39, which produces... Try 1 11->431897088 12->400972288 30->338363648 After several awkward failed attempts to fix this, it seemed best to observe actual behaviour rather than peeking into the dynamic data structures. Thus I propose... ProcessTest>>testHighPriorityOverridesWaitTime "The first process to resume will pass straight through the gate while the other waits for the assert to whichRan." | gate checkAssert priorityRan | gate := Semaphore new signal. checkAssert := Semaphore new. [ gate wait. priorityRan := 11. checkAssert signal ] forkAt: 11. [ gate wait. priorityRan := 12. checkAssert signal ] forkAt: 12. checkAssert wait. self assert: priorityRan=12 description: 'Second scheduled but higher priority should run first'. gate signal. checkAssert wait. self assert: whichRan=11 description: 'First scheduled but lower priority should run after'. https://pharo.fogbugz.com/default.asp?17501

2 1

GTDebugger feedback - Setup/TearDown tabs for test cases
by Ben Coman Jan. 30, 2016

Jan. 30, 2016

I really like the SetUp/TearDown tabs when debugging a failed test, however it seems a waste to devote a whole half of window to them causing lines in the Source tab to wrap unnecessarily. Could they be moved adjacent to the Source tab? I guess the Browse button would equally apply to #setUp and #tearDown methods. Also, you can edit the SetUp code but changes don't seem to be saved through. So can this either be fixed (including when the method doesn't exist) or there be some hint it can't be saved: * tab says [SetUp (read-only)] * in an fake comment above its code put "This method is read only" (maybe in light grey) * Instead of the yellow/orange "modified" triangle appearing in the top-right of the pane, make it another colour - maybe black to mean you can't save - I think red is reserved for meaning the pane was edited elsewhere? cheers -ben P.S. I'd like to add my voice to those commenting that the stepping buttons are too far away. Glancing back and forth between them and the code I feel like I'm watching a tennis game. P.P.S The icons on those buttons are real nice.

1 0

Use cases for methods with optional parameters
by Damien Cassou Jan. 30, 2016

Jan. 30, 2016

Hi, I would like to study the impact of adding optional parameters to keyword methods in Pharo. The goal of optional parameters is to facilitate the implementation of methods where some parameters are optional. For example, Seaside has: WAComponent>>request: aRequestString label: aLabelString default: aDefaultString onAnswer: aBlock ... This method of 4 arguments has only 1 required argument (aRequestString) and 3 optional ones. In the current implementation, this results in 7 additional methods that only delegate directly or indirectly to the one above: - request: - request:default: - request:default:onAnswer: - request:label: - request:label:default: - request:label:onAnswer: - request:onAnswer: Before starting to implement anything, I need to know if it makes sense. If you want to help me, please send me all the use cases you have by giving me: - the library name (and URL if not in Catalog), or "pharo" if it's in Pharo - the class where this happens - the range of selectors that make sense For the example above, this would be: - Seaside - WAComponent - request:* Thank you very much -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

6 7