April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello/ftp stopped working for me

by Alexandre Bergel

Thanks Johan for such a deep insight. You're probably very close to the truth. I modified the priority of the finalization process to 61. The socket problem just vanished. It is hard to see whether this is a hack or this process should be at a higher priority by design. I googled a bit about finalization and priority processes to see whether java people have a similar issue, but I haven't find something relevant yet. Cheers, Alexandre On 30 Apr 2009, at 05:40, John M McIntosh wrote: > Further to this I"m wondering if there is something else "clever" > going on. > > Should the finalization process run at priority 61? See > WeakArray>>restartFinalizationProcess > Perhaps someone can check that? > > Let me ramble on... > > In the past you had the event polling going on at prioirty 40 in the > 'UI process' > That would grind away... > > You also had the 'event tickler' that ran every 500 ms at priority 60. > > And there in the middle why the key player here, the 'WeakArray > finalization process' at 50 > > In this problem area, if we consider the socket creation fails because > the number of sockets allocated has reached the limit (aka unix limit) > not seen in windows. > then this is because either (a) we are actualy holding onto thousands > of sockets on purpose? > Or we have 1, and thousands of zombies that have been tenured to > OldSpace but not yet GCed, and Unix is unhappy with us. > > Now when the socket create fails that causes well another pointless > attempt at creation (why?) but also a full GC. > The full GC will of course signal to the 'WeakArray finalization > process' for it to gently destroy sockets. > > But let's consider what's NEW here is the 'input events fetching > process' is now running at 2x the speed of the older UI process and > consuming 10-30% of the cpu? > I'm not sure why before it was acceptable to look every 1/50 second, > but now it has to be every 1/100 of a second. > > But it's interesting that it''s running at priority 60, which means > it's sucking CPU away from the weak array finalization process. > > Now as we know the weak array finalization process is rather cpu > intensive, so I wonder if there is just enough CPU taken away from > finalization process > so that it can't do enough work before the retry for the socket > allocation leaps in and fails for a final time? > > Well of course I'm not sure why the finalization process wouldn't > finalize all the zombie sockets in one go when the full gc completes, > but that would require some more testing... > > > On 29-Apr-09, at 8:09 PM, John M McIntosh wrote: > >> Er maybe someone doing the testing can stick a >> Socket allInstances size inspect >> in at the pointer where the exception is signaled. I think it would >> be enlightening what the value is. >> >> On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote: >> >>> Socket status must Unconnected before opening a new >>> connection >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 30, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by Damien Cassou

On Thu, Apr 30, 2009 at 8:53 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> In pharo webpage where it says "archive and more...". It is a link >> to this: >> http://gforge.inria.fr/frs/?group_id=1299 > > I updated the web page to make this more clear. I've changed it again a little: - re-add the "archive and more..." link because it can still be useful to people wanting older versions of Pharo - add a new paragraph in Pharo-Core which says that "you probably don't want this" :-) -- Damien Cassou http://damiencassou.seasidehosting.st

April 30, 2009

Re: [Pharo-project] tests for Collection classes

by Damien Cassou

On Thu, Apr 30, 2009 at 10:33 AM, Cyrille Delaunay <cyrille.delaunay(a)etudiant.univ-lille1.fr> wrote: > Hello > > I'm Cyrille Delaunay, I work for the RMOD Inria team. > I'm currently working on tests for the Pharo Collection Library using traits. > I've modified, added some traits and therefore redifined things in > test classes to attempt to get a best coverage. > (For the moment : Arraytest , BagTest , DictionaryTest , IntervalTest > , OrderedCollectionTest , SetTest , SortedCollectionTest StringTest , > SymbolTest , LinkedListTest ). > All modification have been saved in 'PharoTaskForces'. > With a static coverage tool (also saved in PharoTaskPhorces ) removing noise > for each class (methods defined too high in hierarchy that are not > appropriated , > private methods , Â very specific methods that may should not be tested > for collection Â ), I got those coverage : Hi Cyrille, thank you very much. This is very nice work. Hope to see that in Pharo soon. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st

April 30, 2009

Re: [Pharo-project] Slow Image

