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

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by StÃ©phane Ducasse

Yes now. I think that knowing in the browser the status of a test is really urgent. Seriously not knowing is really slowing me down. Then with the same kind of reasoning we would not integrated the improvements that alex and lukas did to MC browser and they are really great! So we should just be opportunistic. and this is also true that looking at what keith did is on my list. Stef On Nov 8, 2008, at 11:00 AM, Marcus Denker wrote: > Hi, > > In general, we should distinguish between "development" and > "integration into pharo". > It makes no sense to harvest broken things. If sunit needs > improvement, start a sunit > improvement branch. Then, when it is stable, we can integrate. > > And, we then have a chance to think if we actually want a change or > not. > > Marcus > > > On 08.11.2008, at 08:16, StÃ©phane Ducasse wrote: > >> I moved it into treatedInbox. >> We cannot keep broken elements in the inobox, especially since >> marcus or adrian or nicolas >> may have a look at it again. >> We do not have time for losing it three or four times. >> >> For us this is really important that we keep it clean else we can >> lose control. >> anything that somebody put in treated inbox will end up either in >> >> Is it clear? >> If you try to do our job you will really fast see how it can get >> frustrating >> - not knowing what is a changes >> - not knowing whether it works >> - not knowing whether is works but breaks something else. >> and taking responsibility for the mess we can put. >> >> So take 2 min to think about that and you will see what we are >> doing and why. >> We can do an harvesting session with anybody so that we share the >> feel >> >> Stef >> >> On Nov 7, 2008, at 8:37 PM, Alexandre Bergel wrote: >> >>>> When I load SUnit in pharoBox >>> >>> There is no SUnit package in PharoInbox. >>> Are you referring to SUnitGUI-AlexandreBergel.15.mcz in Pharo? >>> Obviously we should not have saved this file in Pharo, but in >>> PharoInbox rather. I apologize for this. >>> >>> SUnitGUI-AlexandreBergel.15.mcz expects the method >>> generateLastRunMethodNamed:for: to be present. This method is >>> provided by two packages that may be found in PharoTreatedInbox. >>> >>> However there is something strange, the following method has >>> disappeared from the image (I tried with an Core 10133 updated): >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> TestResult>>runCase: aTestCase >>> | testCasePassed | >>> testCasePassed := true. >>> [[aTestCase runCase] >>> on: self class failure >>> do: >>> [:signal | >>> failures add: aTestCase. >>> testCasePassed := false. >>> signal return: false]] >>> on: self class error >>> do: >>> [:signal | >>> errors add: aTestCase. >>> testCasePassed := false. >>> signal return: false]. >>> testCasePassed ifTrue: [passed add: aTestCase] >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Is there any reason for this? Our extension on storing results >>> will have to be updated then... >>> >>> Alexandre >>> >>>> >>>> I cannot run tests anymore! >>>> David Alex can you really check? >>>> >>>> Guys I appreciate your work but it would be great if you could >>>> test more >>>> what you are doing because I spent a lot of time on problems like >>>> that. >>>> >>>> Stef >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by Damien Cassou

On Fri, Nov 7, 2008 at 5:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I will move the rest to treated. > Except I you shout and tell me that your code is ready for integration. Does it mean you will ignore everything but these 3 fixes? I don't understand why. If you don't have time, just don't harvest them. -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 8, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by Marcus Denker

Hi, In general, we should distinguish between "development" and "integration into pharo". It makes no sense to harvest broken things. If sunit needs improvement, start a sunit improvement branch. Then, when it is stable, we can integrate. And, we then have a chance to think if we actually want a change or not. Marcus On 08.11.2008, at 08:16, StÃ©phane Ducasse wrote: > I moved it into treatedInbox. > We cannot keep broken elements in the inobox, especially since > marcus or adrian or nicolas > may have a look at it again. > We do not have time for losing it three or four times. > > For us this is really important that we keep it clean else we can > lose control. > anything that somebody put in treated inbox will end up either in > > Is it clear? > If you try to do our job you will really fast see how it can get > frustrating > - not knowing what is a changes > - not knowing whether it works > - not knowing whether is works but breaks something else. > and taking responsibility for the mess we can put. > > So take 2 min to think about that and you will see what we are doing > and why. > We can do an harvesting session with anybody so that we share the feel > > Stef > > On Nov 7, 2008, at 8:37 PM, Alexandre Bergel wrote: > >>> When I load SUnit in pharoBox >> >> There is no SUnit package in PharoInbox. >> Are you referring to SUnitGUI-AlexandreBergel.15.mcz in Pharo? >> Obviously we should not have saved this file in Pharo, but in >> PharoInbox rather. I apologize for this. >> >> SUnitGUI-AlexandreBergel.15.mcz expects the method >> generateLastRunMethodNamed:for: to be present. This method is >> provided by two packages that may be found in PharoTreatedInbox. >> >> However there is something strange, the following method has >> disappeared from the image (I tried with an Core 10133 updated): >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> TestResult>>runCase: aTestCase >> | testCasePassed | >> testCasePassed := true. >> [[aTestCase runCase] >> on: self class failure >> do: >> [:signal | >> failures add: aTestCase. >> testCasePassed := false. >> signal return: false]] >> on: self class error >> do: >> [:signal | >> errors add: aTestCase. >> testCasePassed := false. >> signal return: false]. >> testCasePassed ifTrue: [passed add: aTestCase] >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> Is there any reason for this? Our extension on storing results will >> have to be updated then... >> >> Alexandre >> >>> >>> I cannot run tests anymore! >>> David Alex can you really check? >>> >>> Guys I appreciate your work but it would be great if you could >>> test more >>> what you are doing because I spent a lot of time on problems like >>> that. >>> >>> Stef >>> >>> >>> >>> _______________________________________________ >>> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 8, 2008

