June 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Re: Monticello 1.5

by Matthew Fulmer

On Fri, Jun 27, 2008 at 01:09:36PM +0200, St?phane Ducasse wrote: > Hi matthew > > > Thanks for your explanation. > We were afraid by MC1.5 because > - the atomic loading features as hacked by ralph looked dubious to us. Ralph's pseudo-atomic loader is not in MC1.5, according to Keith; however, a different pseudo-atomic loader written by keith is the default loader. It also includes the old loader (disabled by default), and an experimental true atomic loader (also disabled by default). > we did not want to break the dependency mechanism As far as I am able to tell, MC1.5 has not touched the dependency mechanism, and it works fine on what I have tried it with (which is only Nile, so far) > - the problem with PLF is that it looks like a black box that loads > a lot of stuff and we do not know why LPF loads Installer, then Monticello 1.5, then Loader. That is all. It does this by using Installer, which is able to fetch scripts off the web, dispatching optionally based on the image version (Squeak3.9, Pharo0.1), and by author initials. Look at the bottom of http://installer.pbwiki.com/LevelPlayingField First it runs the script LevelPlayingField-Preamble, then it runs one of the LevelPlayingField-<image version> scripts, and finally it runs the LevelPlayingField-Postscript script That is all it does. The scripts are linked and viewable on the web, so you can check what they do, and edit them by logging into the wiki (password is squeak) > - since we do **everything** with MC is should work 100% or we are > dead. So do we. We keep it working > Now we would be happy to ask our MC expert (yes I looked at adrian and > lukas) :) > to check your changes and slowly incorporate them. Ok. Do what suits your fancy. Seems like a strange approach, though, since that is exactly what MC1.5 is: a merge of all the features from all the older forks of Monticello: impara, 3.9, with a much more careful eye on backward compatability. Unlike Monticello in 3.9, MC1.5 can save packages that Monticello in 3.8 is able to read and load. > Alex did a small but cool improvement: dirty packages are always at > the top of the mc browser. > We found that cool and integrate it. I'll integrate it too. Thanks for the notification. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

June 27, 2008

RE: [Pharo-project] EToys removal

by Gary Chambers

No problem then. How do you need it signed? As always, anything released to the community from Pinesoft is MIT license. Regards, Gary. > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of > Stephane Ducasse > Sent: 27 June 2008 6:00 PM > To: An open mailing list to discuss any topics related to an > open-sourceSmalltalk > Subject: Re: [Pharo-project] EToys removal > > > Hi gary > > > Thanks. As indicated in my previous emails the removal currently > > consists of > > an MC package that provides "blank" methods for those to be removed > > and > > modified versions for disintegration (!)... > > I like that sound :) Zap! > > We could then proceed with the disintegration and the rest. > > > Will have to check against existing Pharo removals for the latter. > > > > At present the methods are marked 'gvc' as the author... guess that > > needs to > > change given the policy for Pharo. > > Do not worry for the gvc jsut signe the license agreement so that we > stay clean. > > Stef > > > > > > > > Regards, Gary. > > > >> -----Original Message----- > >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of > >> Alain > >> Plantec > >> Sent: 27 June 2008 4:50 PM > >> To: pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] EToys removal > >> > >> > >> On Friday 27 June 2008 16:46:52 Gary Chambers wrote: > >>> Just to say that my investigation is almost complete. Having > >> completed most > >>> of our work on the various Pinesoft Sprints I should have a bit > >> more time > >>> for it... > >>> > >>> Obviously there is some overlap with MVC/Nebraska/ScriptLoader > >> removal (and > >>> a bit of UI Enhancements modifications) though. > >>> > >>> Just a concern, forgiving a quote from Alain's email, "Stephane > >>> seems to > >>> prefer that I work on Etoy removing". > >>> > >>> I'm wondering the best way forward with this now. > >> maybe you can just send here what you've done. > >> I will make a try and help in order to make a slice package if > >> needed. > >> alain > >>> > >>> Regards, Gary. > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2008

Re: [Pharo-project] EToys removal

by StÃ©phane Ducasse

Hi gary > Thanks. As indicated in my previous emails the removal currently > consists of > an MC package that provides "blank" methods for those to be removed > and > modified versions for disintegration (!)... I like that sound :) Zap! We could then proceed with the disintegration and the rest. > Will have to check against existing Pharo removals for the latter. > > At present the methods are marked 'gvc' as the author... guess that > needs to > change given the policy for Pharo. Do not worry for the gvc jsut signe the license agreement so that we stay clean. Stef > > > Regards, Gary. > >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of >> Alain >> Plantec >> Sent: 27 June 2008 4:50 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] EToys removal >> >> >> On Friday 27 June 2008 16:46:52 Gary Chambers wrote: >>> Just to say that my investigation is almost complete. Having >> completed most >>> of our work on the various Pinesoft Sprints I should have a bit >> more time >>> for it... >>> >>> Obviously there is some overlap with MVC/Nebraska/ScriptLoader >> removal (and >>> a bit of UI Enhancements modifications) though. >>> >>> Just a concern, forgiving a quote from Alain's email, "Stephane >>> seems to >>> prefer that I work on Etoy removing". >>> >>> I'm wondering the best way forward with this now. >> maybe you can just send here what you've done. >> I will make a try and help in order to make a slice package if >> needed. >> alain >>> >>> Regards, Gary. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2008

RE: [Pharo-project] EToys removal

by Gary Chambers