by Damien Cassou

On Wed, Apr 29, 2009 at 6:24 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Damien Cassou wrote: >> On Tue, Apr 28, 2009 at 2:35 PM, Â <stephan(a)stack.nl> wrote: >>>> Anyone with a win32 system able to confirm that the new image slows >>>> heavily down as descibed in [1] using the procedure in [2]? >> >> I confirm it's very slow using Windows XP Pro SP3 on Virtual Box, image 10293. > > does someone have a somewhat smaller load sequence we could use to > benchmark the difference? Something that runs in a few minutes? 20 minutes on my Ubuntu/Linux 9.04 -- Damien Cassou http://damiencassou.seasidehosting.st

April 30, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by Simon Denier

On 30 avr. 09, at 09:53, David RÃ¶thlisberger wrote: > Hi, > > You can post the bug notification to omnibrowser- > dev(a)googlegroups.com and/or upload > your patch to http://source.wiresong.ca/ob. Thanks. Good to know there is such a group. Registered. > > Concerning this particular bug: > I don't understand what you mean with 'cancel button'? Where do you > get such a > button, what is its behavior compared to the cancel option? I do get the button, which I think is quite standard for such pop up. It is the one next to the search field. Indeed, the cancel option cancels the user exit and come back to the edit panel with unsaved changes, while the cancel button works like the discard option, discarding the unsaved changes. BTW, any hint about how to introduce return line in pop up title? :) > > > David > >> However, I see this is related to OB. >> It's not really a package of the core pharo, but rather an external >> one included in Damien development images. >> Such external package has its own maintainer and is not maintained >> by >> pharo team. >> You should post to the appropriate code repository and mailing >> list... >> (a good soul in this list will have to tell you which one, because I >> don't know it) >> >> Cheers >> >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >>> ok then, no problem. >>> BTW, I'd like somebody to look at the fix I made because I'm not >>> sure that >>> is the right way to doit. I mean, it is rare how the exception is >>> related to >>> the dialog box. I think it is done that way because the handler of >>> the >>> notification could not show a dialog... but if that is the idea >>> then I think >>> something is missing to relate the cancel option of the >>> notification with >>> the cancel button of the dialog. >>> >>> On Wed, Apr 29, 2009 at 12:39 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> Not annoying at all. Please do. >>>> >>>> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >>>>> Another fix... >>>>> (Do I have to send a mail to the list per fix? the how to >>>>> contribute >>>>> page >>>>> says so but it can be annoying...) >>>>> Hernan. >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Simon

April 30, 2009

[Pharo-project] tests for Collection classes

by Cyrille Delaunay

