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

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

[Pharo-project] How do we manage todos?

by StÃ©phane Ducasse

I would prefer a bugtraker with a tag todo that are not bug fixes. Stef

Sept. 28, 2008

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

by StÃ©phane Ducasse

I sent an email a while back on checkeing Kernel Extensions. I know added an entries in the bgtracker. Stef On Sep 28, 2008, at 7:01 PM, 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. > > 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 > > _______________________________________________ > 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 alpha universe

by StÃ©phane Ducasse

On Sep 28, 2008, at 6:50 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Hi Damien >> >> I can give you an explanation but keith will not like it. >> Note that I like the ideas that he is pushing and that I started to >> write a chapter for the next book on installer. >> - Keith idea that everybody can build its own distribution is not >> something that everybody like > It is what the community has been talking about and doing for the past > few years. I started by providing a Seaside-Magma-Pier image, now > instead I can provide a Seaside-Magma-Pier entry in Sake/Packages > which > will work in any image that the squeak community typically uses. > > There are people now building one-click Pier images, and one click > Seaside images, but this is going back to doing it the old way, and it > will not be generally useful, since every major project builds their > own > image. For example Gjallar, Sophie, WebStore (my Project) etc. >> - For example I would like to have a real look at MC1.6 but the >> message around it is blurry > I am sure that Matthew will be able to make the message clearer, in > the > meantime please do not overlook the months of work that have gone into > MC1.5. I will look do not worry. :) I'm just slow > >> I tried LFP and it broke on me. > That was simply the wiki complaining that it was being hit too hard. > LPF > has been working for many people for months, you just got unlucky. It > may be fixed. >> - I like installer but when I look at the code I would like to >> refactor it. > Of course, Installer is designed with that future refactoring in mind. > Keeping everything in one class was an initial design goal for the > purpose of "looking slim" and gaining acceptance. Now that Installer > has > gained some acceptance it may be time to tidy up the code. I still > like > the one class feature, but at some point the maintainability will > suffer > too much. Ok I could do a pass on that then. > >> - There is no document in a nice format that explain why and how >> (i'm fixing that for installer > Installer has a class comment and this is available on the squeak > wiki, > and http://installer.pbwiki.com/Installer what more do you want? >> and I was waiting because I will refactor it else I do not publish >> the chapter but I did not want to >> insult keith since this is not the point since I like installer). >> - unknown is strnage :) >> - So if you want to help me I would love to have a >> - Installer code refactored >> - Installer chapter >> - Sake (have a look at the code) >> - Sake Chapter for the book > Sounds good to me! > > Keith > > _______________________________________________ > 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