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

Re: [Pharo-project] what happened to the "load code updates" button in the left flap?

by StÃ©phane Ducasse

I agree. >> Simple users don't need to update in my opinion. Using the different > releases should be enough. I was fed up to see this ugly flap under my nose all the time :) Stef

June 27, 2008

Re: [Pharo-project] Fwd: [squeak-dev] Units package

by StÃ©phane Ducasse

On Jun 27, 2008, at 9:35 AM, Michael Rueger wrote: > Marcus Denker wrote: >> On 27.06.2008, at 09:04, StÃ©phane Ducasse wrote: >>>> >>>> we should harvest the Units....latest version >>>> >> Do we want it as part of the image? > > Question is whether we view Pharo more as a distribution: > small kernel and a (large) set of loadable additions that are know > to work (pass tests). > Which would be the model I prefer :-) I would that way too. Even if for regex I would do the inverse to clean some part that deliberately needs a good regex. Now I would like to check sake to see how we can build a process to check out and run tests automatically. > I would even go so far to have minimalistic Date/Time features, but > then the ability to load Chronos if I need it. Very simple > HTTPClient vs libCurl or a full native implementation etc etc. > > Michael > > _______________________________________________ > 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 Hilaire Fernandes

I tried yesterday LPF on Pharo, infortunately when loading Magma beta MC blows on my face again. I will give a fresh start again. Hilaire 2008/6/27 Matthew Fulmer <tapplek(a)gmail.com>: > On Fri, Jun 27, 2008 at 09:32:35AM +0200, Hilaire Fernandes wrote: >> Oh, Chris I am just a dumb developer and I don't know much about the >> tools, I just know it is a pain to get MC 1.5 working. > > 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, 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 > - 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" > - Working MonticelloConfigurations > - 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. > 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. The biggest remaining issue is Traits > support; 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. > > > > 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. > > -- > 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 > -- http://blog.ofset.org/hilaire

June 27, 2008

[Pharo-project] Re: Monticello 1.5

by Matthew Fulmer

On Fri, Jun 27, 2008 at 09:32:35AM +0200, Hilaire Fernandes wrote: > Oh, Chris I am just a dumb developer and I don't know much about the > tools, I just know it is a pain to get MC 1.5 working. 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, 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 - 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" - Working MonticelloConfigurations - 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. 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. The biggest remaining issue is Traits support; 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. 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. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

June 27, 2008

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

by Matthew Fulmer

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. > 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. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

June 27, 2008

[Pharo-project] Proposal for external issues

by Norbert Hartl

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

June 27, 2008

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

by Norbert Hartl

On Fri, 2008-06-27 at 00:47 -0700, 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? > No, but I don't think there are that many. But the question is still good. We had a good (but short) thread on squeak-dev about sharing fixes between forks but without a real outcome. I would like to see a matrix where every acknowledged fix will be put in and every fork can have a look at and decide to integrate or not. > Is there a process to > determine which mantis bugs apply to Pharo? > Yes, we decided to double the effort and open tickets in pharo to put fixes from mantis into pharo. If I think once more about it I would create a new issues type mantis. This way we would have a change to find mantis fixes afterwards. As long as there isn't a good solution it is useful to find everything which is already included. I would propose that an issue from mantis is an issue with type "mantis" and status "fixed". That would fit into our "to be created" workflow. Using the mantis ticket number in the issue title will give all information that is needed. > 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. > I don't think that pharo is able to find a broader base on squeak-dev. It is good to have it separate. As soon as etoys is out this definite ;) For me it is just a question how we deal with the other way: bringing fixes from pharo back to squeak. I hope it is enough if squeak releasers scan the pharo issue tracker. > So, how are you using squeak mantis in Pharo? > We don't use mantis we just point to it. Norbert

June 27, 2008

Re: [Pharo-project] what happened to the "load code updates" button in the left flap?

by Damien Cassou

On Fri, Jun 27, 2008 at 10:03 AM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > Oh. Thanks! > > I suggest we add some brief instructions to the welcome window so people > know how to load the latest code updates. It really isn't obvious if you > don't know. Simple users don't need to update in my opinion. Using the different releases should be enough. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 27, 2008

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

by Adrian Lienhard

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. 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. Adrian On Jun 27, 2008, at 09:47 , 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] Squeak bugs, Pharo bugs

by Damien Cassou

On Fri, Jun 27, 2008 at 9:47 AM, Matthew Fulmer <tapplek(a)gmail.com> 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? If there is a report on mantis that you would like to see fixed in Pharo, add an entry to the issue tracking system at http://code.google.com/p/pharo with a link to the mantis report. If a fix exists, publish the package to the PharoInbox after having verify that the mcz can be loaded in a clean Pharo image. Set the status of your report as Fixed and the type to Patch. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 27, 2008

Re: [Pharo-project] what happened to the "load code updates" button in the left flap?

by Oscar Nierstrasz

Oh. Thanks! I suggest we add some brief instructions to the welcome window so people know how to load the latest code updates. It really isn't obvious if you don't know. - on On Jun 27, 2008, at 9:50, Alain Plantec wrote: > On Friday 27 June 2008 09:36:17 Oscar Nierstrasz wrote: >> >> Hi guys, >> >> Haven't had time to look at Pharo for a while. I grabbed the latest >> version (Pharo0.1-10042-2008-06-24.zip) and there is no flap on the >> left hand side. Is there a short cut to load the code updates? > Shared flaps are hidden. > World menu/flaps/Show shared flaps > or cmd-F ? > alain >> >> The Pharo-dev version (pharo-0.1-10036dev08.06.20.zip) still has the >> flap. >> >> Did I miss something? >> >> - on >> >> >> _______________________________________________ >> 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] what happened to the "load code updates" button in the left flap?

by Adrian Lienhard