Hello I'm Cyrille Delaunay, I work for the RMOD Inria team. I'm currently working on tests for the Pharo Collection Library using traits. I've modified, added some traits and therefore redifined things in test classes to attempt to get a best coverage. (For the moment : Arraytest , BagTest , DictionaryTest , IntervalTest , OrderedCollectionTest , SetTest , SortedCollectionTest StringTest , SymbolTest , LinkedListTest ). All modification have been saved in 'PharoTaskForces'. With a static coverage tool (also saved in PharoTaskPhorces ) removing noise for each class (methods defined too high in hierarchy that are not appropriated , private methods , very specific methods that may should not be tested for collection ), I got those coverage : Arraytest : tested at 94.5 % BagTest : 88.4 % DictionaryTest: 85 % IntervalTest : 93 % OrderedCollectionTest : 93.9% SetTest : 85.9% SortedCollectionTest : 92.3 % StringTest : 91% LinkedListTest : 90.5 % Here are the more important modifications i've made about traits : -> new trait TConvertTest : testing converting methods (such that 'asArray,' asBag', .. ) -> new trait 'TSortTrait' : testing sorting methods for 'ArrayedCollection'. -sort -sort: -isSorted -isSortedBy: -> new trait: 'TCopySequenceable' : testing copying methods using an order, an index access (copyAfter: for example) -> new trait 'TOccurrencesTest' : testing method : -> OccurencesOf: -> new trait: TIterateSequencedReadableTest' testing iterating methods using a specific order ( usable therefore only by sequenceable collection ) -> new trait: 'TConcatenaionTest' Bad initial version (specific to sequenceable collection) Split into two trait: -> TSequencedConcatenationTest (initial version) -> TConcatenationTest (to do) - > new trait: 'TReplacementSequencedTest' testing replacemnt methods : - replaceAll:with: - replaceFrom:to:with: - replaceFrom:to:with:startingAt: for Sequenced Collection -> Modification of all the methods in 'TIndexAccessingTest' making them independent of elements in collection's Type.( so that it can be used with all type of sequenceable collection like 'String'). -> -> modification of all the tests in 'TAsStringAndDelimiterTest' making its independent of the elements' type in collection. 'TAsStringAndDelimiterTest' added to 'ArrayTest'. -> redefinition of 'TAsStringCommaAndDelimiterTest' which were specific to sequenceable collection (and didn't work for 'BagTest'). The initial version has been kept in a new trait: 'TAsStringCommaAndDelimiterSequenceableTest'. -> with new trait: 'TBeginsEndsWith' testing methods: - beginsWith: - endsWith: -> Remodularisation of the initial trait 'TIndexAccessing' (which became to big) Split into three traits: - methods like 'indexOf' added to the New trait 'IndexAccess' . - methods concerning 'SubCollectionAccess' added to a new trait: 'TSubCollectionAccess'. - methods concerning elements access added to a new trait : 'TSequencedElementAccessTest' -> new trait: 'TPrintTest' testing 'stream printing' methods Modification of TPrintTest wich was specific to sequenceable collections. Initial version has been kept in a new trait : TPrintSequencedTest -> Modification of TConvertTest wich tested some methods (asSet, asIdentitySet) for duplicate contents what can't work for Interval or Collection without equel elements. Creation of a new trait : 'TConvertAsSetForMultiplinessTest'. -> Remodularisation of TCopySequenceableTest wich were too big. Creation of a new trait : -> TCopySequenceableSameContents testing copying methods that only change the order of elements and don't remove or add any elements to the copy. -> TCopyPartOfSequenceable testing copying methods that only copy a part of a collection (copyAfter: copyUpTo: ) -> TCopySequenceableWithOrWithoutSpecificElements testing copying methods ( from the initial trait TCopySequenceable ) that copy the collection with more or less specified elements . -> 'TCopySequenceableWithReplacement' testing copying methods ( from the initial version of TSequenceableTest ) that copy and replace subcollections in the receiver. -> Refinition of all tests in TIndexAccess so that they required a simple collection without equal element and test the 'Standard' comportement that come with. Therefore, it can be used by collections that don't allowed duplicate elements. The aspect of 'multiple occurrences' was puted into a new trait: TIndexAccessForMultipliness ( this aspect is important for 'lastIndexOf:' or 'identityIndexOf:' for exemple ) -> modification of all methods in TAddTest. those methods used always directly 'self collection' to test if an element had been added . For example : self assert: self collection size = oldsize + 1 That didn't work if required methods returned a new object at each time and not an instance variable of the classTest. TAddTest use now its own copies of required collection to be independant of the way the method is given by the ClassTest. -> new trait: - TRmoveByIndexTest testing methods for removing by index access (used at least by OrderedCollection and SortedCollection) -> new trait: - TCopyPartOfSequenceableForMultipliness testing the specific comportement with duplicate for methods in TCopyPartOfSequenceable. TCopyPartOfSequenceable can now be used by collection that don't allowed duplicate elements. -> new traits : - TCopySequenceableWithReplacementForSorted testing specific comportement of methods like 'copyReplaceAll:with:' for sorted collection. -> redefinition of trait : 'TIterateTest' (in a new trait 'TIterateNew'). This trait required a specific collection of integer and many tests depended on the fact that elements were SmallInteger. As this trait test iterating methods for all collections ( it is used by 'CollectionRootTest' ), it should work for every kind of collection and therfore every kind of elements in ( it should, for example, work for 'LinkedList' that use 'Link' elements ) The new trait work now for 'LinkedListTest'. -> Modification of all tests in 'TIterateSequencedReadableTest' ( in the same way and for the same reasons than 'TItereateTest' ) -> Modification of test: testAsCommaStringMore in trait 'TAsStringCommaAndDelimiterSequenceableTest' so that it works also with elements for wich 'asString' return a String including ' '. (for example: Link new asSTring returns: 'a Link') -> TConvertTest split into two Traits. All methods converting into a sorted collection are now tested in a new trait: TConvertAsSortedTest so that collections that can't include 'sortable' elements (LinkedList for example ) can use TConvertTest. TConvertAsSorted is specific to collection that can include sortable elements. -> Modification of TConvertTest wich tested some methods (asSet, asIdentitySet) for duplicate contents what can't work for Interval or Collection without equel elements. Creation of a new trait : 'TConvertAsSetForMultiplinessTest'. -> Remodularisation of TCopySequenceableTest wich were too big. Creation of a new trait : -> TCopySequenceableSameContents testing copying methods that only change the order of elements and don't remove or add any elements to the copy. -> TCopyPartOfSequenceable testing copying methods that only copy a part of a collection (copyAfter: copyUpTo: ) -> TCopySequenceableWithOrWithoutSpecificElements testing copying methods ( from the initial trait TCopySequenceable ) that copy the collection with more or less specified elements . -> 'TCopySequenceableWithReplacement' testing copying methods ( from the initial version of TSequenceableTest ) that copy and replace subcollections in the receiver. -> Refinition of all tests in TIndexAccess so that they required a simple collection without equal element and test the 'Standard' comportement that come with. Therefore, it can be used by collections that don't allowed duplicate elements. The aspect of 'multiple occurrences' was puted into a new trait: TIndexAccessForMultipliness ( this aspect is important for 'lastIndexOf:' or 'identityIndexOf:' for exemple ) -> modification of all methods in TAddTest. those methods used always directly 'self collection' to test if an element had been added . For example : self assert: self collection size = oldsize + 1 That didn't work if required methods returned a new object at each time and not an instance variable of the classTest. TAddTest use now its own copies of required collection to be independant of the way the method is given by the ClassTest. -> new trait: - TRmoveByIndexTest testing methods for removing by index access (used at least by OrderedCollection and SortedCollection) -> new trait: - TCopyPartOfSequenceableForMultipliness testing the specific comportement with duplicate for methods in TCopyPartOfSequenceable. TCopyPartOfSequenceable can now be used by collection that don't allowed duplicate elements. -> new traits : - TCopySequenceableWithReplacementForSorted testing specific comportement of methods like 'copyReplaceAll:with:' for sorted collection. -> redefinition of trait : 'TIterateTest' (in a new trait 'TIterateNew'). This trait required a specific collection of integer and many tests depended on the fact that elements were SmallInteger. As this trait test iterating methods for all collections ( it is used by 'CollectionRootTest' ), it should work for every kind of collection and therfore every kind of elements in ( it should, for example, work for 'LinkedList' that use 'Link' elements ) The new trait work now for 'LinkedListTest'. -> Modification of all tests in 'TIterateSequencedReadableTest' ( in the same way and for the same reasons than 'TItereateTest' ) -> Modification of test: testAsCommaStringMore in trait 'TAsStringCommaAndDelimiterSequenceableTest' so that it works also with elements for wich 'asString' return a String including ' '. (for example: Link new asSTring returns: 'a Link') -> TConvertTest split into two Traits. All methods converting into a sorted collection are now tested in a new trait: TConvertAsSortedTest so that collections that can't include 'sortable' elements (LinkedList for example ) can use TConvertTest. TConvertAsSorted is specific to collection that can include sortable elements.

April 30, 2009

[Pharo-project] Enhanced ContextPartOn printReportOn: from John McIntosh

by StÃ©phane Ducasse

> > I've attached a ContextPart>>errorReportOn: we use to print more > information, the current one dates from the last decade of the last > century and really > provides too little data on the instance variables and stack size. > For example if we could see all of files: we chould see if the > pier.changes file is there. >>>> >>>> > > > ContextPart>>errorReportOn: strm > "Write a detailed error report on the stack (above me) on a > stream. For both the error file, and emailing a bug report. > Suppress any errors while getting printStrings. Limit the length." > > | cnt aContext startPos | > strm print: Date today; space; print: Time now; cr. > strm cr. > strm nextPutAll: 'VM: '; > nextPutAll: SmalltalkImage current platformName asString; > nextPutAll: ' - '; > nextPutAll: SmalltalkImage current platformSubtype asString; > nextPutAll: ' - '; > nextPutAll: SmalltalkImage current osVersion asString; > nextPutAll: ' - '; > nextPutAll: SmalltalkImage current vmVersion asString; > cr. > strm nextPutAll: 'Image: '; > nextPutAll: SystemVersion current version asString; > nextPutAll: ' ['; > nextPutAll: SmalltalkImage current lastUpdateString asString; > nextPutAll: ']'; > cr. > strm cr. > SecurityManager default printStateOn: strm. > > "Note: The following is an open-coded version of > ContextPart>>stackOfSize: since this method may be called during a > low space condition and we might run out of space for allocating the > full stack." > cnt := 0. startPos := strm position. > aContext := self. > [aContext notNil and: [(cnt := cnt + 1) < 40]] whileTrue: > [aContext printDetails: strm. "variable values" > strm cr. > aContext := aContext sender]. > > strm cr; nextPutAll: '--- The full stack ---'; cr. > aContext := self. > cnt := 0. > [aContext == nil] whileFalse: > [cnt := cnt + 1. > cnt = 40 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - -'; cr]. > strm print: aContext; cr. "just class>>selector" > > strm position > (startPos+150000) ifTrue: [strm nextPutAll: > '...etc...'. > ^ self]. "exit early" > cnt > 200 ifTrue: [strm nextPutAll: '-- and more not shown --'. ^ > self]. > aContext := aContext sender]. > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki

