- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Proposal for external issues

by Adrian Lienhard

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

June 27, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

>> I realize LevelPlayingField is not the preferred mechanism to >> load stuff into Pharo, and it brings along two other things >> beside Monticello 1.5 (namely, Installer and Launcher). I will >> try to prepare something suitable for loading Monticello 1.5 >> into Pharo, but it cannot be a plain SLICE package, due to the >> Monticello loading problems I explained above. I'll read up at >> http://code.google.com/p/pharo/wiki/HowToContribute >> >> I'll also see what changes Stef and Lukas made to Monticello as >> part of Pharo and attempt to merge them. > > Before you invest a lot of work, we should maybe discuss first > whether we want Monticello 1.5 in Pharo. Personally, I'm sceptic if > this is a good idea. I once had a look and although I know MC quite > well, I didn't manage to understand the changes made in MC 1.5 > within reasonable time. They look pretty hackish and there are a > *lot* of them. You know me :) I trust you. ;) Now if matthew can really separate things and make them cleaner. Else we keep our old version. stef

June 27, 2008

Re: [Pharo-project] Squeak bugs, Pharo bugs

by StÃ©phane Ducasse

yes but ou will read the fix notes on mantis anyway. Stef On Jun 27, 2008, at 12:55 PM, Adrian Lienhard wrote: > > On Jun 27, 2008, at 10:56 , Matthew Fulmer wrote: > >> On Fri, Jun 27, 2008 at 10:21:33AM +0200, Adrian Lienhard wrote: >>> Hi Matthew, >>> >>> Every change needs an entry on our issue tracker http://code.google.com/p/pharo/ >>> . For fixes originating in Mantis, just add a link to the Mantis >>> issue >>> there. We should consider adding a note to Mantis when a fix was >>> integrated in Pharo. >> >> I would suggest creating an issue in mantis named "Fixes >> incorperated into Pharo 0.1, and marking all incorperated issues >> as children of that one. That way, mantis will have an easily >> searchable record of what has been incorperated into Pharo. > > If it is as simple as adding a note (I don't know), then this may be > a good solution. I'll check when we start integrating changes. What > I want to avoid, though, is that we increase our administrative work. > > Adrian > > _______________________________________________ > 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] Re: Monticello 1.5

by StÃ©phane Ducasse

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. we did not want to break the dependency mechanism - the problem with PLF is that it looks like a black box that loads a lot of stuff and we do not know why - since we do **everything** with MC is should work 100% or we are dead. 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. 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. >> Indeed. Monticello is hard to load, precisely because the loader > is being modified while loading. Thus, we have a script that is > able to reliably load Monticello 1.5 onto any image: > > http://installer.pbwiki.org/LevelPlayingField > > To run it, do this: (I just tested it and got it working in > Pharo) > > HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' > > The actual job of loading Monticello is done here: > > http://installer.pbwiki.org/LevelPlayingField-Monticello15 > > Notice the technique: first a plain file-out of PackageInfo and > Monticello is loaded, next, nearly the exact same packages is > loaded via Monticello. This ensures that the changes made to > Monticello while Monticello is running are minimal. I keep that > script up-to-date as I make changes to Monticello 1.5. > > Monticello and PackageInfo have a number of improvements: > > - Packages can be loaded out-of-order, what does it mean exactly? > as orphaned methods and > classes are stored in an Orphanage, which is revisited when > loading later packages > > - Tests can be separately packages from the main code, without > extensive repackaging: Name a package Monticello.impl to get > classes in Monticello-*, except for those that end in *-Tests, > or name a package Monticello.tests to get all packages in > categories Monticello-*-Tests We would go for real packages = without relying only on naming conventions so I do not know if this one is really useful. > > - A new dual version sorter, able to view changes between > arbitrary versions in a repository; in the right pane of the > MC browser, use the menu item "open dual changes browser" Cool > > - Working MonticelloConfigurations That I would really want and per package source so that we can load magritte in luask repos and moose in squeaksource and ob in wiresong > - I am fixing bugs in a new loader for Monticello that does code > loading in a truly atomic fashion: code is swapped into the > system, and pointers are revised in exactly ONE primitive. I > have it working well enough that I made it my default loader. This is really important. > > It is able to load problematic packages that are sensitive to > inconsistencies during loading, like Monticello and Morphic. > As an Acid test, I am able to load Monticello using the new > package loader, which has, until now, been impossible in any > version of Monticello. Good > The biggest remaining issue is Traits > support; Argh this is on my pipeline to check andreas proposal to have traits as subclass of classdescription but I did not find the time to check that. > Packages with traits are not supported. To try it > out, run this after running the LPF script above: > > Installer install: 'Monticello16-Beta' > > In the past, people have had various problems with Monticello > 1.5, such as loading FFI and strange issues with Instance > variables. Keith and I were somewhat unaware of these until they > were brought to our attention on IRC, and have since been fixed. > This product is under active development, and our goal is to get > the same very useful version of Monticello running on every > active Squeak platform, and we have done so, to the best of our > knowledge. So if you find a problem, please let us know and we > will fix it, most likely within the hour. IRC is the best way; > mailing lists are next. Excellent. > > I realize LevelPlayingField is not the preferred mechanism to > load stuff into Pharo, exact. I will be against loading stuff nobody look at. > and it brings along two other things > beside Monticello 1.5 (namely, Installer and Launcher). I like the installer even if one day we will refactor it :) > I will try to prepare something suitable for loading Monticello 1.5 > into Pharo, but it cannot be a plain SLICE package, due to the > Monticello loading problems I explained above. I'll read up at > http://code.google.com/p/pharo/wiki/HowToContribute Sure this is the rule for simple stuff. after we can use Installer or Cs. > I'll also see what changes Stef and Lukas made to Monticello as > part of Pharo and attempt to merge them. We wanted to have a rock solid version because it is and will be our backbone. > > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > 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