or World menu -> help -> Update code from server Adrian BTW, apparently hiding the flaps was done manually as I still have them because I use the update stream On Jun 27, 2008, at 09:50 , Alain Plantec wrote: > On Friday 27 June 2008 09:36:17 Oscar Nierstrasz wrote: >> >> Hi guys, >> >> Haven't had time to look at Pharo for a while. I grabbed the latest >> version (Pharo0.1-10042-2008-06-24.zip) and there is no flap on the >> left hand side. Is there a short cut to load the code updates? > Shared flaps are hidden. > World menu/flaps/Show shared flaps > or cmd-F ? > alain >> >> The Pharo-dev version (pharo-0.1-10036dev08.06.20.zip) still has the >> flap. >> >> Did I miss something? >> >> - on >> >> >> _______________________________________________ >> 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] what happened to the "load code updates" button in the left flap?

by Alain Plantec

On Friday 27 June 2008 09:36:17 Oscar Nierstrasz wrote: > > Hi guys, > > Haven't had time to look at Pharo for a while. I grabbed the latest > version (Pharo0.1-10042-2008-06-24.zip) and there is no flap on the > left hand side. Is there a short cut to load the code updates? Shared flaps are hidden. World menu/flaps/Show shared flaps or cmd-F ? alain > > The Pharo-dev version (pharo-0.1-10036dev08.06.20.zip) still has the > flap. > > Did I miss something? > > - on > > > _______________________________________________ > 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] Squeak bugs, Pharo bugs

by Matthew Fulmer

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/

June 27, 2008

[Pharo-project] what happened to the "load code updates" button in the left flap?

by Oscar Nierstrasz

Hi guys, Haven't had time to look at Pharo for a while. I grabbed the latest version (Pharo0.1-10042-2008-06-24.zip) and there is no flap on the left hand side. Is there a short cut to load the code updates? The Pharo-dev version (pharo-0.1-10036dev08.06.20.zip) still has the flap. Did I miss something? - on

June 27, 2008

Re: [Pharo-project] Fwd: [squeak-dev] Units package

by Michael Rueger

Marcus Denker wrote: > > On 27.06.2008, at 09:04, StÃ©phane Ducasse wrote: > >>> >>> we should harvest the Units....latest version >>> > > Do we want it as part of the image? Question is whether we view Pharo more as a distribution: small kernel and a (large) set of loadable additions that are know to work (pass tests). Which would be the model I prefer :-) I would even go so far to have minimalistic Date/Time features, but then the ability to load Chronos if I need it. Very simple HTTPClient vs libCurl or a full native implementation etc etc. Michael

June 27, 2008

Re: [Pharo-project] Fwd: [squeak-dev] Units package

by Hilaire Fernandes

Why not a package in Squeaksource? Hilaire 2008/6/27 Marcus Denker <denker(a)iam.unibe.ch>: > > On 27.06.2008, at 09:04, StÃ©phane Ducasse wrote: > >>> >>> we should harvest the Units....latest version >>> > > Do we want it as part of the image?

June 27, 2008

[Pharo-project] Re: Monticello 1.5

by Hilaire Fernandes

Oh, Chris I am just a dumb developer and I don't know much about the tools, I just know it is a pain to get MC 1.5 working. I am cc to Pharo firends with a small recall of the situation, may be they have some tips Chris is working on new beta version of Magma which I am testing with him. As far as I can understand, Chris use Monticello configuration to be able to load in one click several Magma mcz packages. This requires Monticello 1.5, but this ones does not work equally on the different version of Squeak nor with Pharo. Which tools could be suggested to Chris ? (I can give more details if needed but really this is becoming insane --and unproductive--, and I really hope Pharo people will do it right) Hilaire 2008/6/27 Chris Muller <ma.chris.m(a)gmail.com>: > Well of course I am always open to suggestions. Everyone knows what > the requirement is: one-click loading of an entire (multi-package) > system. Do you know another way I can accomplish this other than > Monticello? What is everyone else doing? > > > > > > On Thu, Jun 26, 2008 at 3:09 PM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: >> Chris, >> >> As MC seems to be a source of frustration, I am wondering why do you >> need it for the beta release of Magma? >> >> Now I really think I want to move in the future to Pharo as the >> development plans are clearer (https://gforge.inria.fr/projects/pharo) >> Yet Seasider are participating to Pharo so I am confident. >> >> I will first try Magma beta and my code as well. >> >> Hilaire >> >> >> -- >> http://blog.ofset.org/hilaire >> > -- http://blog.ofset.org/hilaire

June 27, 2008

Re: [Pharo-project] Fwd: [squeak-dev] Units package

by Marcus Denker