April 30, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by StÃ©phane Ducasse

On Apr 29, 2009, at 11:40 PM, Hernan Wilkinson wrote: > ups... another question then... where is a list of core pharo > packages? if you open monticello in core you get the core packages. There are stored in Pharo on SqueakSource. > I saw there is a pharo-core image and a pharo (or pharo-dev) image. > I could not find the pharo-core image, the one in the download page > is the pharo-dev image. > > Thanks > Hernan. > > On Wed, Apr 29, 2009 at 2:22 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com > > wrote: > However, I see this is related to OB. > It's not really a package of the core pharo, but rather an external > one included in Damien development images. > Such external package has its own maintainer and is not maintained by > pharo team. > You should post to the appropriate code repository and mailing list... > (a good soul in this list will have to tell you which one, because I > don't know it) > > Cheers > > 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > ok then, no problem. > > BTW, I'd like somebody to look at the fix I made because I'm not > sure that > > is the right way to doit. I mean, it is rare how the exception is > related to > > the dialog box. I think it is done that way because the handler of > the > > notification could not show a dialog... but if that is the idea > then I think > > something is missing to relate the cancel option of the > notification with > > the cancel button of the dialog. > > > > On Wed, Apr 29, 2009 at 12:39 PM, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > >> Not annoying at all. Please do. > >> > >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > >> > Another fix... > >> > (Do I have to send a mail to the list per fix? the how to > contribute > >> > page > >> > says so but it can be annoying...) > >> > Hernan. > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 30, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by David RÃ¶thlisberger

