- Pharo-dev - lists.pharo.org

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

by Damien Cassou

On Sun, Sep 28, 2008 at 9:44 PM, Yann Monclair <yann.monclair(a)smalltalk.fr> wrote: > I found a few senders in Universe, but I couldn't publish the changes, the > project is ReadOnly and I haven't time to chase up the admins about it yet. Philippe and I fixed them. Thanks -- 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)

Sept. 29, 2008

RE: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside2.9 alphauniverse

by Ramon Leon

> > 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 uninstall can not work in general... > overrides are evil. My feelings exactly. I don't want an MC that tries to be smart, I want packages who's authors recognize that overrides are pure evil and don't use overrides. If the built in method doesn't work for you, then create an extension that does with a prefix that suites your package. It might not be pretty, but it's better that changing core code and breaking other peoples packages. Ramon Leon http://onsmalltalk.com

Sept. 29, 2008

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

by Keith Hodges

Marcus Denker wrote: > > On 28.09.2008, at 22:16, Keith Hodges wrote: > >> >>> considering that mantis now has >1000 open entries... >>> >>> Marcus >>> >> ?? >> >> The difference being, that we dont create a mantis entry so that it can >> languish unused. We use mantis as a vessel for holding snippets of code >> and collecting feedback. >> >> Installer collects a list of fixes applied, and Sake/Tasks has a task >> for documenting those fixes in the image. >> > > So fixes are not integrated into the image anymore and the report then > closed? When a release image is released the fixes are integrated into the image as normal, and can be closed or marked "fixed". Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something. Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer. This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team. > What I don't understand with the use of Installer with mantis entries: > From my > experience from 3.6 to 3.9, there is quite some dependency between fixes. Nothing is automatic, if you or some script loads the wrong fix in the wrong order then that is a problem. > Thas means: two fixes are overriding the same method, to harvest both, > the second > one applied can not be added but needs to be redone to take the > changes of the first > into account. > > I really can't imagine how you can automatically apply changesets from > the bugtracker Nothing is automatic. > > to build "your own release". This just can't work with all the > dependencies between > fixes. However, the old way, fixes are applied to a moving target, since the alpha image is continuously being updated. With this approach fixes applied to 3.10 (a fixed target) are used to create a 3.11 unstable until the combination of fixes is deemed "stable" Keith

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by Norbert Hartl

On Sun, 2008-09-28 at 21:41 +0200, StÃ©phane Ducasse wrote: > Now it is working for me. > For me, too. Thanks! Norbert

Sept. 28, 2008

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

by Marcus Denker

On 28.09.2008, at 22:16, Keith Hodges wrote: > >> considering that mantis now has >1000 open entries... >> >> Marcus >> > ?? > > The difference being, that we dont create a mantis entry so that it > can > languish unused. We use mantis as a vessel for holding snippets of > code > and collecting feedback. > > Installer collects a list of fixes applied, and Sake/Tasks has a task > for documenting those fixes in the image. > So fixes are not integrated into the image anymore and the report then closed? What I don't understand with the use of Installer with mantis entries: From my experience from 3.6 to 3.9, there is quite some dependency between fixes. Thas means: two fixes are overriding the same method, to harvest both, the second one applied can not be added but needs to be redone to take the changes of the first into account. I really can't imagine how you can automatically apply changesets from the bugtracker to build "your own release". This just can't work with all the dependencies between fixes. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 28, 2008

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

by Keith Hodges

> considering that mantis now has >1000 open entries... > > Marcus > ?? The difference being, that we dont create a mantis entry so that it can languish unused. We use mantis as a vessel for holding snippets of code and collecting feedback. Installer collects a list of fixes applied, and Sake/Tasks has a task for documenting those fixes in the image. Keith

Sept. 28, 2008

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

by StÃ©phane Ducasse

thanks. Stef On Sep 28, 2008, at 9:44 PM, Yann Monclair wrote: > I replaced the only sender I found in the base Pharo image > (HttpUrl>>#askNamePassword). > > I found a few senders in Universe, but I couldn't publish the > changes, the project is ReadOnly and I haven't time to chase up the > admins about it yet. > > I'll send my agreement next week. > > Cheers, > > Yann > > On Sun, Sep 28, 2008 at 8:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > 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 > > > _______________________________________________ > 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] About Network-YM.44.mcz

by Yann Monclair

I replaced the only sender I found in the base Pharo image (HttpUrl>>#askNamePassword). I found a few senders in Universe, but I couldn't publish the changes, the project is ReadOnly and I haven't time to chase up the admins about it yet. I'll send my agreement next week. Cheers, Yann On Sun, Sep 28, 2008 at 8:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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 >> > > > _______________________________________________ > 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] How do we manage todos?

by Tudor Girba

You can always use the built in Enhancement tag. Cheers, Doru On Sep 28, 2008, at 9:40 PM, StÃ©phane Ducasse wrote: > I would prefer a bugtraker with a tag todo that are not bug fixes. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com www.tudorgirba.com/blog "Problem solving efficiency grows with the abstractness level of problem understanding."

Sept. 28, 2008

Re: [Pharo-project] Update 10082

by StÃ©phane Ducasse

Now it is working for me. Stef

Sept. 28, 2008