On 27.06.2008, at 09:04, StÃ©phane Ducasse wrote: >> >> we should harvest the Units....latest version >> Do we want it as part of the image? I am a fan of growing the number (and deepness) of abstractions available as part of what one percives as the "language"... e.g. I am quite sure that the math capabilities of the programming language of the future will be more similar to mathematica then to C. Having "native" support for dealing with Units is, I think, something that a language should have built in. In most situations, numbers are used to model something that has a unit... and today we have the memory and processing power to model this in most cases. The units package allows one to write expressions like: 25 inches as cm and do calculations with these units. But there is always the danger of putting "too much" into a system. All the stuff we are cleaning now in pharo is an example for that. So there is definitely a tension between providing more abstraction vs. simplifying the system to it's bare minimum. For the units, I lean towards including them. Marcus >> Begin forwarded message: >> >>> From: "Marcus Denker" <denker(a)iam.unibe.ch> >>> Date: June 24, 2008 2:11:45 PM CEDT >>> To: "BalÃ¡zs KÃ³si" <rebmekop(a)gmail.com> >>> Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> Subject: Re: [squeak-dev] Units package >>> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> >>> Hello, >>> >>> the bug seems to be fixed in the last version. I harvested the >>> test to make sure (this is >>> in Units-md.16 on SqueakSource) >>> >>> The versions starting with -14 contain many enhancements (and the >>> bugfix). This was contributed >>> by Pinesoft (http://www.pinesoft.co.uk/) >>> >>> Maybe the universe version could be updated? >>> >>> Marcus >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> On Thu, Jun 19, 2008 at 4:56 PM, BalÃ¡zs KÃ³si <rebmekop(a)gmail.com> >>> wrote: >>> > UnitValue >> hash >>> > ^value hash bitXor: unit hash >>> > >>> > and >>> > >>> > testEquality >>> > >>> > self deny: (60 units: #seconds) hash = (60 units: >>> #meters) hash. >>> > self deny: (60 units: #seconds) = (60 units: #meters). >>> > self deny: (60 units: #seconds) hash = (1 units: >>> #minutes) hash. >>> > self assert: (60 units: #seconds) = (1 units: #minutes). >>> >>> Much better :) >>> >>> Cheers, BalÃ¡zs >>> >>> ps: cc-d to Marcus Denker, because he seems to be maintainer of >>> the package. >>> >>> >>> >>> >> >> >> > > _______________________________________________ > 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] Fwd: [squeak-dev] Units package

by StÃ©phane Ducasse

> > we should harvest the Units....latest version > > Begin forwarded message: > >> From: "Marcus Denker" <denker(a)iam.unibe.ch> >> Date: June 24, 2008 2:11:45 PM CEDT >> To: "BalÃ¡zs KÃ³si" <rebmekop(a)gmail.com> >> Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> Subject: Re: [squeak-dev] Units package >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> >> Hello, >> >> the bug seems to be fixed in the last version. I harvested the test >> to make sure (this is >> in Units-md.16 on SqueakSource) >> >> The versions starting with -14 contain many enhancements (and the >> bugfix). This was contributed >> by Pinesoft (http://www.pinesoft.co.uk/) >> >> Maybe the universe version could be updated? >> >> Marcus >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> On Thu, Jun 19, 2008 at 4:56 PM, BalÃ¡zs KÃ³si <rebmekop(a)gmail.com> >> wrote: >> > UnitValue >> hash >> > ^value hash bitXor: unit hash >> > >> > and >> > >> > testEquality >> > >> > self deny: (60 units: #seconds) hash = (60 units: #meters) >> hash. >> > self deny: (60 units: #seconds) = (60 units: #meters). >> > self deny: (60 units: #seconds) hash = (1 units: #minutes) >> hash. >> > self assert: (60 units: #seconds) = (1 units: #minutes). >> >> Much better :) >> >> Cheers, BalÃ¡zs >> >> ps: cc-d to Marcus Denker, because he seems to be maintainer of the >> package. >> >> >> >> > > >

June 27, 2008

Re: [Pharo-project] milestone 1 (about squeak flap)

by StÃ©phane Ducasse

thanks! Stef On Jun 26, 2008, at 11:51 AM, Alain Plantec wrote: > On Thursday 26 June 2008 08:48:58 StÃ©phane Ducasse wrote: >> I mean not having squeak in the flap name :) >> > it's done (not really hard to achieve). > I've uploaded PharoFlap package to PhariInbox (sorry, I've forgot > SLICE in the name) : > It simply rename squeak flap > - 'Squeak' -> 'Pharo' > - add Flap>>newPharoFlap as a replacement method for > Flap>>newSqueakFlap > - makes Flap>>newSqueakFlap as deprecated > The look is unchanged (except the color of the flap). > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 26, 2008

Re: [Pharo-project] [ANN] new update

by Norbert Hartl

On Thu, 2008-06-26 at 08:45 +0200, StÃ©phane Ducasse wrote: > how please tell me. > What exactly? To change the status of an issue you just have to click in the textfield then you get a pull down menu with all stati available. To create a status you have to press the admin tab and then issue tracker. Norbert > On Jun 26, 2008, at 12:42 AM, Norbert Hartl wrote: > > > On Wed, 2008-06-25 at 23:50 +0200, Adrian Lienhard wrote: > >> I think closed is better. Everyone knows what it means. > > > > Ok, I changed the issues to "closed" > > > > Norbert > >> Adrian > >> > >> On Jun 25, 2008, at 23:44 , Norbert Hartl wrote: > >> > >>> On Wed, 2008-06-25 at 23:34 +0200, Adrian Lienhard wrote: > >>>> Thanks, Stef! > >>>> Looks good. > >>>> > >>>> In the bug tracker, the status of 3 harvested changes is > >>>> "statusVerified". This does not seem to be a valid state. Shouldn't > >>>> it > >>>> be "Closed" instead?! > >>>> > >>> Yes, I created the "Closed" status exactly for this. I don't think > >>> there is much to do after it is harvested therefor closed. Would > >>> it be better to call it "harvested" ? > >>> > >>> Norbert > >>>> Adrian > >>>> > >>>> On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: > >>>> > >>>>> here is a couple of fixed. > >>>>> BTW yesterday I issued another image. > >>>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> > >>>>> Couple of changes to make more tests work plus fix of finalization > >>>>> logic: > >>>>> - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 > >>>>> ) > >>>>> - FinalizerTest reverted to real test case > >>>>> - added missing class variables to DigitalSigntureAlgorithm > >>>>> - Fix issue #13: TraitsTests pollutes ProtoObject subclasses > >>>>> (Mantis > >>>>> 7090) > >>>>> - make BitmapStreamTest clean up the file > >>>>> bitmapStreamTest.ref.extSeg > >>>>> ------------------------------------------------------ > >>>>> update10043 > >>>>> MVC cleaning step 3 > >>>>> ------------------------------------------------------ > >>>>> update10044 > >>>>> cleaning unimplemented calls > >>>>> ------------------------------------------------------ > >>>>> update10045 > >>>>> Some more cleaning made by Norbert > >>>>> ------------------------------------------------------ > >>>>> update10046 > >>>>> KernelTests-Numbers -- Nan and hex tests broken > >>>>> > >>>>> Collection methods #select: and #collect: have no test > >>>>> > >>>>> MC fixes > >>>>> > >>>>> Remove testAllMethodsWithSourceString > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > > > > > _______________________________________________ > > 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 26, 2008