Re: [Pharo-project] Monticelle renaming (was I would like to clean the inbox! Please read)

by Noury Bouraqadi

Thanks Lukas for the feedback. Now I have some questions: -For fuctionality 1 : Because of the dependency with the RefactoringBrowser, which obviously shouldn't be in the core image. Does it make sense to have it in an external package ? It's handy to avoid using multiple tools when renaming a Monticello Package and the corresponding class prefixes. But, may be should I reimplement without reusing the RefactoringBrowser ? -Is fuctionality 2 useful for other people than me ? Fixing the issues you identified wouldn't be a big challenge. Noury On 7 nov. 08, at 22:26, Lukas Renggli wrote: > The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu > items into the Monticello Browser, by overriding and extending several > methods in Monticello. If this code is included with Pharo, it should > become part of Monticello itself. There are 4 test cases included. > > Below I review the two new functionalities independently: > > 1. Replace Classes Prefix: This functionality is useful, however the > implementation depends on the presence of the Refactoring Browser. > Furthermore this functionality is already present in the Refactoring > Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class > allows one to batch rename, batch copy and batch create a set of > classes using regular expressions. > > 2. Rename Package: This functionality renames class categories and > method protocols to match the new package name. The code also takes > care of the dependencies and removing traces of the old package in the > Monticello Browser. It does not depend on external functionality. > There are however 3 major problems with the implementation: (1) Class > extensions extinct if they do not match the package names in a > case-sensitive way. PackageInfo treats class categories > case-sensitive, but protocols are handled case-insensitive. (2) > Packages that share the same prefix are wrongly renamed, even if > PackageInfo does not consider them to be from the same package (for > example Morphic and MorphicExtras). (3) The ancestry of the renamed > package is not preserved, what makes merging packages across renaming > impossible. Though, I don't know if such a functionality would be > possible with Monticello at all? > > Given the number of problems I don't suggest to include these > extensions for now. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Nov. 8, 2008

Re: [Pharo-project] About Pharo - text to go with version 1.0

by Stefan Schmiedl

On Fri, 7 Nov 2008 21:50:27 +0100 "Matthias Berth" <matthias.berth(a)googlemail.com> wrote: > Damien, Stefan, > > > thanks for the comments - good points. I have tried to improve the > text, see > > http://code.google.com/p/pharo/wiki/GettingStartedAbout > > It now has a list of packages that Pharo includes and another list of > things that are not included. Newcomers can ignore these. Nice and clear, starting with understandable stuff, while ending on a technical upbeat :-) Good work! s.

Nov. 8, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by StÃ©phane Ducasse

thanks lukas On Nov 7, 2008, at 10:26 PM, Lukas Renggli wrote: > The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu > items into the Monticello Browser, by overriding and extending several > methods in Monticello. If this code is included with Pharo, it should > become part of Monticello itself. There are 4 test cases included. > > Below I review the two new functionalities independently: > > 1. Replace Classes Prefix: This functionality is useful, however the > implementation depends on the presence of the Refactoring Browser. > Furthermore this functionality is already present in the Refactoring > Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class > allows one to batch rename, batch copy and batch create a set of > classes using regular expressions. > > 2. Rename Package: This functionality renames class categories and > method protocols to match the new package name. The code also takes > care of the dependencies and removing traces of the old package in the > Monticello Browser. It does not depend on external functionality. > There are however 3 major problems with the implementation: (1) Class > extensions extinct if they do not match the package names in a > case-sensitive way. PackageInfo treats class categories > case-sensitive, but protocols are handled case-insensitive. (2) > Packages that share the same prefix are wrongly renamed, even if > PackageInfo does not consider them to be from the same package (for > example Morphic and MorphicExtras). (3) The ancestry of the renamed > package is not preserved, what makes merging packages across renaming > impossible. Though, I don't know if such a functionality would be > possible with Monticello at all? > > Given the number of problems I don't suggest to include these > extensions for now. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by StÃ©phane Ducasse

