Alexandre (and anyone else that may have been using the #development
version), While at STS 2011, I think that I have fixed the major update problems with the MetacelloBrowser (and added tests to track the expected behavior).... to be clear there are two kinds of update problems that might exist: - updates to the shared MBConfigurationRoot based on system modifications (i.e., hand edits, package loads/unloads that affect the classes/methods both ConfigurationOfXXX and classes methods implmented in the projects) - updates in the GUI to reflect the underlying model changes. I feel very good about model updates (still expecting to learn of holes) and pretty good about view updates (there are still some model changes that don't quite correctly update the display). There are still several commands that are still implemented in MetacelloBrowser (the class) that should be moved to MBCommands.. But other than those two areas is there anything else that prevents us from announcing that 1.57 is stable and then updating the documentation to match? I've been somewhat heavy handed in what I've done so far: mainly in redefining what commands show up on the tool bar. But _my_ main thrust so far has been: - support a development process - create MBConfigurationRoot which in concert with MBCommand allows for creating multiple GUI implementations with Morphic and OB implemented so far, but I wouldn't think that Glamour, Seaside, or even javascript-based GUIs wouldn't be that hard to implement and now might be a good time to take a breath and review/critique the overall experience...if the result is mildly positive to raving, then we can try to fix the above two issues (updates/move the commands) and then do another release ...but if the experience is negative to nearly positive, I would say we need to do some more thinking/bug fixing ... Personally I know that there is a _lot_ more that can/should be done, but I have been using the browser pretty heavily and can do 75%+ of my work using the tool (without resorting to Monticello Browser or hand of configs) and would rate it at "mildly positive"...and since I feel comfortable with the stability of MBConfigurationRoot, I would feel comfortable getting wider exposure... But that's just me and I know too much about Metacello and MetacelloBrowser to be able to make an objective judgement ... Dale |
Hi Dale,
Before jumping into the update you mentioned, there is a critical problems that prevents me from using the browser. Here is a short scenario that illustrates the problem: 1 - create a package MyTestProject with a class inside and save it in www.squeaksource.com/MyTestProject (it is global write and read). You need to use the Monticello browser for it. 2 - create a configuration (+Configuration), let's say ConfigurationOfMyTestProject 2 - make it depend the package MyTestProject 3 - Select the config MyTestProject in the browser 4 - add development version 5 - Modify the class of your class contained in the package MyTestProject 6 - right-click on the @1.0 #development and press 'save all and add development version'. And I get an error: Version #stable is not defined in ConfigurationOfMyTestProject. In my opinion, this is the problem that prevent me from using it :-( Is there something we could do? Side question, why MBCommand class>>on:for: and target:for: ? Apparently these two methods do the same things. I will continue with the rest of your email in my next email. Alexandre > There are still several commands that are still implemented in MetacelloBrowser (the class) that should be moved to MBCommands.. > > > But other than those two areas is there anything else that prevents us from announcing that 1.57 is stable and then updating the documentation to match? > > I've been somewhat heavy handed in what I've done so far: mainly in redefining what commands show up on the tool bar. But _my_ main thrust so far has been: > > - support a development process > - create MBConfigurationRoot which in concert with MBCommand allows > for creating multiple GUI implementations with Morphic and OB > implemented so far, but I wouldn't think that Glamour, Seaside, or > even javascript-based GUIs wouldn't be that hard to implement > > and now might be a good time to take a breath and review/critique the overall experience...if the result is mildly positive to raving, then we can try to fix the above two issues (updates/move the commands) and then do another release ...but if the experience is negative to nearly positive, I would say we need to do some more thinking/bug fixing ... > > Personally I know that there is a _lot_ more that can/should be done, but I have been using the browser pretty heavily and can do 75%+ of my work using the tool (without resorting to Monticello Browser or hand of configs) and would rate it at "mildly positive"...and since I feel comfortable with the stability of MBConfigurationRoot, I would feel comfortable getting wider exposure... > > But that's just me and I know too much about Metacello and MetacelloBrowser to be able to make an objective judgement ... > > Dale -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by Dale Henrichs
> - updates to the shared MBConfigurationRoot based on system modifications (i.e., hand edits, package loads/unloads that affect the classes/methods both ConfigurationOfXXX and classes methods implmented in the projects)
> - updates in the GUI to reflect the underlying model changes. > > I feel very good about model updates (still expecting to learn of holes) and pretty good about view updates (there are still some model changes that don't quite correctly update the display). So far, update problem haven't bothered me that much. The only thing is that time to time the configuration is marked as dirty and the corresponding package is not and none of the dependent packages is. > There are still several commands that are still implemented in MetacelloBrowser (the class) that should be moved to MBCommands.. Yes. I will work on them once the problem Mariano and I mentioned today is solved. > I've been somewhat heavy handed in what I've done so far: mainly in redefining what commands show up on the tool bar. But _my_ main thrust so far has been: > > - support a development process Yes, probably things can be slightly improved. Before releasing it, I would like to intensively use it and ask my students to do the same. Kind regards, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by abergel
On 03/18/2011 11:51 AM, Alexandre Bergel wrote:
> Hi Dale, > > Before jumping into the update you mentioned, there is a critical problems that prevents me from using the browser. Here is a short scenario that illustrates the problem: > 1 - create a package MyTestProject with a class inside and save it in www.squeaksource.com/MyTestProject (it is global write and read). You need to use the Monticello browser for it. > 2 - create a configuration (+Configuration), let's say ConfigurationOfMyTestProject > 2 - make it depend the package MyTestProject > 3 - Select the config MyTestProject in the browser > 4 - add development version > 5 - Modify the class of your class contained in the package MyTestProject > 6 - right-click on the @1.0 #development and press 'save all and add development version'. > > And I get an error: Version #stable is not defined in ConfigurationOfMyTestProject. > In my opinion, this is the problem that prevent me from using it :-( > Is there something we could do? Certainly ... I've submitted Issue 123 to track ... if the problem involves Metacello changes, I am planning a 1.0-beta.28.3.2 release to address some MetacelloBrowser issues (Issue 115 plus any others that pop up) ... > > Side question, why MBCommand class>>on:for: and target:for: ? Apparently these two methods do the same things. > At one point in time they did not do the same things, so they can be cleaned up ... I have a feeling that one is in the morphic package and one is in the ob package, so if you clean it up, also make sure that the method ends up in a common package ... Dale |
In reply to this post by abergel
On 03/18/2011 12:00 PM, Alexandre Bergel wrote:
>> - updates to the shared MBConfigurationRoot based on system >> modifications (i.e., hand edits, package loads/unloads that affect >> the classes/methods both ConfigurationOfXXX and classes methods >> implmented in the projects) - updates in the GUI to reflect the >> underlying model changes. >> >> I feel very good about model updates (still expecting to learn of >> holes) and pretty good about view updates (there are still some >> model changes that don't quite correctly update the display). > > So far, update problem haven't bothered me that much. The only thing > is that time to time the configuration is marked as dirty and the > corresponding package is not and none of the dependent packages is. Yeah these are the things that I'm eventually going to track down ... > >> There are still several commands that are still implemented in >> MetacelloBrowser (the class) that should be moved to MBCommands.. > > Yes. I will work on them once the problem Mariano and I mentioned > today is solved. Okay, good ... I'll try to resolve that issue today ... > >> I've been somewhat heavy handed in what I've done so far: mainly in >> redefining what commands show up on the tool bar. But _my_ main >> thrust so far has been: >> >> - support a development process > > Yes, probably things can be slightly improved. I'd be interested in specific suggestions, etc. > > Before releasing it, I would like to intensively use it and ask my > students to do the same. That's great ... when you feel comfortable with releasing it, I'll feel comfortable:) Dale |
In reply to this post by Dale Henrichs
>> Side question, why MBCommand class>>on:for: and target:for: ? Apparently these two methods do the same things.
>> > > At one point in time they did not do the same things, so they can be cleaned up ... I have a feeling that one is in the morphic package and one is in the ob package, so if you clean it up, also make sure that the method ends up in a common package ... Done. No big deal apparently. All tests are green after having simply removed on:for: I guess the OB version uses target:for: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by Dale Henrichs
>> Side question, why MBCommand class>>on:for: and target:for: ? Apparently these two methods do the same things.
>> > > At one point in time they did not do the same things, so they can be cleaned up ... I have a feeling that one is in the morphic package and one is in the ob package, so if you clean it up, also make sure that the method ends up in a common package ... Done. No big deal apparently. All tests are green after having simply removed on:for: I guess the OB version uses target:for: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Sorry for the multiple emails, pb with my the smtp server of me.com
Alexandre On 18 Mar 2011, at 15:35, Alexandre Bergel wrote: >>> Side question, why MBCommand class>>on:for: and target:for: ? Apparently these two methods do the same things. >>> >> >> At one point in time they did not do the same things, so they can be cleaned up ... I have a feeling that one is in the morphic package and one is in the ob package, so if you clean it up, also make sure that the method ends up in a common package ... > > > Done. > No big deal apparently. All tests are green after having simply removed on:for: I guess the OB version uses target:for: > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by Dale Henrichs
>>> There are still several commands that are still implemented in
>>> MetacelloBrowser (the class) that should be moved to MBCommands.. >> >> Yes. I will work on them once the problem Mariano and I mentioned >> today is solved. > > Okay, good ... I'll try to resolve that issue today ... Excellent Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by abergel
On 03/18/2011 12:39 PM, Alexandre Bergel wrote:
>>> Side question, why MBCommand class>>on:for: and target:for: ? Apparently these two methods do the same things. >>> >> >> At one point in time they did not do the same things, so they can be cleaned up ... I have a feeling that one is in the morphic package and one is in the ob package, so if you clean it up, also make sure that the method ends up in a common package ... > > > Done. > No big deal apparently. All tests are green after having simply removed on:for: I guess the OB version uses target:for: > > Cheers, > Alexandre Nope ... you broke OB ... 1. the methods are not identical look at them a little closer 2. we don't have 100% test coverage ... but you knew that:( I've reverted your change so that I can continue working on the problem that you want fixed ... Dale |
> Nope ... you broke OB ...
> > 1. the methods are not identical look at them a little closer > 2. we don't have 100% test coverage ... but you knew that:( > > I've reverted your change so that I can continue working on the problem that you want fixed ... Oups, sorry. I created a testOpening that simply checks if opening an OB browser does not raise an error. Thanks, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
On 03/18/2011 01:20 PM, Alexandre Bergel wrote:
>> Nope ... you broke OB ... >> >> 1. the methods are not identical look at them a little closer >> 2. we don't have 100% test coverage ... but you knew that:( >> >> I've reverted your change so that I can continue working on the problem that you want fixed ... > > > Oups, sorry. > I created a testOpening that simply checks if opening an OB browser does not raise an error. > > Thanks, > Alexandre > I'm not sure how to write a test to validate that the menu is created correctly for OB ... the window opened fine ... it was menu creation that was broken ... I don't think we have any explicit unit tests for that condition (missing method for menu creation) in Morphic either ... don't know how to write those tests either ... BTW, if you update to Metacello 1.0-beta.28.3.2, you'll get the fix for the problem that you're waiting for ...keep in mind that 1.0-beta.28.3.2 _is_ still in development, but it is targeted for MetacelloBrowser Dale |
> BTW, if you update to Metacello 1.0-beta.28.3.2, you'll get the fix for the problem that you're waiting for ...keep in mind that 1.0-beta.28.3.2 _is_ still in development, but it is targeted for MetacelloBrowser
Cool!!! Thanks!!! I checked and it effectively works. I will ask the students to use the browser. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Free forum by Nabble | Edit this page |