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

Re: [Pharo-project] About Network-YM.44.mcz

by StÃ©phane Ducasse

But what did you get from the senders of Url>>#toText? Because indeed Url>>#toText will be removed. Ok I will check what you did and wait for your agreement :) Stef On Sep 28, 2008, at 9:09 PM, Yann Monclair wrote: > Hi list, > > I figured I'd explain my commit here, since I don't know how you > handle your issue tracker. > > While I was loading some code in my image (Universes iirc), I got a > lot of warnings pop up, about Url>>#toText being deprecated. > After taking a look at it, I saw that the deprecation comment > recommended using instead Url>>#asText. Which I tried, but it broke > most of the SUnits and also the expected behaviour. > Looking at the code, I saw that Url>>#toText simply did ^self > asString, when Url>>#asText does ^self asString asText. The semantic > leap between Text and String is too big (imo) to force that change > on users. > I thought it would be better to replace the deprecation comment to > recommend replacing the obsolote Url>>#toText by Url>>#asString > (which is what this method actually does). > > I would rather have removed the method, since it has been marked for > obsolete for more than 3 years now! But I don't know what the > approach is to deleting methods, and how to communicate to people > that this isn't a missing method but an intentional removal. > > I hope this helps understand this version. > > Cheers, > > Yann > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

argh I have to check.... sorry Stef On Sep 28, 2008, at 9:26 PM, StÃ©phane Ducasse wrote: > Thanks I will fix that. > This is strange since I tested it on my working Moose image. > > Stef > > On Sep 28, 2008, at 8:43 PM, Norbert Hartl wrote: > >> In 10082 the script is buggy. script174 contains a line >> with only >> >> .mcz >> >> and one line with an archive >> >> Pinesoft-Removals-EToys-stephane.ducasse.1.mcz >> >> that is not in the repository. >> >> 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 >

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

normally this is fixed. I will try to reload it. Stef On Sep 28, 2008, at 8:43 PM, Norbert Hartl wrote: > In 10082 the script is buggy. script174 contains a line > with only > > .mcz > > and one line with an archive > > Pinesoft-Removals-EToys-stephane.ducasse.1.mcz > > that is not in the repository. > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

Thanks I will fix that. This is strange since I tested it on my working Moose image. Stef On Sep 28, 2008, at 8:43 PM, Norbert Hartl wrote: > In 10082 the script is buggy. script174 contains a line > with only > > .mcz > > and one line with an archive > > Pinesoft-Removals-EToys-stephane.ducasse.1.mcz > > that is not in the repository. > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Marcus Denker

On 28.09.2008, at 19:01, Keith Hodges wrote: > >> Now, the code may work perfectly fine, and Keith's done a lot of >> work, but >> it's just not community friendly code. A package should have a clear >> responsibility, few dependencies, not too many extensions, no >> overrides if >> at all possible, and must install and uninstall cleanly without >> hosing my >> system. If it doesn't meet those criteria, I don't consider it >> safe to even >> experiment with. >> >> Ramon Leon >> http://onsmalltalk.com >> > If it uses overrides, the MC1.5 should be able to uninstall it. > However > MC1.5 probably depends upon it. So you are probably stuck there. > keep in mind that unsinstall can not work in gereral... overrides are evil. So just think you installed some packate that has an override. Now you install a second, that overrides again. Ups, broken. So we change the new override to take into account the change done in the first. Now when de-installing the first package, what should happen? > Kernel-Extensions are not supposed to be removed, they are supposed to > be integrated into the main image. We have two ways of doing this. > > We are slowly breaking it down into bug fixes on mantis, considering that mantis now has >1000 open entries... Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 28, 2008

[Pharo-project] About Network-YM.44.mcz

by Yann Monclair

Hi list, I figured I'd explain my commit here, since I don't know how you handle your issue tracker. While I was loading some code in my image (Universes iirc), I got a lot of warnings pop up, about Url>>#toText being deprecated. After taking a look at it, I saw that the deprecation comment recommended using instead Url>>#asText. Which I tried, but it broke most of the SUnits and also the expected behaviour. Looking at the code, I saw that Url>>#toText simply did ^self asString, when Url>>#asText does ^self asString asText. The semantic leap between Text and String is too big (imo) to force that change on users. I thought it would be better to replace the deprecation comment to recommend replacing the obsolote Url>>#toText by Url>>#asString (which is what this method actually does). I would rather have removed the method, since it has been marked for obsolete for more than 3 years now! But I don't know what the approach is to deleting methods, and how to communicate to people that this isn't a missing method but an intentional removal. I hope this helps understand this version. Cheers, Yann

Sept. 28, 2008

[Pharo-project] Update 10082

by Norbert Hartl

In 10082 the script is buggy. script174 contains a line with only .mcz and one line with an archive Pinesoft-Removals-EToys-stephane.ducasse.1.mcz that is not in the repository. Norbert

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> > 100% agree. This is why I'm saying that we want to integrate extensions > or reject them. > >> If it doesn't meet those criteria, I don't consider it safe to even >> experiment with. However, if the base system doesnt support loading and unloading of things in the first place, its a bit unfair to expect a package to be unloadable, when its purpose is to fix the base package so as to be able to support loading and unloading. Once everything we use has LPF (or equivalent) then it is reasonable to expect loading an unloading to work. I admit that Kernel-Extensions has become bloated with more than just the minimum, however it has the advantage of being version controlled which changesets are not. Keith

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Keith Hodges

> Now, the code may work perfectly fine, and Keith's done a lot of work, but > it's just not community friendly code. A package should have a clear > responsibility, few dependencies, not too many extensions, no overrides if > at all possible, and must install and uninstall cleanly without hosing my > system. If it doesn't meet those criteria, I don't consider it safe to even > experiment with. > > Ramon Leon > http://onsmalltalk.com > If it uses overrides, the MC1.5 should be able to uninstall it. However MC1.5 probably depends upon it. So you are probably stuck there. Kernel-Extensions are not supposed to be removed, they are supposed to be integrated into the main image. We have two ways of doing this. We are slowly breaking it down into bug fixes on mantis, however these are changesets and are not removeable either. Keith

Sept. 28, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Keith Hodges

> I agree that Universes is not the ultimate solution, but at least it > seems to work reasonably well. I like the declarative way to > specifying package dependencies. > > Cheers, > Lukas > > Sake/Packages has been changed to be declarative for the most part, though it isn't restricted to that. Keith

Sept. 28, 2008