- Pharo-dev - lists.pharo.org

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

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

by Adrian Lienhard

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

Nov. 7, 2008

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

by Lukas Renggli

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

Nov. 7, 2008

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

by Matthias Berth

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. Cheers Matthias On Thu, Nov 6, 2008 at 11:22 AM, Stefan Schmiedl <s(a)xss.de> wrote: > On Thu, 6 Nov 2008 08:00:14 +0100 > "Damien Cassou" <damien.cassou(a)gmail.com> wrote: > >> On Wed, Nov 5, 2008 at 10:12 PM, Matthias Berth >> <matthias.berth(a)googlemail.com> wrote: >> > * great tools, e.g. OmniBrowser with refactoring support >> > * polished user interface with TrueType fonts and Polymorph widgets >> >> Don't give the tool names. Newcomers don't care. > > ... if they don't know the names from somewhere else. And newcomers > are not the only ones reading "about" docs. How about > > "... with scalable fonts (TrueType) and ??? widgets (Polymorph)" > >> > but it is a fork: Do not expect Etoy/Nebraska to work in >> > Pharo. >> >> Again, Newcomers don't care in my opinion. > > Again: a newcomer to Pharo is not necessarily a newcomer to Smalltalk or > Squeak. I am a case in point: I intermittently dabbled with Squeak, so I have > a rough knowledge about the "kid stuff" living in the image. A clear statement > that this (for me) irrelevant stuff and its supporting cruft is removed, is a plus. > > Just making Smalltalk, > s. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 7, 2008

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

by Alexandre Bergel

> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 7, 2008

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

by StÃ©phane Ducasse

Thanks Stef On Nov 7, 2008, at 8:05 PM, Alexandre Bergel wrote: > Ok, I am having a look at it now... > > Alexandre > > On 7 Nov 2008, at 12:29, StÃ©phane Ducasse wrote: > >> Hi >> >> When I load SUnit in pharoBox >> 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. 7, 2008

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

by Alexandre Bergel

Ok, I am having a look at it now... Alexandre On 7 Nov 2008, at 12:29, StÃ©phane Ducasse wrote: > Hi > > When I load SUnit in pharoBox > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 7, 2008

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

by StÃ©phane Ducasse

this is renaming... in inbox Tx lukas On Nov 7, 2008, at 6:54 PM, Lukas Renggli wrote: >> Can somebody (lukas for example) have a look at the code of noury >> on package >> renaming. >> Noury told me that it worked since years but lukas told me that >> renaming is not supported in MC >> so I'm puzzled. > > In what package is that? > > 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. 7, 2008