[Pharo-project] Sunit Extensions breaking the TestRunner
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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@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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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@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
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@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
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
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@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
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
However there is something strange, the following method has disappeared from the image (I tried with an Core 10133 updated): -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= TestResult>>runCase: aTestCase [...]
Is there any reason for this? Our extension on storing results will have to be updated then...
So yes, why has this method disappeared? Me too would like to know that. David
I do not know. Can you check and see if it was in your code or a mistake we did? Stef On Nov 9, 2008, at 9:41 AM, David Röthlisberger wrote:
However there is something strange, the following method has disappeared from the image (I tried with an Core 10133 updated): -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= TestResult>>runCase: aTestCase [...] Is there any reason for this? Our extension on storing results will have to be updated then...
So yes, why has this method disappeared? Me too would like to know that.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Can you check and see if it was in your code or a mistake we did?
ah, I see what happened. We had Kerala loaded when we committed this SUnit version, but Kerala overrides method in SUnit such as TestResult>>runCase:, so those methods didn't get committed. Very bad. I committed a new version to Pharo: SUnit-DavidRoethlisberger.42 in which I also merged changes of stephane_ducassse.denker.41. Let me know if you need anything else to make SUnit work. David
However there is something strange, the following method has disappeared from the image (I tried with an Core 10133 updated): -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= TestResult>>runCase: aTestCase [...] Is there any reason for this? Our extension on storing results will have to be updated then...
So yes, why has this method disappeared? Me too would like to know that.
David
_______________________________________________ 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
Pfffff... But our greatest mistake is to not have loaded the all thing again. Alexandre On 10 Nov 2008, at 07:05, David Röthlisberger wrote:
Can you check and see if it was in your code or a mistake we did?
ah, I see what happened. We had Kerala loaded when we committed this SUnit version, but Kerala overrides method in SUnit such as TestResult>>runCase:, so those methods didn't get committed. Very bad. I committed a new version to Pharo: SUnit-DavidRoethlisberger.42 in which I also merged changes of stephane_ducassse.denker.41. Let me know if you need anything else to make SUnit work.
David
However there is something strange, the following method has disappeared from the image (I tried with an Core 10133 updated): -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= TestResult>>runCase: aTestCase [...] Is there any reason for this? Our extension on storing results will have to be updated then...
So yes, why has this method disappeared? Me too would like to know that.
David
_______________________________________________ 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
_______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
David Röthlisberger wrote:
Can you check and see if it was in your code or a mistake we did?
ah, I see what happened. We had Kerala loaded when we committed this SUnit version, but Kerala overrides method in SUnit such as TestResult>>runCase:, so those methods didn't get committed. Very bad.
Not bad, typical, and you get used to it winding you up if you are an MC1.0 user. So you have to adopt a strategy for maintaining each package, such as maintainng an image specifically for each package that you may have overrides in. So that is what MC1.5 was written for, to fix this bug! But people have failed to see the need for it. Because many of you folks are package writers, rather than package users/tweakers you don't find this problem an issue. But if the package writer will not take on board requests for modifications what can you do.
I committed a new version to Pharo: SUnit-DavidRoethlisberger.42 in which I also merged changes of stephane_ducassse.denker.41. Let me know if you need anything else to make SUnit work.
David the only reason you would need to override runCase: is if your SUnit doesnt include runCaseWith: aBlock as a specific place intended as a hook for test cases to wrap all tests in contexts/exception handlers. (e.g. WACurrentSession)
SUnit in www.squeaksource.com/Testing includes runCaseWith: Keith
Hi keith
We had Kerala loaded when we committed this SUnit version, but Kerala overrides method in SUnit such as TestResult>>runCase:, so those methods didn't get committed. Very bad. Not bad, typical, and you get used to it winding you up if you are an MC1.0 user. So you have to adopt a strategy for maintaining each package, such as maintainng an image specifically for each package that you may have overrides in.
So that is what MC1.5 was written for, to fix this bug! But people have failed to see the need for it.
Because many of you folks are package writers, rather than package users/tweakers you don't find this problem an issue. But if the package writer will not take on board requests for modifications what can you do.
You lost me. Could reexplained it to me> May be I'm just too tired too :)
I committed a new version to Pharo: SUnit-DavidRoethlisberger.42 in which I also merged changes of stephane_ducassse.denker.41. Let me know if you need anything else to make SUnit work.
David the only reason you would need to override runCase: is if your SUnit doesnt include runCaseWith: aBlock as a specific place intended as a hook for test cases to wrap all tests in contexts/exception handlers. (e.g. WACurrentSession)
SUnit in www.squeaksource.com/Testing includes runCaseWith:
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi keith
We had Kerala loaded when we committed this SUnit version, but Kerala
overrides method in SUnit such as TestResult>>runCase:, so those methods didn't get committed. Very bad.
Not bad, typical, and you get used to it winding you up if you are an MC1.0 user. So you have to adopt a strategy for maintaining each package, such as maintainng an image specifically for each package that you may have overrides in.
So that is what MC1.5 was written for, to fix this bug! But people have failed to see the need for it.
Because many of you folks are package writers, rather than package users/tweakers you don't find this problem an issue. But if the package writer will not take on board requests for modifications what can you do.
You lost me. Could reexplained it to me> May be I'm just too tired too :)
Let me elaborate. Suppose there is two persons A and B. Both are using package C. And both want to override some methods in package C to make their packages working. But author of package C refusing to include modifications of both persons. Now, the only option they have is to ship their MC package each with own overrides to original 'maintained' version of C, and hope that if someone would want to load both A and B packages, their overrides will not interfere with each other. -- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
2008/11/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi keith
We had Kerala loaded when we committed this SUnit version, but Kerala
overrides method in SUnit such as TestResult>>runCase:, so those methods didn't get committed. Very bad.
Not bad, typical, and you get used to it winding you up if you are an MC1.0 user. So you have to adopt a strategy for maintaining each package, such as maintainng an image specifically for each package that you may have overrides in.
So that is what MC1.5 was written for, to fix this bug! But people have failed to see the need for it.
Because many of you folks are package writers, rather than package users/tweakers you don't find this problem an issue. But if the package writer will not take on board requests for modifications what can you do.
You lost me. Could reexplained it to me> May be I'm just too tired too :)
Let me elaborate. Suppose there is two persons A and B. Both are using package C. And both want to override some methods in package C to make their packages working. But author of package C refusing to include modifications of both persons. Now, the only option they have is to ship their MC package each with own overrides to original 'maintained' version of C, and hope that if someone would want to load both A and B packages, their overrides will not interfere with each other.
As an alternative users A and B can club together and make a package called C-extras, which avoids the problem of overrides clashing. This is exactly the situation we have with Seaside, package maintainers refusing to add even simple accessors, so... Seaside28Jetsam was created as "Seaside-Extras". This is exactly the role of the Kernel-Extensions package (not that it includes many overrides). Several have turned their noses up at Kernel-Extensions because it includes things that they dont necessarily like, but in the process you are pooring scorn on a social process of collecting all extensions in a managed place where collisions can be avoided. Taking this on board... a package developer could recognise that perhaps they haven't got it all right and recognise a need to harness and guide such extras. Thus encouraging users of their package to collaborate in order to make the extras well documented and worthy of inclusion into future releases of the main package. Presently, the culture of "overrides are evil" is maintained because of the danger of clashes as Igor explained. But they dont have to be evil if they are managed in a social collaborative process which avoids such collisions, i.e. Seaside28Jetsam, and KernelExtensions. Those who write the packages can pronounce the doctrine of "overrides are evil", because they are not forced to use them, however those of us who want to actually. The solution for SUnit is for those who are interested in improving SUnit to actually TALK to others who have been already doing the same, and to collaborate on one such SUnit-improved rather than 10 separate ones! regards Keith
As an alternative users A and B can club together and make a package called C-extras, which avoids the problem of overrides clashing.
This is exactly the situation we have with Seaside, package maintainers refusing to add even simple accessors, so... Seaside28Jetsam was created as "Seaside-Extras".
This is exactly the role of the Kernel-Extensions package (not that it includes many overrides). Several have turned their noses up at Kernel-Extensions because it includes things that they dont necessarily like,
keith may I say that this is not productive to bash us systematically. We did a report on Kernel Extensions and we will certainly harvest some of the extensions. Now if nobody beside me look at it, then it will end up on my long stack and so far I'm quite busy.
but in the process you are pooring scorn on a social process of collecting all extensions in a managed place where collisions can be avoided.
Taking this on board... a package developer could recognise that perhaps they haven't got it all right and recognise a need to harness and guide such extras. Thus encouraging users of their package to collaborate in order to make the extras well documented and worthy of inclusion into future releases of the main package.
Presently, the culture of "overrides are evil" is maintained because of the danger of clashes as Igor explained. But they dont have to be evil if they are managed in a social collaborative process which avoids such collisions, i.e. Seaside28Jetsam, and KernelExtensions. Those who write the packages can pronounce the doctrine of "overrides are evil", because they are not forced to use them, however those of us who want to actually.
Overrides are still something that we should avoid as much as possible.
The solution for SUnit is for those who are interested in improving SUnit to actually TALK to others who have been already doing the same, and to collaborate on one such SUnit-improved rather than 10 separate ones!
True. Alex told me that he will have a look at your extensions. So he will I'm sure. Stef
regards
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The solution for SUnit is for those who are interested in improving SUnit to actually TALK to others who have been already doing the same, and to collaborate on one such SUnit-improved rather than 10 separate ones!
True. Alex told me that he will have a look at your extensions. So he will I'm sure.
Yes, I will have a look at it. But nothing Rome was not made in one day... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I apologize for my previous emails being somewhat brash. I admit that am not in the best of spirits having been hit by a firework (no lasting damage done). Keith
no problem you are right. I can imagine that this is raging seeing us reinventing the wheel. Stef PS: jannik told me that he will report the problems he has with Installer On Nov 10, 2008, at 7:57 PM, Keith Hodges wrote:
I apologize for my previous emails being somewhat brash. I admit that am not in the best of spirits having been hit by a firework (no lasting damage done).
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse writes:
Overrides are still something that we should avoid as much as possible.
It's always possible to avoid overrides by having your own branch of a package. Exupery does that for VMMaker. That works with MC 1.x's merging, and allows it to track who's changed what to make it easier to follow downstream changes. Bryce
2008/11/11 <bryce@kampjes.demon.co.uk>:
Stéphane Ducasse writes:
Overrides are still something that we should avoid as much as possible.
It's always possible to avoid overrides by having your own branch of a package. Exupery does that for VMMaker. That works with MC 1.x's merging, and allows it to track who's changed what to make it easier to follow downstream changes.
It may work for VMMaker (because it is quite uncommon thing), but in broader range it will introduce even more problems. Going with your doctrine, there can be 10 developers, each forced to maintain own version of some basic package with own overrides. Now, if someone would want to use all 10 projects in single image, he will have to deal with 10 different versions of same package. The brave soul can go through all 10 versions, spend week or two merging them into common base. But i don't think he would want to repeat it over and over again, in case he wants to update one of 10 packages to new version, where some bugs fixed or new features added.
Bryce
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko writes:
2008/11/11 <bryce@kampjes.demon.co.uk>:
Stéphane Ducasse writes:
Overrides are still something that we should avoid as much as possible.
It's always possible to avoid overrides by having your own branch of a package. Exupery does that for VMMaker. That works with MC 1.x's merging, and allows it to track who's changed what to make it easier to follow downstream changes.
It may work for VMMaker (because it is quite uncommon thing), but in broader range it will introduce even more problems. Going with your doctrine, there can be 10 developers, each forced to maintain own version of some basic package with own overrides. Now, if someone would want to use all 10 projects in single image, he will have to deal with 10 different versions of same package. The brave soul can go through all 10 versions, spend week or two merging them into common base. But i don't think he would want to repeat it over and over again, in case he wants to update one of 10 packages to new version, where some bugs fixed or new features added.
In the case you describe you're better off using separate MC packages. You'd build your own image by merging each of the 10 developers changes together to make your own version. You're better off because MC will alert you if two of the package versions change the same method. If the changes in the separate package versions do not change the same methods then there will be no conflicts and no trouble merging. Using overrides, you're on your own tracking down conflicting changes and the only notification you'll get is the bugs produced. If one of the packages is updated, then with MC all you need to do is merge it in, MC will figure out if the new changes in that package conflict with something else. That's why I now maintain my own VMMaker packages instead of using overrides or change sets. The VMMaker base does change and sometimes methods I've changed change underneath me. It's too easy to badly break the VM trying to manage merging without utilising MCs capabilities and tracking down the breakage without decent tool support is very painful. I've done it with VMMaker before MC. I do use overrides if I need to change a single method in another package but even there I'd be tempted to keep the override in a separate override package to make them easier to find and to limit such overrides to optional functionality so users are not forced to use the override. There is one such override in Exupery itself. Bryce
participants (7)
-
Alexandre Bergel -
bryce＠kampjes.demon.co.uk -
David Röthlisberger -
Igor Stasenko -
Keith Hodges -
Marcus Denker -
Stéphane Ducasse