Re: [Pharo-project] milestone 1 (about squeak flap)

by Alain Plantec

On Thursday 26 June 2008 08:48:58 StÃ©phane Ducasse wrote: > I mean not having squeak in the flap name :) > it's done (not really hard to achieve). I've uploaded PharoFlap package to PhariInbox (sorry, I've forgot SLICE in the name) : It simply rename squeak flap - 'Squeak' -> 'Pharo' - add Flap>>newPharoFlap as a replacement method for Flap>>newSqueakFlap - makes Flap>>newSqueakFlap as deprecated The look is unchanged (except the color of the flap). alain

June 26, 2008

Re: [Pharo-project] ReleaseTest>>testUnimplementedCalls

by Adrian Lienhard

Hi Norbert, yes, I think this makes sense. Like this we can remove all cases that we know are ok. The tests then becomes actually useful. Adrian On Jun 26, 2008, at 00:38 , Norbert Hartl wrote: > I thought once more about this test. I'm reluctant to have > this test removed. On the other hand is Adrien right. He > states that a lot of test classes are doing calls to methods > they created while the test runs. > > One solution would be to change the test to use perform: to > invoke those methods. But that would making tests a bit > tedious. So this is not my preferred solution. > > I tweaked SystemNavigation>>allUnimplementedNonPrimitiveCalls > to > > allUnimplementedNonPrimitiveCallsX > "Answer an Array of each message that is sent by an expression in a > method but is not implemented by any object in the system." > | all meth dict | > dict := Dictionary new. > all := self systemNavigation allImplementedMessages. > self systemNavigation allBehaviorsDo: [:cl | > cl selectorsDo: [:sel | > meth := cl compiledMethodAt: sel. > meth primitive = 0 ifTrue: [ > meth messages do: [:m | > (all includes: m) ifFalse: [ > ((dict at: cl ifAbsentPut: [ Dictionary new ]) > at: sel ifAbsentPut: [ OrderedCollection new]) > add: m > ] > ] > ] > ] > ]. > ^ dict > > So the test would be like > > (SystemNavigation default allUnimplementedNonPrimitiveCallsX > associationsSelect: [:a| > (a key allSuperclasses includes: TestCase) not > ]) isEmpty > > Would this or something similar be useful or is this just a lot of > noise without much of a benefit? > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 26, 2008

Re: [Pharo-project] [ANN] new update

by Adrian Lienhard

First, I think you have to be logged in. Then, click on an issue and then click the link named "Add a comment andmake changes below" at the left hand side. A form is opened with a text field named Status. Adrian On Jun 26, 2008, at 08:45 , StÃ©phane Ducasse wrote: > how please tell me. > > On Jun 26, 2008, at 12:42 AM, Norbert Hartl wrote: > >> On Wed, 2008-06-25 at 23:50 +0200, Adrian Lienhard wrote: >>> I think closed is better. Everyone knows what it means. >> >> Ok, I changed the issues to "closed" >> >> Norbert >>> Adrian >>> >>> On Jun 25, 2008, at 23:44 , Norbert Hartl wrote: >>> >>>> On Wed, 2008-06-25 at 23:34 +0200, Adrian Lienhard wrote: >>>>> Thanks, Stef! >>>>> Looks good. >>>>> >>>>> In the bug tracker, the status of 3 harvested changes is >>>>> "statusVerified". This does not seem to be a valid state. >>>>> Shouldn't >>>>> it >>>>> be "Closed" instead?! >>>>> >>>> Yes, I created the "Closed" status exactly for this. I don't think >>>> there is much to do after it is harvested therefor closed. Would >>>> it be better to call it "harvested" ? >>>> >>>> Norbert >>>>> Adrian >>>>> >>>>> On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: >>>>> >>>>>> here is a couple of fixed. >>>>>> BTW yesterday I issued another image. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> Couple of changes to make more tests work plus fix of >>>>>> finalization >>>>>> logic: >>>>>> - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 >>>>>> ) >>>>>> - FinalizerTest reverted to real test case >>>>>> - added missing class variables to DigitalSigntureAlgorithm >>>>>> - Fix issue #13: TraitsTests pollutes ProtoObject subclasses >>>>>> (Mantis >>>>>> 7090) >>>>>> - make BitmapStreamTest clean up the file >>>>>> bitmapStreamTest.ref.extSeg >>>>>> ------------------------------------------------------ >>>>>> update10043 >>>>>> MVC cleaning step 3 >>>>>> ------------------------------------------------------ >>>>>> update10044 >>>>>> cleaning unimplemented calls >>>>>> ------------------------------------------------------ >>>>>> update10045 >>>>>> Some more cleaning made by Norbert >>>>>> ------------------------------------------------------ >>>>>> update10046 >>>>>> KernelTests-Numbers -- Nan and hex tests broken >>>>>> >>>>>> Collection methods #select: and #collect: have no test >>>>>> >>>>>> MC fixes >>>>>> >>>>>> Remove testAllMethodsWithSourceString >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 26, 2008

Re: [Pharo-project] milestone 1

by StÃ©phane Ducasse

