[Pharo-project] [enh] Cleaning of and test for MessageTally
Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
thanks On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
alex I saw that you remove contentsChanged from CodeHolder. Is it on purpose? contentsChanged super contentsChanged. self changed: #annotation Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I saw that you remove contentsChanged from CodeHolder. Is it on purpose?
contentsChanged super contentsChanged. self changed: #annotation
No, apparently some problem with the merge. It should not be removed. I update the Slice. Alexandre
On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
You have some duplicated code spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ]. ^ node "^ result" spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ]. closeAfter ifTrue: [ node close ]. ^ node "^ result" It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break. Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I removed the duplicated code in SLICE-MessageTallyCleaningAndTest- Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed). I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example. Cheers, Alexandre On 16 Mar 2010, at 13:24, Stéphane Ducasse wrote:
You have some duplicated code
spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow
| node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock.
openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ].
^ node "^ result"
spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter
| node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock.
openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ].
closeAfter ifTrue: [ node close ].
^ node "^ result"
It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break.
Stef
On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Cool thanks alex. If you understand it well then may be you can write a better comment than mine about the implementation. :) Stef On Mar 16, 2010, at 8:30 PM, Alexandre Bergel wrote:
I removed the duplicated code in SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed).
I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example.
Cheers, Alexandre
On 16 Mar 2010, at 13:24, Stéphane Ducasse wrote:
You have some duplicated code
spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow
| node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock.
openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ].
^ node "^ result"
spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter
| node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock.
openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ].
closeAfter ifTrue: [ node close ].
^ node "^ result"
It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break.
Stef
On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If you understand it well then may be you can write a better comment than mine about the implementation. :)
Writing is like coding: it is an incremental engineering process. I will have a good description because you provided a good foundation. :-) Alexandre
On Mar 16, 2010, at 8:30 PM, Alexandre Bergel wrote:
I removed the duplicated code in SLICE-MessageTallyCleaningAndTest- Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed).
I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example.
Cheers, Alexandre
On 16 Mar 2010, at 13:24, Stéphane Ducasse wrote:
You have some duplicated code
spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow
| node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock.
openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ].
^ node "^ result"
spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter
| node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock.
openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ].
closeAfter ifTrue: [ node close ].
^ node "^ result"
It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break.
Stef
On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote:
Waiting in PharoInbox. This fix has been developed in a 11271.
SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1
This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window.
ToolsTest contains few and simple tests.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (2)
-
Alexandre Bergel -
Stéphane Ducasse