[Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal? Stef
Hi Stef. Been busy with work-work so haven't had time to review the EToys removal. There are some methods identified that have not been verified for removal vs. modification, but I've attached the mcz here anyway. There are a few removals in TheWorldMainDockingBar in the etoys removals, no mods there. The DockingBarMorph is, however, used in Polymorph for toolbars. There is a potential conflict in Project>>finalEnterActions that is defined in both Polymorph and EToysRemoval, the EToysRemoval version should work with Polymorph though (based on Polymorph version with an additional removal of "world presenter positionStandardPlayer"). This will cause problems when updating Polymorph though, until I get some time to split off the overrides into a separate package. As for Etoys removal, the package contains changed methods and stubs (flagged for removal). There are some manual steps required to get rid of extra cruft (mostly preferences and scripting forms). Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all
I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I posted a reply to this but it is held "awaiting moderator approval" since the message body is too big. If you like I can repost but put the EToysRemovals on SqueakSource. Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all
I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks I'm busy too :) but thanks I will have a look at that :) Stef On Sep 15, 2008, at 1:16 PM, Gary Chambers wrote:
Hi Stef.
Been busy with work-work so haven't had time to review the EToys removal. There are some methods identified that have not been verified for removal vs. modification, but I've attached the mcz here anyway.
There are a few removals in TheWorldMainDockingBar in the etoys removals, no mods there.
The DockingBarMorph is, however, used in Polymorph for toolbars. There is a potential conflict in Project>>finalEnterActions that is defined in both Polymorph and EToysRemoval, the EToysRemoval version should work with Polymorph though (based on Polymorph version with an additional removal of "world presenter positionStandardPlayer"). This will cause problems when updating Polymorph though, until I get some time to split off the overrides into a separate package.
As for Etoys removal, the package contains changed methods and stubs (flagged for removal). There are some manual steps required to get rid of extra cruft (mostly preferences and scripting forms).
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: "An open mailing list to discuss any topics related to an open- sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all
I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <Pinesoft-Removals-EToys-gvc. 6.mcz>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi gary to relax from real men work (fixing my house :), I was browsing your package. I would like to know what is the semantics of self flag: #toRemove why did you keep the method in general do we have to look at the senders? Stef
Hi Stef.
Been busy with work-work so haven't had time to review the EToys removal. There are some methods identified that have not been verified for removal vs. modification, but I've attached the mcz here anyway.
There are a few removals in TheWorldMainDockingBar in the etoys removals, no mods there.
The DockingBarMorph is, however, used in Polymorph for toolbars. There is a potential conflict in Project>>finalEnterActions that is defined in both Polymorph and EToysRemoval, the EToysRemoval version should work with Polymorph though (based on Polymorph version with an additional removal of "world presenter positionStandardPlayer"). This will cause problems when updating Polymorph though, until I get some time to split off the overrides into a separate package.
As for Etoys removal, the package contains changed methods and stubs (flagged for removal). There are some manual steps required to get rid of extra cruft (mostly preferences and scripting forms).
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: "An open mailing list to discuss any topics related to an open- sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all
I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <Pinesoft-Removals-EToys-gvc. 6.mcz>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 20.09.2008, at 21:20, Stéphane Ducasse wrote:
Hi gary
to relax from real men work (fixing my house :), I was browsing your package. I would like to know what is the semantics of self flag: #toRemove why did you keep the method in general do we have to look at the senders?
another question is if it's really good to use monticello for the removal... if we load it, it moves all overrides into the removal-override category. These we then would have to re-categorize by hand. Maybe for a change like this, a changeset might be better... Marcus
Stef
Hi Stef.
Been busy with work-work so haven't had time to review the EToys removal. There are some methods identified that have not been verified for removal vs. modification, but I've attached the mcz here anyway.
There are a few removals in TheWorldMainDockingBar in the etoys removals, no mods there.
The DockingBarMorph is, however, used in Polymorph for toolbars. There is a potential conflict in Project>>finalEnterActions that is defined in both Polymorph and EToysRemoval, the EToysRemoval version should work with Polymorph though (based on Polymorph version with an additional removal of "world presenter positionStandardPlayer"). This will cause problems when updating Polymorph though, until I get some time to split off the overrides into a separate package.
As for Etoys removal, the package contains changed methods and stubs (flagged for removal). There are some manual steps required to get rid of extra cruft (mostly preferences and scripting forms).
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: "An open mailing list to discuss any topics related to an open- sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all
I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <Pinesoft-Removals-EToys-gvc. 6.mcz>_______________________________________________ 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
I could produce some changeset going over gary removal. Let me know. This is too much fun to finally remove etoy. Stef On Sep 20, 2008, at 9:28 PM, Marcus Denker wrote:
On 20.09.2008, at 21:20, Stéphane Ducasse wrote:
Hi gary
to relax from real men work (fixing my house :), I was browsing your package. I would like to know what is the semantics of self flag: #toRemove why did you keep the method in general do we have to look at the senders?
another question is if it's really good to use monticello for the removal... if we load it, it moves all overrides into the removal-override category. These we then would have to re-categorize by hand.
Maybe for a change like this, a changeset might be better...
Marcus
Stef
Hi Stef.
Been busy with work-work so haven't had time to review the EToys removal. There are some methods identified that have not been verified for removal vs. modification, but I've attached the mcz here anyway.
There are a few removals in TheWorldMainDockingBar in the etoys removals, no mods there.
The DockingBarMorph is, however, used in Polymorph for toolbars. There is a potential conflict in Project>>finalEnterActions that is defined in both Polymorph and EToysRemoval, the EToysRemoval version should work with Polymorph though (based on Polymorph version with an additional removal of "world presenter positionStandardPlayer"). This will cause problems when updating Polymorph though, until I get some time to split off the overrides into a separate package.
As for Etoys removal, the package contains changed methods and stubs (flagged for removal). There are some manual steps required to get rid of extra cruft (mostly preferences and scripting forms).
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: "An open mailing list to discuss any topics related to an open- sourceSmalltalk" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar
Hi all
I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <Pinesoft-Removals-EToys-gvc. 6.mcz>_______________________________________________ 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
first one of a long series. I will go over all the extensions of gary removal and slowly removed them all and check the senders. Please have a look. "Change Set: removalIsUniClass Date: 20 September 2008 Author: Stephane.Ducasse Remove isUniClass and fix senders. Note that for senders that were defined in Etoy I just removed their body"
Version 2 On Sep 20, 2008, at 10:07 PM, Stéphane Ducasse wrote:
first one of a long series. I will go over all the extensions of gary removal and slowly removed them all and check the senders. Please have a look.
"Change Set: removalIsUniClass Date: 20 September 2008 Author: Stephane.Ducasse
Remove isUniClass and fix senders. Note that for senders that were defined in Etoy I just removed their body"
<EtoyRemoval-001-removalIsUniClass. 1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Marcus and others Do you think that the cs approach is good because after applying them we will have to publish new packages? So could you harvest these ones for example and let me know what do you think and if cs is better? because I could produce also packages. Stef On Sep 20, 2008, at 10:29 PM, Stéphane Ducasse wrote:
Another one :) Cleaning the inspector.
<EtoyRemoval-002-CleanInspector.2.cs>
Stef_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 21.09.2008, at 18:26, Stéphane Ducasse wrote:
Marcus and others
Do you think that the cs approach is good because after applying them we will have to publish new packages? So could you harvest these ones for example and let me know what do you think and if cs is better? because I could produce also packages.
Packages are good, too. Just a removal package that re-classifies the methods is not good. Marcus
Stef
On Sep 20, 2008, at 10:29 PM, Stéphane Ducasse wrote:
Another one :) Cleaning the inspector.
<EtoyRemoval-002-CleanInspector.2.cs>
Stef_______________________________________________ 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
Ok then I will produce packages in the inbox. I could publish directly but I would like that somebody else has a look at what I'm doing. Stef On Sep 21, 2008, at 7:48 PM, Marcus Denker wrote:
On 21.09.2008, at 18:26, Stéphane Ducasse wrote:
Marcus and others
Do you think that the cs approach is good because after applying them we will have to publish new packages? So could you harvest these ones for example and let me know what do you think and if cs is better? because I could produce also packages.
Packages are good, too. Just a removal package that re-classifies the methods is not good.
Marcus
Stef
On Sep 20, 2008, at 10:29 PM, Stéphane Ducasse wrote:
Another one :) Cleaning the inspector.
<EtoyRemoval-002-CleanInspector.2.cs>
Stef_______________________________________________ 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
On Sat, Sep 20, 2008 at 09:28:08PM +0200, Marcus Denker wrote:
On 20.09.2008, at 21:20, St�phane Ducasse wrote:
Hi gary
to relax from real men work (fixing my house :), I was browsing your package. I would like to know what is the semantics of self flag: #toRemove why did you keep the method in general do we have to look at the senders?
another question is if it's really good to use monticello for the removal... if we load it, it moves all overrides into the removal-override category. These we then would have to re-categorize by hand.
MC1.5 fixed this problem long ago. When overrides are removed, the old version is restored. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
On 22.09.2008, at 00:48, Matthew Fulmer wrote:
On Sat, Sep 20, 2008 at 09:28:08PM +0200, Marcus Denker wrote:
On 20.09.2008, at 21:20, Stéphane Ducasse wrote:
Hi gary
to relax from real men work (fixing my house :), I was browsing your package. I would like to know what is the semantics of self flag: #toRemove why did you keep the method in general do we have to look at the senders?
another question is if it's really good to use monticello for the removal... if we load it, it moves all overrides into the removal-override category. These we then would have to re-categorize by hand.
MC1.5 fixed this problem long ago. When overrides are removed, the old version is restored.
Cool! But that does not help here: the removal package changes the methods to the state that you want to keep. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
CS would be better, just had to use a package due to being interleaved with other work... Note that with MC there is no mechanism for removing a method! Perhaps I should have just done the changed methods along with an initialize that would clean up other dependencies, after which an unload of EToys could be done. Regards, Gary. ----- Original Message ----- From: "Marcus Denker" <denker@iam.unibe.ch> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project@lists.gforge.inria.fr> Sent: Sunday, September 21, 2008 6:48 PM Subject: Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar On 21.09.2008, at 18:26, Stéphane Ducasse wrote:
Marcus and others
Do you think that the cs approach is good because after applying them we will have to publish new packages? So could you harvest these ones for example and let me know what do you think and if cs is better? because I could produce also packages.
Packages are good, too. Just a removal package that re-classifies the methods is not good. Marcus
Stef
On Sep 20, 2008, at 10:29 PM, Stéphane Ducasse wrote:
Another one :) Cleaning the inspector.
<EtoyRemoval-002-CleanInspector.2.cs>
Stef_______________________________________________ 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
participants (4)
-
Gary Chambers -
Marcus Denker -
Matthew Fulmer -
Stéphane Ducasse