I mean not having squeak in the flap name :) Now this is cool that you come up with this list because I like it a lot since I did not want to push it alone. But now this is different. This is a good goal. It would be good if we can really push that. BTW I will be at RMLL then on "holiday" working on the seaside book. So I may be not reactuve as now (I hope my parent will have a good connection). So next week I will be connected day long, the week after nothing clear, the week after I hope that the box will arrived and that the network will be working. STef On Jun 25, 2008, at 11:59 PM, Adrian Lienhard wrote: > I agree. For Milestone 1 I suggest: > > - carefully check list of 3.10 (and maybe Croquet) fixes and > integrate the ones that make sense (notice, on our wiki there exist > pages listing 3.10.* and Croquet fixes). > > - Check for important fixes posted on Mantis that were not > integrated in 3.10 or were posted more recently. > > - Make all remaining tests pass or mark them as expected failures > (only 2 left!) > > Anything else that would be valuable and does not take too much > effort? > > This version would then be a good candidate for a first release. It > would be good if we have a first release as this allows people to > start moving to Pharo. And its also good that we do not have > fundamental changes that would require code migration. > > Adrian > > PS: Stef, I do not understand what you mean by "putting Pharo in the > flap" > > On Jun 25, 2008, at 09:11 , StÃ©phane Ducasse wrote: > >> for milestone 1 >> - it would be good to have a Pharo in the flap (if any flap) and >> any other better looking lesssqueakish look :L) >> if one of you has time :) > > >> >> >> - when do we want to finish. It would be good to have milestone 1 >> out for esug or before. >> - I would really like to see the items of 3.10 examined. >> >> for milestone 2 >> >> - better building process >> >> - something that I would like us to do is to have a task force >> writing some good class comments. >> If you can think about that it would be good. >> >> Purpose of the class >> Main methods >> Main collaborators >> Example >> Internal representation >> >> Stef >> >> _______________________________________________ >> 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 26, 2008

Re: [Pharo-project] [ANN] new update

by StÃ©phane Ducasse

how please tell me. On Jun 26, 2008, at 12:42 AM, Norbert Hartl wrote: > On Wed, 2008-06-25 at 23:50 +0200, Adrian Lienhard wrote: >> I think closed is better. Everyone knows what it means. > > Ok, I changed the issues to "closed" > > Norbert >> Adrian >> >> On Jun 25, 2008, at 23:44 , Norbert Hartl wrote: >> >>> On Wed, 2008-06-25 at 23:34 +0200, Adrian Lienhard wrote: >>>> Thanks, Stef! >>>> Looks good. >>>> >>>> In the bug tracker, the status of 3 harvested changes is >>>> "statusVerified". This does not seem to be a valid state. Shouldn't >>>> it >>>> be "Closed" instead?! >>>> >>> Yes, I created the "Closed" status exactly for this. I don't think >>> there is much to do after it is harvested therefor closed. Would >>> it be better to call it "harvested" ? >>> >>> Norbert >>>> Adrian >>>> >>>> On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: >>>> >>>>> here is a couple of fixed. >>>>> BTW yesterday I issued another image. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> Couple of changes to make more tests work plus fix of finalization >>>>> logic: >>>>> - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 >>>>> ) >>>>> - FinalizerTest reverted to real test case >>>>> - added missing class variables to DigitalSigntureAlgorithm >>>>> - Fix issue #13: TraitsTests pollutes ProtoObject subclasses >>>>> (Mantis >>>>> 7090) >>>>> - make BitmapStreamTest clean up the file >>>>> bitmapStreamTest.ref.extSeg >>>>> ------------------------------------------------------ >>>>> update10043 >>>>> MVC cleaning step 3 >>>>> ------------------------------------------------------ >>>>> update10044 >>>>> cleaning unimplemented calls >>>>> ------------------------------------------------------ >>>>> update10045 >>>>> Some more cleaning made by Norbert >>>>> ------------------------------------------------------ >>>>> update10046 >>>>> KernelTests-Numbers -- Nan and hex tests broken >>>>> >>>>> Collection methods #select: and #collect: have no test >>>>> >>>>> MC fixes >>>>> >>>>> Remove testAllMethodsWithSourceString >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 26, 2008

Re: [Pharo-project] [ANN] new update

by StÃ©phane Ducasse

Yes but I have no idea no idea how to interact and change these status. Again a geek interface. Stef On Jun 25, 2008, at 11:34 PM, Adrian Lienhard wrote: > Thanks, Stef! > Looks good. > > In the bug tracker, the status of 3 harvested changes is > "statusVerified". This does not seem to be a valid state. Shouldn't > it be "Closed" instead?! > > Adrian > > On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: > >> here is a couple of fixed. >> BTW yesterday I issued another image. >> >> Stef >> >> >> >> Couple of changes to make more tests work plus fix of finalization >> logic: >> - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 >> ) >> - FinalizerTest reverted to real test case >> - added missing class variables to DigitalSigntureAlgorithm >> - Fix issue #13: TraitsTests pollutes ProtoObject subclasses >> (Mantis 7090) >> - make BitmapStreamTest clean up the file bitmapStreamTest.ref.extSeg >> ------------------------------------------------------ >> update10043 >> MVC cleaning step 3 >> ------------------------------------------------------ >> update10044 >> cleaning unimplemented calls >> ------------------------------------------------------ >> update10045 >> Some more cleaning made by Norbert >> ------------------------------------------------------ >> update10046 >> KernelTests-Numbers -- Nan and hex tests broken >> >> Collection methods #select: and #collect: have no test >> >> MC fixes >> >> Remove testAllMethodsWithSourceString >> >> >> >> _______________________________________________ >> 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 26, 2008

Re: [Pharo-project] ReleaseTest>>testUnimplementedCalls

by StÃ©phane Ducasse