Hi, You can post the bug notification to omnibrowser-dev(a)googlegroups.com and/or upload your patch to http://source.wiresong.ca/ob. Thanks. Concerning this particular bug: I don't understand what you mean with 'cancel button'? Where do you get such a button, what is its behavior compared to the cancel option? David > However, I see this is related to OB. > It's not really a package of the core pharo, but rather an external > one included in Damien development images. > Such external package has its own maintainer and is not maintained by > pharo team. > You should post to the appropriate code repository and mailing list... > (a good soul in this list will have to tell you which one, because I > don't know it) > > Cheers > > 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> ok then, no problem. >> BTW, I'd like somebody to look at the fix I made because I'm not sure that >> is the right way to doit. I mean, it is rare how the exception is related to >> the dialog box. I think it is done that way because the handler of the >> notification could not show a dialog... but if that is the idea then I think >> something is missing to relate the cancel option of the notification with >> the cancel button of the dialog. >> >> On Wed, Apr 29, 2009 at 12:39 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> Not annoying at all. Please do. >>> >>> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >>>> Another fix... >>>> (Do I have to send a mail to the list per fix? the how to contribute >>>> page >>>> says so but it can be annoying...) >>>> Hernan. >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 30, 2009

Re: [Pharo-project] run all tests from superClass

