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

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

Re: [Pharo-project] Proposal for external issues

by Norbert Hartl

On Fri, 2008-06-27 at 12:53 +0200, StÃ©phane Ducasse wrote: > I like that. > I think that what I hated about the inria task managers was that every > was separated. > With clear tags, having one large list is better for my eyes. May be > it will not scale but we will see. Yes, it is ok for the moment. If it doesn't fit later on we know the requirements then. > I would like to have a list of items that > - I can work on..... > - harvest > > When we have 30 min we should not lost 20 on finding info. > yep. Norbert > Stef > > On Jun 27, 2008, at 10:55 AM, 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] Re: Monticello 1.5

by Adrian Lienhard

On Jun 27, 2008, at 11:41 , Matthew Fulmer wrote: > 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. Adrian

June 27, 2008

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

by StÃ©phane Ducasse

>> 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. Yes! > > >> To contribute code, the process is described here: http://code.google.com/p/pharo/wiki/HowToContribute >> >> We planned to go through Mantis and select changes to be integrated >> in >> Pharo in the next weeks. If you have Mantis fixes that you would like >> to see applied, please provide a list. > > ok. Thanks. I will do so soon. Excellent. Matthew, we are open to people ideas :) We are just fed up about dogma like Etoys should be in the distribution. :)

June 27, 2008

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

by Adrian Lienhard

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

June 27, 2008

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

by StÃ©phane Ducasse

Sure please do! The crew already answered. This is a cool feeling. Stef On Jun 27, 2008, at 9:47 AM, Matthew Fulmer wrote: > Hi. I am wondering what the process is of filing bugs against > Pharo/Squeak, notably ones already in Squeak mantis. This bug > against Networking is longstanding, and has a fix: > > http://bugs.squeak.org/view.php?id=6768 > > Should I try to get it into Pharo? > > Is there a list of Mantis > issues that have been folded into Pharo? > > Is there a process to > determine which mantis bugs apply to Pharo? > > I ask because Pharo is currently, de facto, the only work being > done on Squeak core, and I don't see a good reason to really > push a separate effort and call it 3.11. > > So, how are you using squeak mantis in Pharo? > > -- > 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

Re: [Pharo-project] Proposal for external issues

by StÃ©phane Ducasse

I like that. I think that what I hated about the inria task managers was that every was separated. With clear tags, having one large list is better for my eyes. May be it will not scale but we will see. I would like to have a list of items that - I can work on..... - harvest When we have 30 min we should not lost 20 on finding info. Stef On Jun 27, 2008, at 10:55 AM, 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