Metacello browser
Locked
 
|
Hi Dale,
I fixed the tests to make them green. Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest What do we do with MBPackageInfoTest>>testSeeChanges? I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. Version 1.56 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Alex,
I'm still in the middle of trying to get things working in OmniBrowser/GemStone and the have been trying to eradicate the use of the browser iv but have had trouble getting rid of the last few places where it's used, so I'm not surprised that there are a number of places broken ... the eggs are broken, but the omelette isn't finished yet:) I tried to be faithful to the implementation of add configuration when I moved it to mbcommand hierarchy, so I'd appreciate more info about what you think is missing ... if the test enforces the missing behavior, then that will be easy enough to take care or... If I recall I wasn't actually finished ... it was clear that there was going to have to be a bunch of stuff moved to the cmd structure to break the tight coupling with MetacelloBrowser ... over the course of the day I have moved things like checkrepository and friends to MBCommand so the mbcommand implementation is a little more friendly to code being moved from MetacelloBrowser ... I think that the recent changes that I've made will make it possible to eliminate all of the references to browser throughout the model and command structure, but it is a big task to stomp them all out and I'm not surprised that those things are broken in places ... If you noticed, I added the class MBDevelopmentCycleTests where I've implemented a couple of tests for a couple of the commands that I moved to mbCommand (i.e., ported to GemStone/OB) plus a couple of empty test methods that I intended to fill in when I had a better idea of what it would take to make the commands independent of either morphic or ob ... this test creates real packages and configurations and removes things afterwards, packages can be loaded and updated, so it is the framework that we want to use for the bulk of our testing ... the test for the changes browser should be written within this framework ... be aware that there are three or four different classses of changes browser that will bet used depending upon settings of preferences and platform ... `== nil` is more efficient in GemStone so I've gotten into the happen of thinking typing hit ... just a habit. Dale On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > Hi Dale, > > I fixed the tests to make them green. > Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. > > By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? > > I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest > > What do we do with MBPackageInfoTest>>testSeeChanges? > > I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. > > Version 1.56 > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
In reply to this post by Alexandre Bergel-5
I guess you are working in PharoCore? Be aware that I am building the OB variant of MetacelloBrowser and you removed some methods that are needed for ob to work #isOBCommand ...
To be safe you should probably develop in an image with at least OB loaded so that you don't inadvertently remove things that are only used by OB, either or only remove methods when you have OB land the all of the packages loaded ... also be aware that there is a GemStone specific package as well ... Dale On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > Hi Dale, > > I fixed the tests to make them green. > Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. > > By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? > > I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest > > What do we do with MBPackageInfoTest>>testSeeChanges? > > I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. > > Version 1.56 > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
It looks like #isOBCommands got lost because of a missed merge ... not an explicit removal..
Dale On Mar 5, 2011, at 8:10 PM, Dale Henrichs wrote: > I guess you are working in PharoCore? Be aware that I am building the OB variant of MetacelloBrowser and you removed some methods that are needed for ob to work #isOBCommand ... > > To be safe you should probably develop in an image with at least OB loaded so that you don't inadvertently remove things that are only used by OB, either or only remove methods when you have OB land the all of the packages loaded ... also be aware that there is a GemStone specific package as well ... > > Dale > > On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > >> Hi Dale, >> >> I fixed the tests to make them green. >> Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. >> >> By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? >> >> I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest >> >> What do we do with MBPackageInfoTest>>testSeeChanges? >> >> I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. >> >> Version 1.56 >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > |
|
|
In reply to this post by Alexandre Bergel-5
After merging in my recent changes, there are 4 failing tests... I'm inclined to leave the tests failing for the time being .. these are the tests that create a fake browser instance because the commands and model are still using the browser ... the use of the browser iv should be stamped out and I'm not inclined to patch some tests that are clearly wrong in the first place and will need to be completely rewritten once we've eliminated the pervasive use of browser ... I am in the middle of this work and it will take several days to complete and I don't intend on making the tests green until the restructuring is complete...
Dale On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > Hi Dale, > > I fixed the tests to make them green. > Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. > > By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? > > I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest > > What do we do with MBPackageInfoTest>>testSeeChanges? > > I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. > > Version 1.56 > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
In reply to this post by Dale Henrichs
Ok
Alexandre On 6 Mar 2011, at 00:46, Dale Henrichs wrote: > Alex, > > I'm still in the middle of trying to get things working in OmniBrowser/GemStone and the have been trying to eradicate the use of the browser iv but have had trouble getting rid of the last few places where it's used, so I'm not surprised that there are a number of places broken ... the eggs are broken, but the omelette isn't finished yet:) > > I tried to be faithful to the implementation of add configuration when I moved it to mbcommand hierarchy, so I'd appreciate more info about what you think is missing ... if the test enforces the missing behavior, then that will be easy enough to take care or... > > If I recall I wasn't actually finished ... it was clear that there was going to have to be a bunch of stuff moved to the cmd structure to break the tight coupling with MetacelloBrowser ... over the course of the day I have moved things like checkrepository and friends to MBCommand so the mbcommand implementation is a little more friendly to code being moved from MetacelloBrowser ... > > I think that the recent changes that I've made will make it possible to eliminate all of the references to browser throughout the model and command structure, but it is a big task to stomp them all out and I'm not surprised that those things are broken in places ... > > If you noticed, I added the class MBDevelopmentCycleTests where I've implemented a couple of tests for a couple of the commands that I moved to mbCommand (i.e., ported to GemStone/OB) plus a couple of empty test methods that I intended to fill in when I had a better idea of what it would take to make the commands independent of either morphic or ob ... this test creates real packages and configurations and removes things afterwards, packages can be loaded and updated, so it is the framework that we want to use for the bulk of our testing ... the test for the changes browser should be written within this framework ... be aware that there are three or four different classses of changes browser that will bet used depending upon settings of preferences and platform ... > > `== nil` is more efficient in GemStone so I've gotten into the happen of thinking typing hit ... just a habit. > > Dale > > On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > >> Hi Dale, >> >> I fixed the tests to make them green. >> Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. >> >> By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? >> >> I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest >> >> What do we do with MBPackageInfoTest>>testSeeChanges? >> >> I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. >> >> Version 1.56 >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Dale Henrichs
I am working with Pharo 1.2 (non-core). OB is present in my image.
Maybe I mess something up when merging. No idea. But if isOBCommand would have been tested, I would have found the problem :-) Alexandre On 6 Mar 2011, at 01:10, Dale Henrichs wrote: > I guess you are working in PharoCore? Be aware that I am building the OB variant of MetacelloBrowser and you removed some methods that are needed for ob to work #isOBCommand ... > > To be safe you should probably develop in an image with at least OB loaded so that you don't inadvertently remove things that are only used by OB, either or only remove methods when you have OB land the all of the packages loaded ... also be aware that there is a GemStone specific package as well ... > > Dale > > On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > >> Hi Dale, >> >> I fixed the tests to make them green. >> Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. >> >> By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? >> >> I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest >> >> What do we do with MBPackageInfoTest>>testSeeChanges? >> >> I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. >> >> Version 1.56 >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Dale Henrichs
I had 3 red tests. I fixed them. It was quite easy. Instead of using the 'browser' instance variable to know which is the selected configuration, I asked the version for its projectLabel. Easier :-)
Version 1.57 in the box. Cheers, Alexandre On 6 Mar 2011, at 00:46, Dale Henrichs wrote: > Alex, > > I'm still in the middle of trying to get things working in OmniBrowser/GemStone and the have been trying to eradicate the use of the browser iv but have had trouble getting rid of the last few places where it's used, so I'm not surprised that there are a number of places broken ... the eggs are broken, but the omelette isn't finished yet:) > > I tried to be faithful to the implementation of add configuration when I moved it to mbcommand hierarchy, so I'd appreciate more info about what you think is missing ... if the test enforces the missing behavior, then that will be easy enough to take care or... > > If I recall I wasn't actually finished ... it was clear that there was going to have to be a bunch of stuff moved to the cmd structure to break the tight coupling with MetacelloBrowser ... over the course of the day I have moved things like checkrepository and friends to MBCommand so the mbcommand implementation is a little more friendly to code being moved from MetacelloBrowser ... > > I think that the recent changes that I've made will make it possible to eliminate all of the references to browser throughout the model and command structure, but it is a big task to stomp them all out and I'm not surprised that those things are broken in places ... > > If you noticed, I added the class MBDevelopmentCycleTests where I've implemented a couple of tests for a couple of the commands that I moved to mbCommand (i.e., ported to GemStone/OB) plus a couple of empty test methods that I intended to fill in when I had a better idea of what it would take to make the commands independent of either morphic or ob ... this test creates real packages and configurations and removes things afterwards, packages can be loaded and updated, so it is the framework that we want to use for the bulk of our testing ... the test for the changes browser should be written within this framework ... be aware that there are three or four different classses of changes browser that will bet used depending upon settings of preferences and platform ... > > `== nil` is more efficient in GemStone so I've gotten into the happen of thinking typing hit ... just a habit. > > Dale > > On Mar 5, 2011, at 6:27 PM, Alexandre Bergel wrote: > >> Hi Dale, >> >> I fixed the tests to make them green. >> Would you mind to check the class MBConfigurationRoot please? 'configurations' is defined nowhere, and it is accessed by its method. Should 'configurations' be an instance variable ? It is a class instance variable although. >> >> By running the code critic, I fixed a number of problems. I tried to fix them as much as I can. I also see that you often use '== nil ifTrue:' instead of 'ifNil:'. Is there a reason for this? >> >> I found many bugs in MBAddConfigurationCommand, you may want to double check what I did. Note that I wrote a test MBAddConfigurationCommandTest >> >> What do we do with MBPackageInfoTest>>testSeeChanges? >> >> I defined an empty directRefresh on MBVersionBrowser. #directRefresh is not sent by this class. Since MBAbstractBrowser calls #directRefresh, I had to do so. >> >> Version 1.56 >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Alexandre Bergel-5
On Mar 6, 2011, at 10:45 AM, Alexandre Bergel wrote: > I am working with Pharo 1.2 (non-core). OB is present in my image. > Maybe I mess something up when merging. No idea. But if isOBCommand would have been tested, I would have found the problem :-) Haha ... you are _absolutely_ right! ... actually the missing methods were due to a skipped merge ... I just couldn't figure out why you would remove them unless you didn't have ob loaded:) No I encourage you to continue to harp on the testing issue, even if I grumble about it now and then, because I agree 100% that the job isn't done until you've got good test coverage .... Dale |
|
|
In reply to this post by Alexandre Bergel-5
On Mar 6, 2011, at 10:57 AM, Alexandre Bergel wrote: > I had 3 red tests. I fixed them. It was quite easy. Instead of using the 'browser' instance variable to know which is the selected configuration, I asked the version for its projectLabel. Easier :-) > > Version 1.57 in the box. > Ah good! Dale |
|
|
In reply to this post by Dale Henrichs
> No I encourage you to continue to harp on the testing issue, even if I grumble about it now and then, because I agree 100% that the job isn't done until you've got good test coverage ....
I am perfectly happy with the current situation. Really. I absolutely do not mind to go after what you wrote and writing test for it. Testing what you did is the best way for me to see what has been done. I really appreciate your work. MetacelloBrowser is shaping good. I will update its website soon and update the documentation. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Alexandre Bergel-5
On Mar 6, 2011, at 10:57 AM, Alexandre Bergel wrote: > I had 3 red tests. I fixed them. It was quite easy. Instead of using the 'browser' instance variable to know which is the selected configuration, I asked the version for its projectLabel. Easier :-) > > Version 1.57 in the box. Oh wait ... that change is not correct ... it might make the tests pass, but I am intentionally using the configurationInfo method it is wrong to bypass the configurationInfo send .... I haven't finished getting the configurationInfo stuff working correctly ... which is why I mentioned the red tests .... the real fix is to get the underlying configurationInfo stuff to work correctly ... Dale |
|
|
In reply to this post by Alexandre Bergel-5
>> No I encourage you to continue to harp on the testing issue, even if I grumble about it now and then, because I agree 100% that the job isn't done until you've got good test coverage .... > > > I am perfectly happy with the current situation. Really. I absolutely do not mind to go after what you wrote and writing test for it. Testing what you did is the best way for me to see what has been done. > > I really appreciate your work. MetacelloBrowser is shaping good. I will update its website soon and update the documentation. Thanks for that alex. Because this way we are building a really good infrastructure to manage complex dependencies. The domain covered by metacello is far from trivial. Stef |
|
|
In reply to this post by Dale Henrichs
> Oh wait ... that change is not correct ... it might make the tests pass, but I am intentionally using the configurationInfo method it is wrong to bypass the configurationInfo send .... I haven't finished getting the configurationInfo stuff working correctly ... which is why I mentioned the red tests .... the real fix is to get the underlying configurationInfo stuff to work correctly ...
Hum... I do not really see how to fix the code or the test. Would you mind to add a test that brakes to illustrate the problem? We can either revert to the previous version, or I wait for your new fix. I prefer the latter. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by stephane ducasse-2
> Thanks for that alex. Because this way we are building a really good infrastructure to manage complex dependencies.
> The domain covered by metacello is far from trivial. Indeed. I think that the next big steps for the browser, is to support merging and enforcing a development process. At that stage, this is not only engineering that is required, but also some research has to be done. This is indeed complex. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Alexandre Bergel-5
For me the red test is the test that breaks and illustrates the problem ... when I am in the middle of development I let the tests go red because the solution is not necessarily that the tests are wrong, but that I haven't completed the underlying development yet ... when I am satisfied with the new infrastructure ... I've been pushing around a very large volume of code over the last several days with multiple refactorings ... then it is time to look at the failing tests and determine if the test is still valid or fix the bugs in the underlying infrastructure ...
so your change made the tests green but didn't contribute to finishing the jobs of eliminating the use of the brower instance variable... Dale On Mar 6, 2011, at 11:33 AM, Alexandre Bergel wrote: >> Oh wait ... that change is not correct ... it might make the tests pass, but I am intentionally using the configurationInfo method it is wrong to bypass the configurationInfo send .... I haven't finished getting the configurationInfo stuff working correctly ... which is why I mentioned the red tests .... the real fix is to get the underlying configurationInfo stuff to work correctly ... > > > Hum... I do not really see how to fix the code or the test. Would you mind to add a test that brakes to illustrate the problem? > > We can either revert to the previous version, or I wait for your new fix. I prefer the latter. > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
> so your change made the tests green but didn't contribute to finishing the jobs of eliminating the use of the brower instance variable...
Yeah. But what should I do? Revert to a version where the tests are red? Or wait for your improvement and fix the tests. I prefer waiting, I hope this is ok with you. Having red tests make me have nightmares, make my beard grow at a ridiculously high speed, teeth get longer, I become to eat raw meat, ... No no. On tuesday I start a lecture on programming and design. I do not want to afraid my students with this look :-) Cheers, Alexandre > > On Mar 6, 2011, at 11:33 AM, Alexandre Bergel wrote: > >>> Oh wait ... that change is not correct ... it might make the tests pass, but I am intentionally using the configurationInfo method it is wrong to bypass the configurationInfo send .... I haven't finished getting the configurationInfo stuff working correctly ... which is why I mentioned the red tests .... the real fix is to get the underlying configurationInfo stuff to work correctly ... >> >> >> Hum... I do not really see how to fix the code or the test. Would you mind to add a test that brakes to illustrate the problem? >> >> We can either revert to the previous version, or I wait for your new fix. I prefer the latter. >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Alexandre Bergel-5
On Mar 6, 2011, at 11:47 AM, Alexandre Bergel wrote: >> Thanks for that alex. Because this way we are building a really good infrastructure to manage complex dependencies. >> The domain covered by metacello is far from trivial. > > > Indeed. I think that the next big steps for the browser, is to support merging and enforcing a development process. > At that stage, this is not only engineering that is required, but also some research has to be done. This is indeed complex. I am really glad that you are pushing on this stuff and I appreciate the fact that we do have different development styles, the tension between our styles will only end up producing a better solution in the end ... we just have to work through these complex issues and experience the pain first hand ... Again I really appreciate what you are trying to accomplish! I thank you for that, as well. Dale |
|
|
In reply to this post by Alexandre Bergel-5
On Mar 6, 2011, at 11:58 AM, Alexandre Bergel wrote: >> so your change made the tests green but didn't contribute to finishing the jobs of eliminating the use of the brower instance variable... > > Yeah. But what should I do? Revert to a version where the tests are red? Or wait for your improvement and fix the tests. > I prefer waiting, I hope this is ok with you. Having red tests make me have nightmares, make my beard grow at a ridiculously high speed, teeth get longer, I become to eat raw meat, ... No no. On tuesday I start a lecture on programming and design. I do not want to afraid my students with this look :-) My goal is to have a workable version of MetacelloBrowser that works in GemStone (i.e., ported to OB) by the end of today ... depending upon the definition of "end of today" ... I need to start a project in GLASS that will be greatly enhanced by having a working MetacelloBrowser there ... to get there I am making some fairly significant structural changes so I think that right now sitting back and letting me hit the afterburners is the bestthing ... once I get past this hurdle of getting OB and Morphic variants of the tool with a shared model (BTW, this shared model can be shared by Glamour or a javascript api or ...) I think that both of us can settle into the task of incrementally improving the browser with both tests and added functionality ... I don't want you to have nightmares and scare your students, so when I "finish" this round of craziness I will let you know and when I finish I will make sure that the tests are green so that you can sleep with dreams of a field of full of green tests tonite Dale |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |