MetacelloBrowser

Hi!

I am about to announce http://metacellobrowser.dcc.uchile.cl/ on the pharo mailing list.
Comments are welcome.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Hi!

I am going over your changes. This is really cool.

Some questions. Why having saveConfiguration and savePackages as a menu item?
I usually save my application by adding a new versions. As far as I can see, these two functions are essentially useful for debugging purposes or when the configuration has to be manually changed. No?

> Well, I think I've got all the pieces in place now...  MetacelloBrowser-dkh.43 is the final package , well so far:)

I produced version 1.35 with your version

> ... I have monkeyed with a couple of things in addition to just rewriting the basic algorithms ... You'll have seen Issue 113 that was caused by the fact that packages were being created for unloaded mcz files which caused quite a bit of havoc in the image ... I imagine that some of the bugs you've seen recently were due to this problem ... I've fixed the bug, but had to change some tests that were expecting the buggy behavior...

Yes, thanks

> I also added a dependent project list so you get projects and packages now.

Ahhh... Excellent!!!!

> I changed the way that projects and packages are printed so you can easily tell which packages are loaded and whether or not there is a different version from the one specified loaded ... it would be useful to have bold and italics to emphasize some of these things.

Yes, I will try to add font effects.


> I also added a couple of version menu items: append description and update mcz versions ...

Ok.
"append description" add a comment to the metacello version right?

Why do you need append description? Is it not enough to add the comment when you create the versions?

What does "update mcz" exactly do? The comment found in MetacelloToolBox is a bit obscure to me:
        "Update packageSpecs and (conditionally) the project specs in the given version to reflect the new mcz file and project versions."

Do you feel these menu items are for general consumption or for advanced/debugging?

> I have a few more commands that I want to add to the browser ... commands that I use all of the time ...
>
> I also would like to change the way the new version is done:
>
>  it looks like the new version is created as a release version and the configuration is immediately saved

Yes, I use this all the time.

> I would like to create the new version as a development version and support the steps/operations that I documented in my blog post ....

Ok, so what we can do is, add a button "+Version & Save" next to "+Version"

> I _am_ excited about the potential for MetacelloBrowser and I hope the changes I am making or suggesting aren't offensive to you, I've spent time running scripts over the last few months and the GUI makes things som much nicer...

No, not at all. I am sincerely happy about your contribution.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

I'll try to address your questions in one fell swoop...

The way you have the MetacelloBrowser setup right now is that you do development on a particular project, and manually save mcz files as you do development, then when you are done, you publish a new version of the configuration and immediately release it.

This process isn't wrong, but if you need to test the configuration independently (like loading it into Squeak or different versions of Pharo), you shouldn't release the version as stable immediately.

Instead, you create a version that is in development with a blessing of #development .. a version that is in development is subject to change and no one should load it (identifying development versions is something I want to add to the browser this morning).

In my development style I may keep a version open for development for weeks while I fix bugs and test on various platforms, etc. Only when I am completely happy with the functionality do I release the version. So the additional menu items I have added are not for debugging, but for supporting this development style.

With that all said, I think it is bad form to release a new version without testing it first ... loading it on the target platforms, etc., because once a version is released you are not supposed to change it. So I think that a new version should always be created as a development version then the developer has an opportunity to test the configuration itself and fix bugs in the configuration or fix bugs in the application itself that show up during release testing .. once a configuration has been successfully loaded, it can be released into production.

An example is what happened this morning, you created version 1.35 and released it, and then found after further testing that there were bugs in 1.35 .... If you had created the version in development then it wouldn't be picked up by the load latest instructions that you published for using MetacelloBrowser and there would be no danger that someone would accidentally load a version that is not quite finished ...

When a version is open for development, you will do things in different sequences:

  1. update the description for a version
  2. load a new version of an mcz from another developer

In these two cases you'd like to change the development version specification through the tool (rather than open the version in a code browser and manually make the changes) so the two new menu items: 'append description' and 'update mcz versions' were added to support those operations. At this moment I'm using literal names for the menu items and expect that there are better names. I think you figured out what 'append description'  is for and 'update mcz versions' updates the mcz files in the version spec ... in place ... to reflect the fact that you've loaded a new mcz version (or saved a new mcz version manually) ...

Along the same lines, saveConfiguration just saves the configuration and savePackages saves the modified mcz files in a project and then saves the configuration ... so if you are doing development on an open version of MetacelloBrowser and you are ready to checkpoint your work to share with me or to test on a different platform, you need to save the modified mcz files and then manually update the version with the new mcz file names and then manually save the configuration or you can use savePackages which does all of this automatically for you ...

So I don't actually think that these new commands are for debugging/advanced usage, but they are for everyday use by developers. Some menu items will be used more frequently than others depending upon the developers style...