I would keep it Now may be we should improve SUnit to add the possibility to have long tests.... I think that this is really important that we do not get stuck with what we have. Stef On Jun 26, 2008, at 12:38 AM, Norbert Hartl wrote: > I thought once more about this test. I'm reluctant to have > this test removed. On the other hand is Adrien right. He > states that a lot of test classes are doing calls to methods > they created while the test runs. > > One solution would be to change the test to use perform: to > invoke those methods. But that would making tests a bit > tedious. So this is not my preferred solution. > > I tweaked SystemNavigation>>allUnimplementedNonPrimitiveCalls > to > > allUnimplementedNonPrimitiveCallsX > "Answer an Array of each message that is sent by an expression in a > method but is not implemented by any object in the system." > | all meth dict | > dict := Dictionary new. > all := self systemNavigation allImplementedMessages. > self systemNavigation allBehaviorsDo: [:cl | > cl selectorsDo: [:sel | > meth := cl compiledMethodAt: sel. > meth primitive = 0 ifTrue: [ > meth messages do: [:m | > (all includes: m) ifFalse: [ > ((dict at: cl ifAbsentPut: [ Dictionary new ]) > at: sel ifAbsentPut: [ OrderedCollection new]) > add: m > ] > ] > ] > ] > ]. > ^ dict > > So the test would be like > > (SystemNavigation default allUnimplementedNonPrimitiveCallsX > associationsSelect: [:a| > (a key allSuperclasses includes: TestCase) not > ]) isEmpty > > Would this or something similar be useful or is this just a lot of > noise without much of a benefit? > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 26, 2008

Re: [Pharo-project] milestone 1

by Serge Stinckwich

2008/6/25 Adrian Lienhard <adi(a)netstyle.ch>: > I agree. For Milestone 1 I suggest: > > - carefully check list of 3.10 (and maybe Croquet) fixes and integrate the > ones that make sense (notice, on our wiki there exist pages listing 3.10.* > and Croquet fixes). > > - Check for important fixes posted on Mantis that were not integrated in > 3.10 or were posted more recently. > > - Make all remaining tests pass or mark them as expected failures (only 2 > left!) > > Anything else that would be valuable and does not take too much effort? > > This version would then be a good candidate for a first release. It would be > good if we have a first release as this allows people to start moving to > Pharo. And its also good that we do not have fundamental changes that would > require code migration. > > Adrian > > PS: Stef, I do not understand what you mean by "putting Pharo in the flap" I guess he would like to have the Pharo Logo into a flap. -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 26, 2008

Re: [Pharo-project] [ANN] new update

by Norbert Hartl

On Wed, 2008-06-25 at 23:50 +0200, Adrian Lienhard wrote: > I think closed is better. Everyone knows what it means. Ok, I changed the issues to "closed" Norbert > Adrian > > On Jun 25, 2008, at 23:44 , Norbert Hartl wrote: > > > On Wed, 2008-06-25 at 23:34 +0200, Adrian Lienhard wrote: > >> Thanks, Stef! > >> Looks good. > >> > >> In the bug tracker, the status of 3 harvested changes is > >> "statusVerified". This does not seem to be a valid state. Shouldn't > >> it > >> be "Closed" instead?! > >> > > Yes, I created the "Closed" status exactly for this. I don't think > > there is much to do after it is harvested therefor closed. Would > > it be better to call it "harvested" ? > > > > Norbert > >> Adrian > >> > >> On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: > >> > >>> here is a couple of fixed. > >>> BTW yesterday I issued another image. > >>> > >>> Stef > >>> > >>> > >>> > >>> Couple of changes to make more tests work plus fix of finalization > >>> logic: > >>> - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 > >>> ) > >>> - FinalizerTest reverted to real test case > >>> - added missing class variables to DigitalSigntureAlgorithm > >>> - Fix issue #13: TraitsTests pollutes ProtoObject subclasses (Mantis > >>> 7090) > >>> - make BitmapStreamTest clean up the file > >>> bitmapStreamTest.ref.extSeg > >>> ------------------------------------------------------ > >>> update10043 > >>> MVC cleaning step 3 > >>> ------------------------------------------------------ > >>> update10044 > >>> cleaning unimplemented calls > >>> ------------------------------------------------------ > >>> update10045 > >>> Some more cleaning made by Norbert > >>> ------------------------------------------------------ > >>> update10046 > >>> KernelTests-Numbers -- Nan and hex tests broken > >>> > >>> Collection methods #select: and #collect: have no test > >>> > >>> MC fixes > >>> > >>> Remove testAllMethodsWithSourceString > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 25, 2008

[Pharo-project] ReleaseTest>>testUnimplementedCalls

by Norbert Hartl

I thought once more about this test. I'm reluctant to have this test removed. On the other hand is Adrien right. He states that a lot of test classes are doing calls to methods they created while the test runs. One solution would be to change the test to use perform: to invoke those methods. But that would making tests a bit tedious. So this is not my preferred solution. I tweaked SystemNavigation>>allUnimplementedNonPrimitiveCalls to allUnimplementedNonPrimitiveCallsX "Answer an Array of each message that is sent by an expression in a method but is not implemented by any object in the system." | all meth dict | dict := Dictionary new. all := self systemNavigation allImplementedMessages. self systemNavigation allBehaviorsDo: [:cl | cl selectorsDo: [:sel | meth := cl compiledMethodAt: sel. meth primitive = 0 ifTrue: [ meth messages do: [:m | (all includes: m) ifFalse: [ ((dict at: cl ifAbsentPut: [ Dictionary new ]) at: sel ifAbsentPut: [ OrderedCollection new]) add: m ] ] ] ] ]. ^ dict So the test would be like (SystemNavigation default allUnimplementedNonPrimitiveCallsX associationsSelect: [:a| (a key allSuperclasses includes: TestCase) not ]) isEmpty Would this or something similar be useful or is this just a lot of noise without much of a benefit? Norbert

June 25, 2008