by StÃ©phane Ducasse

On Apr 30, 2009, at 8:08 AM, Nicolas Cellier wrote: > The question is not at all to know if class B inherits from class A. > It is that class A and B respond to a common API, whatever the > implementation - inheritance or not. > In this case, TestA and TestB share a common test protocol for testing > the same API. Thanks for answering for me :) By inheriting I do not bind BagIdentitySet to BagTest. I reuse what can be reused. > That's why Stef & al started rewriting collection tests by composition > with traits. > The other more traditional, much simpler (toolwise) but less powerfull > way is to use inheritance, so the question makes sense. especially since we want to minimize duplicated code > What I read here indicates you prefer maintaining many duplicates of > the test. > And when you realize that one of the test was buggy (not the method > that is tested, but the test itself), you certainly prefer to track > all the copies and probably leave a buggy one here and there... > > Rethorical debates are fine, but it would be more enlightning to > discuss around some chosen examples. The new tests for Collections are (soon a bit more clean) in PharoTaskForces in MC. We are starting to have a good coverage and a set of traits. The idea is that soon we will be able to test new collection classes by aggregating trait tests. Stef > 2009/4/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: >> Hernan Wilkinson wrote: >>> I don't think it is a good idea to have hierarchies with test >>> cases... >>> depending on how you are doing it, it could couple the test >>> hierarchy >>> with the model hierarchy and I don't think that is a good idea... >>> It also introduces some complexity, for example the number of >>> tests are >>> not only the test methods but for each concrete test class, the test >>> methods on it plus the test methods of the abstract >>> superclasses... hmmm >>> I don't know, it is not natural at least for me too user inheritance >>> with tests... >> >> +1 >> Besides, one of the goals of the testing is to test "external >> behavior" >> of the classes. >> This means, to me, that the test cases must test the classes without >> knowing if B inherits from A o if both B and C are subclasses of A. >> This way, when you for some reason must refactor or reorganize your >> classes, the test will not break as long as the external behavior of >> them remains unchanged. >> >> Summary, the inheritance of the classes tested is just an >> implementation >> detail, not something the test cases must care of. >> >> Cheers, >> Miguel CobÃ¡ >>> >>> On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> >>> wrote: >>> >>> HI guys >>> >>> I was coding this afternoon with Cyrille who is working a lot to >>> improve the test coverage of collections. >>> And we found a bit strange that when a testcase inherits from >>> another >>> one the tests of the superclass are not run. >>> I checked a bit SUnit code and superclass testmethods are only >>> run is >>> the superclass is abstract or if there are not testmethods. >>> Imagine >>> BagTest >>> IdentityBagTest >>> >>> >>> We could redefine buildSuite on BagTest to invoke allSelectors >>> but this means in essence that we could do it on a lot of >>> potential >>> testcase classes that may be subclasses. >>> >>> Or we could redefine buildSuite on IdentyBagTest but this >>> means that >>> the subclasses should specify it. >>> May be this solution is the best but I wanted to get your >>> thoughts. >>> >>> Of course this idea of inheriting test case make sense when >>> superclass >>> setup can be reused in subclasses one. >>> So the default behavior of buildSuite always invoking all >>> testmethods >>> may not be so good but then >>> via subclassing from BagTest if this is not to reuse it. >>> >>> Stef >>> >>> >>> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: >>> >>> > A change have been saved in 'PharoInBox' for class TestCase >>> in >>> > package SUnit >>> > so that suite are now built from allSelectors. >>> > This makes sense when you have testcase classes which >>> inherits from >>> > each other and have parametrized (hook-based) setup. >>> > >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@lists.gforge.inria.fr> >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009