Keith I forwarded the mail because it is interesting for everybody. >> >>> The situation is getting messy. Not really Code does not work -> moved to treatedInbox and we pass to the next items. >>> >>> >>> Cheers, >>> Alexandre >> exactly... everyone doing their own thing for their own reasons. Will >> you be willing to help restore some coherence to the picture. >> >> I set a few goals that are fulfilled in my derived implementation. My >> improvements are based upon more than 10 years of experience of using >> SUnit and things like it. These have been out there for 2 years, so >> there is no reason why people cannot build upon this base. >> >> 1. Ability to define test suites, and have a UI for running test >> suites. >> I have been using this facility for 8 years in st/x and always miss >> it >> in squeak. I want to be able to define a suite for "My Project". >> >> 2. Ability to flag which tests are expected to work in which >> situation, >> which image version and which platform. So that I can run with "all >> tests green" even if I happen to have a few windows specific tests, >> when >> I am running on a mac. >> >> 3. Ability to use tests to specify behaviour and requirements even >> before the tests work. I.e. mark tests as #toDo. >> >> 4. Ability to run tests in an automated tool, without a UI. >> >> 5. Ability to sort tests so that they are run fastest first. 95% of >> the >> tests will run in 10% of the time. >> >> 6. Ability to determine whether a test used the network or not, and >> filter out those tests if necessary. >> >> 7. Ability to integrate other testing technologies like SSpec. (not >> actually done, but conceptually possible now) >> >> A couple of other improvements are also included, such as the >> ability to >> define a custom exception handler around all of your tests. >> >> In my opinion some members of the Pharo team have a big problem with >> "Not Invented Here". They don't even look at the existing stuff >> before >> diving in. Keith let me reply friendly - I mentioned several times that we want to have a look but my time is quite short. if people in the community take time to have a real look at your extensions and how we can integrate them, and write a report the item will move higher up in our todo. >> I spent several months integrating the fixes from 3 separate >> streams of >> Monticello, specifically with the goal of promoting coherence >> within all >> of the the squeak communities. I did this work for the benefit of all >> squeak users, not for the benefit of my health or financial well >> being. >> In fact it has cost me several thousands of pounds in lost revenue. I can understand. For Installer I did my job, I review the code and matthew refactored it and this is much better now (except that I cannot run the test because of a dependency to cloner). We have somebody writing a chapter on Installer, the next item is on Sake Now sometimes you give messages that are not totally clear. and this can be at the level of code formatting (no joke) putting sperate lines everywhere without tabs .... gives a bad impression that you want it or not. Finally, we disagree on the process (fetching tuff from a web site/ magic auto integration...) of course the process is not the tool and we should have a look at MC15. and MC1.6 I tried MC1.5 and it failed on me. You fixed the problem but I have to retry. Then again (this month I have two proposals, one book to finish, several articles to write tons of meetings, phd defense, porting moose to squeak and I want pharo to make progress). So if people from the community can have a look and report this item will move higher up the pending item list. Now all our infrastructure is depending on MC and we pay attention to it. >> I am actually fairly insulted by the attitude of the Pharo team >> towards >> this work. Since they take MC and continue to work on it >> separately, it >> actually renders all of my effort a waste of time. Do not feel insulted. We do not that on purpose. Our changes are not that much and we have to make 100% sure our process works. This does not imply that we will not look at it. But again I do not have the time. >> perhaps we can rescue sunit before it is too late. Yes now when I looked at Sunit Extensions I was worried that I do not understand all the changes and I was not sure that Sspec support was important. >> >> Keith >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by StÃ©phane Ducasse