Re: [Pharo-project] milestone 1

by Adrian Lienhard

I agree. For Milestone 1 I suggest: - carefully check list of 3.10 (and maybe Croquet) fixes and integrate the ones that make sense (notice, on our wiki there exist pages listing 3.10.* and Croquet fixes). - Check for important fixes posted on Mantis that were not integrated in 3.10 or were posted more recently. - Make all remaining tests pass or mark them as expected failures (only 2 left!) Anything else that would be valuable and does not take too much effort? This version would then be a good candidate for a first release. It would be good if we have a first release as this allows people to start moving to Pharo. And its also good that we do not have fundamental changes that would require code migration. Adrian PS: Stef, I do not understand what you mean by "putting Pharo in the flap" On Jun 25, 2008, at 09:11 , StÃ©phane Ducasse wrote: > for milestone 1 > - it would be good to have a Pharo in the flap (if any flap) and any > other better looking lesssqueakish look :L) > if one of you has time :) > > > - when do we want to finish. It would be good to have milestone 1 > out for esug or before. > - I would really like to see the items of 3.10 examined. > > for milestone 2 > > - better building process > > - something that I would like us to do is to have a task force > writing some good class comments. > If you can think about that it would be good. > > Purpose of the class > Main methods > Main collaborators > Example > Internal representation > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 25, 2008

Re: [Pharo-project] [ANN] new update

by Adrian Lienhard

I think closed is better. Everyone knows what it means. Adrian On Jun 25, 2008, at 23:44 , Norbert Hartl wrote: > On Wed, 2008-06-25 at 23:34 +0200, Adrian Lienhard wrote: >> Thanks, Stef! >> Looks good. >> >> In the bug tracker, the status of 3 harvested changes is >> "statusVerified". This does not seem to be a valid state. Shouldn't >> it >> be "Closed" instead?! >> > Yes, I created the "Closed" status exactly for this. I don't think > there is much to do after it is harvested therefor closed. Would > it be better to call it "harvested" ? > > Norbert >> Adrian >> >> On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: >> >>> here is a couple of fixed. >>> BTW yesterday I issued another image. >>> >>> Stef >>> >>> >>> >>> Couple of changes to make more tests work plus fix of finalization >>> logic: >>> - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 >>> ) >>> - FinalizerTest reverted to real test case >>> - added missing class variables to DigitalSigntureAlgorithm >>> - Fix issue #13: TraitsTests pollutes ProtoObject subclasses (Mantis >>> 7090) >>> - make BitmapStreamTest clean up the file >>> bitmapStreamTest.ref.extSeg >>> ------------------------------------------------------ >>> update10043 >>> MVC cleaning step 3 >>> ------------------------------------------------------ >>> update10044 >>> cleaning unimplemented calls >>> ------------------------------------------------------ >>> update10045 >>> Some more cleaning made by Norbert >>> ------------------------------------------------------ >>> update10046 >>> KernelTests-Numbers -- Nan and hex tests broken >>> >>> Collection methods #select: and #collect: have no test >>> >>> MC fixes >>> >>> Remove testAllMethodsWithSourceString >>> >>> >>> >>> _______________________________________________ >>> 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 25, 2008

Re: [Pharo-project] [ANN] new update

by Norbert Hartl

On Wed, 2008-06-25 at 23:34 +0200, Adrian Lienhard wrote: > Thanks, Stef! > Looks good. > > In the bug tracker, the status of 3 harvested changes is > "statusVerified". This does not seem to be a valid state. Shouldn't it > be "Closed" instead?! > Yes, I created the "Closed" status exactly for this. I don't think there is much to do after it is harvested therefor closed. Would it be better to call it "harvested" ? Norbert > Adrian > > On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: > > > here is a couple of fixed. > > BTW yesterday I issued another image. > > > > Stef > > > > > > > > Couple of changes to make more tests work plus fix of finalization > > logic: > > - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 > > ) > > - FinalizerTest reverted to real test case > > - added missing class variables to DigitalSigntureAlgorithm > > - Fix issue #13: TraitsTests pollutes ProtoObject subclasses (Mantis > > 7090) > > - make BitmapStreamTest clean up the file bitmapStreamTest.ref.extSeg > > ------------------------------------------------------ > > update10043 > > MVC cleaning step 3 > > ------------------------------------------------------ > > update10044 > > cleaning unimplemented calls > > ------------------------------------------------------ > > update10045 > > Some more cleaning made by Norbert > > ------------------------------------------------------ > > update10046 > > KernelTests-Numbers -- Nan and hex tests broken > > > > Collection methods #select: and #collect: have no test > > > > MC fixes > > > > Remove testAllMethodsWithSourceString > > > > > > > > _______________________________________________ > > 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 25, 2008

Re: [Pharo-project] [ANN] new update

by Adrian Lienhard

Thanks, Stef! Looks good. In the bug tracker, the status of 3 harvested changes is "statusVerified". This does not seem to be a valid state. Shouldn't it be "Closed" instead?! Adrian On Jun 25, 2008, at 22:12 , StÃ©phane Ducasse wrote: > here is a couple of fixed. > BTW yesterday I issued another image. > > Stef > > > > Couple of changes to make more tests work plus fix of finalization > logic: > - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 > ) > - FinalizerTest reverted to real test case > - added missing class variables to DigitalSigntureAlgorithm > - Fix issue #13: TraitsTests pollutes ProtoObject subclasses (Mantis > 7090) > - make BitmapStreamTest clean up the file bitmapStreamTest.ref.extSeg > ------------------------------------------------------ > update10043 > MVC cleaning step 3 > ------------------------------------------------------ > update10044 > cleaning unimplemented calls > ------------------------------------------------------ > update10045 > Some more cleaning made by Norbert > ------------------------------------------------------ > update10046 > KernelTests-Numbers -- Nan and hex tests broken > > Collection methods #select: and #collect: have no test > > MC fixes > > Remove testAllMethodsWithSourceString > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 25, 2008