Thanks. As indicated in my previous emails the removal currently consists of an MC package that provides "blank" methods for those to be removed and modified versions for disintegration (!)... Will have to check against existing Pharo removals for the latter. At present the methods are marked 'gvc' as the author... guess that needs to change given the policy for Pharo. Regards, Gary. > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of Alain > Plantec > Sent: 27 June 2008 4:50 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] EToys removal > > > On Friday 27 June 2008 16:46:52 Gary Chambers wrote: > > Just to say that my investigation is almost complete. Having > completed most > > of our work on the various Pinesoft Sprints I should have a bit > more time > > for it... > > > > Obviously there is some overlap with MVC/Nebraska/ScriptLoader > removal (and > > a bit of UI Enhancements modifications) though. > > > > Just a concern, forgiving a quote from Alain's email, "Stephane seems to > > prefer that I work on Etoy removing". > > > > I'm wondering the best way forward with this now. > maybe you can just send here what you've done. > I will make a try and help in order to make a slice package if needed. > alain > > > > Regards, Gary. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2008

Re: [Pharo-project] EToys removal

by Alain Plantec

On Friday 27 June 2008 16:46:52 Gary Chambers wrote: > Just to say that my investigation is almost complete. Having completed most > of our work on the various Pinesoft Sprints I should have a bit more time > for it... > > Obviously there is some overlap with MVC/Nebraska/ScriptLoader removal (and > a bit of UI Enhancements modifications) though. > > Just a concern, forgiving a quote from Alain's email, "Stephane seems to > prefer that I work on Etoy removing". > > I'm wondering the best way forward with this now. maybe you can just send here what you've done. I will make a try and help in order to make a slice package if needed. alain > > Regards, Gary. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

June 27, 2008

[Pharo-project] EToys removal

by Gary Chambers

Just to say that my investigation is almost complete. Having completed most of our work on the various Pinesoft Sprints I should have a bit more time for it... Obviously there is some overlap with MVC/Nebraska/ScriptLoader removal (and a bit of UI Enhancements modifications) though. Just a concern, forgiving a quote from Alain's email, "Stephane seems to prefer that I work on Etoy removing". I'm wondering the best way forward with this now. Regards, Gary.

June 27, 2008

Re: [Pharo-project] SLICE-enhanceUnimplementedCallsTest

by Norbert Hartl

And for the new workflow: This is issue #22. And don't forget to sometimes visit http://code.google.com/p/pharo/issues/list?can=1&q=status%3AFixed Norbert On Fri, 2008-06-27 at 16:08 +0200, Norbert Hartl wrote: > I've uploaded a new slice which adjusts the ReleaseTest > for unimplemented calls. Two convenience methods are > added. > > SystemNavigation default allClassesWithUnimplementedCalls > PackageOrganizer default allPackagesContainingUnimplementedCalls > > Can someone review this? > > Btw. you do I mark a certain test as expected failure? > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2008

[Pharo-project] SLICE-enhanceUnimplementedCallsTest

by Norbert Hartl

I've uploaded a new slice which adjusts the ReleaseTest for unimplemented calls. Two convenience methods are added. SystemNavigation default allClassesWithUnimplementedCalls PackageOrganizer default allPackagesContainingUnimplementedCalls Can someone review this? Btw. you do I mark a certain test as expected failure? Norbert

June 27, 2008

Re: [Pharo-project] Proposal for external issues

by Norbert Hartl

On Fri, 2008-06-27 at 13:12 +0200, Adrian Lienhard wrote: > Norbert, I think this is a good idea! > > I updated the page http://code.google.com/p/pharo/wiki/HowToContribute > on how to use the issue tracker. > Good! I would have done it else :) I just need to add that what I said is also applicable for 3.10, 3.11 and so. Therefor we can add Type-3dot10, Type-croquet etc. Norbert > Cheers, > Adrian > > On Jun 27, 2008, at 10:55 , Norbert Hartl wrote: > > > Every now and then someone tries to improve the way to > > go by introducing new processes. Most of time nobody likes > > them and they fail :) > > > > We have several types of changes that we want to integrate > > in pharo: > > > > - enhancements to the platform > > - fixes for reported defects > > - fixes from another squeak release (e.g. 3.10) > > - fixes from other bug databases like mantis > > > > The type of an issue you open on google is pretty near to that. > > Just think about it as a source where the change has its origin. > > For this purpose I created a Type-Mantis in the tracker to assign > > to tickets from mantis we like to integrate. It might be a step > > more to do when opening a ticket but the outcome is that we track > > a list of things already done. > > > > if you look at > > > > http://code.google.com/p/pharo/issues/list?can=1&q=label%3AType-Mantis > > > > you can see what I mean. I think this way it is easier to track > > things. > > > > What do you think? > > > > Norbert > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2008

Re: [Pharo-project] Proposal for external issues

by StÃ©phane Ducasse

thanks this is clearer that what I could write :) Stef On Jun 27, 2008, at 1:12 PM, Adrian Lienhard wrote: > Norbert, I think this is a good idea! > > I updated the page http://code.google.com/p/pharo/wiki/ > HowToContribute on how to use the issue tracker. > > Cheers, > Adrian > > On Jun 27, 2008, at 10:55 , Norbert Hartl wrote: > >> Every now and then someone tries to improve the way to >> go by introducing new processes. Most of time nobody likes >> them and they fail :) >> >> We have several types of changes that we want to integrate >> in pharo: >> >> - enhancements to the platform >> - fixes for reported defects >> - fixes from another squeak release (e.g. 3.10) >> - fixes from other bug databases like mantis >> >> The type of an issue you open on google is pretty near to that. >> Just think about it as a source where the change has its origin. >> For this purpose I created a Type-Mantis in the tracker to assign >> to tickets from mantis we like to integrate. It might be a step >> more to do when opening a ticket but the outcome is that we track >> a list of things already done. >> >> if you look at >> >> http://code.google.com/p/pharo/issues/list?can=1&q=label%3AType- >> Mantis >> >> you can see what I mean. I think this way it is easier to track >> things. >> >> What do you think? >> >> Norbert >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2008