I moved it into treatedInbox. We cannot keep broken elements in the inobox, especially since marcus or adrian or nicolas may have a look at it again. We do not have time for losing it three or four times. For us this is really important that we keep it clean else we can lose control. anything that somebody put in treated inbox will end up either in Is it clear? If you try to do our job you will really fast see how it can get frustrating - not knowing what is a changes - not knowing whether it works - not knowing whether is works but breaks something else. and taking responsibility for the mess we can put. So take 2 min to think about that and you will see what we are doing and why. We can do an harvesting session with anybody so that we share the feel Stef On Nov 7, 2008, at 8:37 PM, Alexandre Bergel wrote: >> When I load SUnit in pharoBox > > There is no SUnit package in PharoInbox. > Are you referring to SUnitGUI-AlexandreBergel.15.mcz in Pharo? > Obviously we should not have saved this file in Pharo, but in > PharoInbox rather. I apologize for this. > > SUnitGUI-AlexandreBergel.15.mcz expects the method > generateLastRunMethodNamed:for: to be present. This method is > provided by two packages that may be found in PharoTreatedInbox. > > However there is something strange, the following method has > disappeared from the image (I tried with an Core 10133 updated): > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > TestResult>>runCase: aTestCase > | testCasePassed | > testCasePassed := true. > [[aTestCase runCase] > on: self class failure > do: > [:signal | > failures add: aTestCase. > testCasePassed := false. > signal return: false]] > on: self class error > do: > [:signal | > errors add: aTestCase. > testCasePassed := false. > signal return: false]. > testCasePassed ifTrue: [passed add: aTestCase] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Is there any reason for this? Our extension on storing results will > have to be updated then... > > Alexandre > >> >> I cannot run tests anymore! >> David Alex can you really check? >> >> Guys I appreciate your work but it would be great if you could test >> more >> what you are doing because I spent a lot of time on problems like >> that. >> >> Stef >> >> >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008

Re: [Pharo-project] adrian .... help :)

by StÃ©phane Ducasse

Ok I see thanks On Nov 7, 2008, at 11:13 PM, Adrian Lienhard wrote: > Hi Stef > > Yesterday evening I did another update and it worked fine... > > It looks like the counter was increased twice in your case. This can > happen if the image is not fresh (the counter was set already) or > the #prepareNewUpdate is executed twice. To prevent this in the > future I changed how the counter is computed (now it does not lazily > increase it anymore but it looks at the latest updateXXX number). > The previous implementation of updateXXX number + 1 does not work > anymore because the new process supports to get back to apply > changes another time after the verification step and hence you do > not know if the updateXXX method was already created or not. > > I did a small update (10135) to check and it worked. So I'm curious > if it works reliably for you too now. > > Adrian > > > On Nov 7, 2008, at 16:12 , StÃ©phane Ducasse wrote: > >> adrian >> >> could you have a look at the scriptloader because it gets >> desynchronised (I had to change the number by hand this morning >> again and I followed exactly the process). May be my image counter >> was not correct. I think that this counter is >> brittle. I would just do what we did before taking the lastest >> updateXXX number + 1 >> >> Stef >> >> _______________________________________________ >> 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 >

Nov. 8, 2008

Fwd: [Pharo-project] Sunit Extensions breaking the TestRunner

by StÃ©phane Ducasse

Begin forwarded message: > From: Keith Hodges <keith_hodges(a)yahoo.co.uk> > Date: November 8, 2008 2:18:32 AM CEST > To: Alexandre Bergel <Alexandre.Bergel(a)inria.fr> > Cc: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: Re: [Pharo-project] Sunit Extensions breaking the TestRunner > > Alexandre Bergel wrote: >> The situation is getting messy. >> >> Cheers, >> Alexandre > exactly... everyone doing their own thing for their own reasons. Will > you be willing to help restore some coherence to the picture. > > I set a few goals that are fulfilled in my derived implementation. My > improvements are based upon more than 10 years of experience of using > SUnit and things like it. These have been out there for 2 years, so > there is no reason why people cannot build upon this base. > > 1. Ability to define test suites, and have a UI for running test > suites. > I have been using this facility for 8 years in st/x and always miss it > in squeak. I want to be able to define a suite for "My Project". > > 2. Ability to flag which tests are expected to work in which > situation, > which image version and which platform. So that I can run with "all > tests green" even if I happen to have a few windows specific tests, > when > I am running on a mac. > > 3. Ability to use tests to specify behaviour and requirements even > before the tests work. I.e. mark tests as #toDo. > > 4. Ability to run tests in an automated tool, without a UI. > > 5. Ability to sort tests so that they are run fastest first. 95% of > the > tests will run in 10% of the time. > > 6. Ability to determine whether a test used the network or not, and > filter out those tests if necessary. > > 7. Ability to integrate other testing technologies like SSpec. (not > actually done, but conceptually possible now) > > A couple of other improvements are also included, such as the > ability to > define a custom exception handler around all of your tests. > > In my opinion some members of the Pharo team have a big problem with > "Not Invented Here". They don't even look at the existing stuff before > diving in. > > I spent several months integrating the fixes from 3 separate streams > of > Monticello, specifically with the goal of promoting coherence within > all > of the the squeak communities. I did this work for the benefit of all > squeak users, not for the benefit of my health or financial well > being. > In fact it has cost me several thousands of pounds in lost revenue. > > I am actually fairly insulted by the attitude of the Pharo team > towards > this work. Since they take MC and continue to work on it > separately, it > actually renders all of my effort a waste of time. > > perhaps we can rescue sunit before it is too late. > > Keith > >

Nov. 8, 2008