[Pharo-project] [ANN] new update

by StÃ©phane Ducasse

here is a couple of fixed. BTW yesterday I issued another image. Stef Couple of changes to make more tests work plus fix of finalization logic: - changed WeakRegistry to use WeakIdentityKeyDictionary (http://bugs.squeak.org/view.php?id=6347 ) - FinalizerTest reverted to real test case - added missing class variables to DigitalSigntureAlgorithm - Fix issue #13: TraitsTests pollutes ProtoObject subclasses (Mantis 7090) - make BitmapStreamTest clean up the file bitmapStreamTest.ref.extSeg ------------------------------------------------------ update10043 MVC cleaning step 3 ------------------------------------------------------ update10044 cleaning unimplemented calls ------------------------------------------------------ update10045 Some more cleaning made by Norbert ------------------------------------------------------ update10046 KernelTests-Numbers -- Nan and hex tests broken Collection methods #select: and #collect: have no test MC fixes Remove testAllMethodsWithSourceString

June 25, 2008

[Pharo-project] Standing against tempest by example :)

by StÃ©phane Ducasse

Begin forwarded message: > From: "Samuel MORELLO" <samuel.morello(a)ouvanous.com> > Date: June 25, 2008 2:09:06 PM CEDT > To: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > http://www.metacafe.com/watch/yt-oNpH5tx4Pu8/lighthouses_and_waves_during_v… > > -- > Samuel > +33 (0)6 20 65 22 99 >

June 25, 2008

Re: [Pharo-project] can you check the last update

by Damien Cassou

On Wed, Jun 25, 2008 at 1:00 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > On Wed, 2008-06-25 at 12:52 +0200, Damien Cassou wrote: >> On Wed, Jun 25, 2008 at 11:05 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> > On Wed, 2008-06-25 at 10:55 +0200, Damien Cassou wrote: >> >> > On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> - removed unnecessary columns Difficulty and Priority from Issue >> >> >> >> Should I remove them completely from the issue tracking system? >> >> >> >> Fixed = Developer made requested changes, QA should verify >> >> Verified = QA has verified that the fix worked >> >> Invalid = This was not a valid issue report >> >> Duplicate = This report duplicates an existing issue >> >> WontFix = We decided to not take action on this issue >> >> Closed = The fix has been treated and issue is closed >> >> >> > >> > I don't understan. I removed the columns in the view as >> > they are only disturbing. What do you mean by showing the >> > list of statusses? >> >> I meant: >> >> Type-Defect = Report of a software defect >> Type-Enhancement = Request for enhancement >> Type-Task = Work item that doesn't change the code or docs >> Type-Patch = Source code patch for review >> Type-Other = Some other kind of issue >> Priority-High = Strongly want to resolve in the specified milestone >> Priority-Medium = Normal priority >> Priority-Low = Might slip to later milestone >> Difficulty-VeryEasy = Anybody can fix that in a few seconds >> Difficulty-Easy = Only little knowledge and time required >> Difficulty-Medium = Knowledge and time required >> Difficulty-Hard = Requires more than one expert >> > Why you want to remove them? Now they are only visible in the admin area > where to don't disturb anyone. But do as you think is best. They can still be set at the bottom of bug raeporats. Just click in the text-fields -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 25, 2008

Re: [Pharo-project] can you check the last update

by StÃ©phane Ducasse

Excellent!!! I like one click todo :) >>> >>> We could do a SLICE for every fix so you could see what needs >>> to be updated. But then it is hard to be sure someone reviewed >>> it. >>> >>> Maybe the best solution is to use the issue tracker on google. >>> That's the purpose it serves. If someone has an update he can >>> open a ticket with type "patch" and status "Fixed". If another >>> one has reviewed it he can change the status to "verified". To >>> see what is ready for update you just filter the issues by >>> status "Verified" >> >> Yes we should do that >> > Ok, I changed a few things: > > - removed unnecessary columns Difficulty and Priority from Issue > list view > - added status closed so it either goes > -> defect -> fix -> verified -> close > or > -> patch -> fix -> verified -> close > - treated a few issues to have correct status > > So Stef, all you have to do is to save this link > > http://code.google.com/p/pharo/issues/list?q=status%3AVerified&can=1 > > and click it if you want to know what to do ;) > > I hope you like it. > > Norbert >>> >>> >>> Norbert >>>> Stef >>>> >>>> On Jun 25, 2008, at 9:45 AM, Norbert Hartl wrote: >>>> >>>>> Are you going to harvest the rest of the packages, too? >>>>> >>>>> KernelTests-al.67 >>>>> Monticello-al.319 >>>>> >>>>> are fixing all but 2 remaining tests. >>>>> Norbert >>>>> >>>>> On Wed, 2008-06-25 at 09:00 +0200, StÃ©phane Ducasse wrote: >>>>>> this is strange when I do a merge with SLICE-randomRemoval I >>>>>> get an >>>>>> emtpy list. >>>>>> Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and >>>>>> randomRemoval >>>>>> the >>>>>> same? >>>>>> Should I close SLICE-randomRemoval? >>>>> >>>>>> Stef >>>>>> >>>>>> On Jun 25, 2008, at 8:52 AM, StÃ©phane Ducasse wrote: >>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> I got some funny unpublished packages and I'm a bit confused. So >>>>>>> could you check what I did. >>>>>>> I was harvesting MVC removal + norbert cleaning SLICE- >>>>>>> UnimplementedCallsFix1-NorbertHartl.1 >>>>>>> >>>>>>> I have to find some time (argh) to improve the process and the >>>>>>> tools. because this is far too much manual. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 25, 2008