I think my blog post (http://gemstonesoup.wordpress.com/#walkthrough) explains the process and describes each of these operations in more detail in the context of a development cycle...I really think we should support the development cycle that I've described, tweaking things a bit as we go along.

Dale

On Feb 24, 2011, at 4:59 AM, Alexandre Bergel wrote:

> This process isn't wrong, but if you need to test the configuration independently (like loading it into Squeak or different versions of Pharo), you shouldn't release the version as stable immediately.

What you said makes sense. However, this gives some unnecessary steps in my case. Having green tests is the only prerequisite from releasing a new version. Many people developing in Moose use this approach as well (implicitly so far by using the #default: baseline and not having explicit versions).

I think we should support a simple versioning (as it is now in MetacelloBrowser) and a more advanced one with #development steps before.
Now, the question is how to combine both development processes in the tool. By the way, we could easily imagine another development processes that would include some additional stage, this is another story.

An easy way would be to have the button '+Version release' and '+Version dev'.
A released version could then be listed in bold, and a development version using a normal font.
How does that sound?

> An example is what happened this morning, you created version 1.35 and released it, and then found after further testing that there were bugs in 1.35 .... If you had created the version in development then it wouldn't be picked up by the load latest instructions that you published for using MetacelloBrowser and there would be no danger that someone would accidentally load a version that is not quite finished ...

Yes, but the tests were green (after I fixed them) :-)

> When a version is open for development, you will do things in different sequences:
>
>  1. update the description for a version
>  2. load a new version of an mcz from another developer

Ok. If this is your development process, then MetacelloBrowser should support it.

> In these two cases you'd like to change the development version specification through the tool (rather than open the version in a code browser and manually make the changes) so the two new menu items: 'append description' and 'update mcz versions' were added to support those operations.

Ok, so 'append description' and 'update mcz versions' should appear only on a development version. Are you ok with this?

> At this moment I'm using literal names for the menu items and expect that there are better names. I think you figured out what 'append description'  is for and 'update mcz versions' updates the mcz files in the version spec ... in place ... to reflect the fact that you've loaded a new mcz version (or saved a new mcz version manually) ...
>
> Along the same lines, saveConfiguration just saves the configuration and savePackages saves the modified mcz files in a project and then saves the configuration ... so if you are doing development on an open version of MetacelloBrowser and you are ready to checkpoint your work to share with me or to test on a different platform, you need to save the modified mcz files and then manually update the version with the new mcz file names and then manually save the configuration or you can use savePackages which does all of this automatically for you ...

Ok. I feel that these menu items should appear only if the current version is in #development right? If the current version is #stable, then it does not make sense to have these menu items. Are you ok with this? If yes, then I will update the browser respectively.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Feb 24, 2011, at 7:07 AM, Alexandre Bergel wrote:

>> This process isn't wrong, but if you need to test the configuration independently (like loading it into Squeak or different versions of Pharo), you shouldn't release the version as stable immediately.
>
> What you said makes sense. However, this gives some unnecessary steps in my case. Having green tests is the only prerequisite from releasing a new version. Many people developing in Moose use this approach as well (implicitly so far by using the #default: baseline and not having explicit versions).

>
> I think we should support a simple versioning (as it is now in MetacelloBrowser) and a more advanced one with #development steps before.
> Now, the question is how to combine both development processes in the tool. By the way, we could easily imagine another development processes that would include some additional stage, this is another story.
>

Yes, this is the challenge .. there is no "one right way to do things", but we are trying to accommodate them all with a single tool.


> An easy way would be to have the button '+Version release' and '+Version dev'.
> A released version could then be listed in bold, and a development version using a normal font.
> How does that sound?

I'd be inclined to keep the number of buttons to a minimum ... since I appear to be in the minority here, I wouldn't mind if the '+version dev' was on the menu only...the button bar should be reserved for the common case ...

Agreed. BTW, I don't like the names (you should know by now that I am horrible at naming things:), so better names need to be defined, but they _are_ only applicable to development versions  so this makes lots of sense.

>
>> At this moment I'm using literal names for the menu items and expect that there are better names. I think you figured out what 'append description'  is for and 'update mcz versions' updates the mcz files in the version spec ... in place ... to reflect the fact that you've loaded a new mcz version (or saved a new mcz version manually) ...
>>
>> Along the same lines, saveConfiguration just saves the configuration and savePackages saves the modified mcz files in a project and then saves the configuration ... so if you are doing development on an open version of MetacelloBrowser and you are ready to checkpoint your work to share with me or to test on a different platform, you need to save the modified mcz files and then manually update the version with the new mcz file names and then manually save the configuration or you can use savePackages which does all of this automatically for you ...
>
> Ok. I feel that these menu items should appear only if the current version is in #development right? If the current version is #stable, then it does not make sense to have these menu items. Are you ok with this? If yes, then I will update the browser respectively.

I would think that the saveConfiguration menu item would be conditional on whether or not the configuration was dirty or not ... regardless of how it got that way or which version is current.

The savePackages menu item should probably be moved to the version menu ... then the meaning of savePackages for a version is to make that version match the loaded state of the image ...

Dale

>> An easy way would be to have the button '+Version release' and '+Version dev'.
>> A released version could then be listed in bold, and a development version using a normal font.
>> How does that sound?
>
> I'd be inclined to keep the number of buttons to a minimum ... since I appear to be in the minority here, I wouldn't mind if the '+version dev' was on the menu only...the button bar should be reserved for the common case ...

I agree. '+Version' means adding a development release version.
By right-clicking on a version, you can set it as a release.

>> Ok, so 'append description' and 'update mcz versions' should appear only on a development version. Are you ok with this?
>
> Agreed. BTW, I don't like the names (you should know by now that I am horrible at naming things:), so better names need to be defined, but they _are_ only applicable to development versions  so this makes lots of sense.

I think that 'set comment' and 'update packages' is a bit better. Are you okay? If yes, I do the change

>>> At this moment I'm using literal names for the menu items and expect that there are better names. I think you figured out what 'append description'  is for and 'update mcz versions' updates the mcz files in the version spec ... in place ... to reflect the fact that you've loaded a new mcz version (or saved a new mcz version manually) ...
>>>
>>> Along the same lines, saveConfiguration just saves the configuration and savePackages saves the modified mcz files in a project and then saves the configuration ... so if you are doing development on an open version of MetacelloBrowser and you are ready to checkpoint your work to share with me or to test on a different platform, you need to save the modified mcz files and then manually update the version with the new mcz file names and then manually save the configuration or you can use savePackages which does all of this automatically for you ...
>>
>> Ok. I feel that these menu items should appear only if the current version is in #development right? If the current version is #stable, then it does not make sense to have these menu items. Are you ok with this? If yes, then I will update the browser respectively.
>
> I would think that the saveConfiguration menu item would be conditional on whether or not the configuration was dirty or not ... regardless of how it got that way or which version is current.
>
> The savePackages menu item should probably be moved to the version menu ... then the meaning of savePackages for a version is to make that version match the loaded state of the image ...

Something important. I like the idea to save the whole set of dirty packages by creating a new version. Are you okay with it?

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Feb 24, 2011, at 9:55 AM, Alexandre Bergel wrote:

>>> An easy way would be to have the button '+Version release' and '+Version dev'.
>>> A released version could then be listed in bold, and a development version using a normal font.
>>> How does that sound?
>>
>> I'd be inclined to keep the number of buttons to a minimum ... since I appear to be in the minority here, I wouldn't mind if the '+version dev' was on the menu only...the button bar should be reserved for the common case ...
>
> I agree. '+Version' means adding a development release version.
> By right-clicking on a version, you can set it as a release.

Agreed.

>
>>> Ok, so 'append description' and 'update mcz versions' should appear only on a development version. Are you ok with this?
>>
>> Agreed. BTW, I don't like the names (you should know by now that I am horrible at naming things:), so better names need to be defined, but they _are_ only applicable to development versions  so this makes lots of sense.
>
> I think that 'set comment' and 'update packages' is a bit better. Are you okay? If yes, I do the change

Agreed.

Agreed to a certain extent ... I think this wanders into the realm of development process and I've got a post that I'll be sending out soon that gets into development process .... the issue being which development process is one following?

Dale

> Agreed to a certain extent ... I think this wanders into the realm of development process and I've got a post that I'll be sending out soon that gets into development process .... the issue being which development process is one following?


The currently behavior of +Version is saving the dirty packages and the configuration.
We could have a menu on the configuration titled '+Version without saving' ?

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Feb 24, 2011, at 10:42 AM, Alexandre Bergel wrote:

>> Agreed to a certain extent ... I think this wanders into the realm of development process and I've got a post that I'll be sending out soon that gets into development process .... the issue being which development process is one following?
>
>
> The currently behavior of +Version is saving the dirty packages and the configuration.
> We could have a menu on the configuration titled '+Version without saving' ?

Again, I don't think it is a good idea to clutter the buttons ...

I've just sent off my post about the development process (enforcement post) so this may be redundant...

If you are releasing a version (which is the current implementation of +Version), then it makes sense to save dirty packages, update the specs and then save the configuration.

If you are opening a version for development, then you are not going to save dirty packages and it may or may not make sense to save the configuration ... opening the version for development is just one of several steps along the way towards the eventual release,

So I think that '+Version without saving' isn't useful anyway and the necessary functionality is covered by 'add dev version' (better names welcome:)...

Dale

>>> Agreed to a certain extent ... I think this wanders into the realm of development process and I've got a post that I'll be sending out soon that gets into development process .... the issue being which development process is one following?
>>
>>
>> The currently behavior of +Version is saving the dirty packages and the configuration.
>> We could have a menu on the configuration titled '+Version without saving' ?
>
> Again, I don't think it is a good idea to clutter the buttons ...

I meant a menu item when right-clicking on a configuration.

> I've just sent off my post about the development process (enforcement post) so this may be redundant...
>
> If you are releasing a version (which is the current implementation of +Version), then it makes sense to save dirty packages, update the specs and then save the configuration.
>
> If you are opening a version for development, then you are not going to save dirty packages and it may or may not make sense to save the configuration ... opening the version for development is just one of several steps along the way towards the eventual release,
>
> So I think that '+Version without saving' isn't useful anyway and the necessary functionality is covered by 'add dev version' (better names welcome:)...

Ok, se we stay with the current implementation of +Version? We can add an option for saving or not packages in a near future then?

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Feb 24, 2011, at 12:01 PM, Alexandre Bergel wrote:

yes...