February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

>>> > With my changes to Pharo (which of course first need to be > integrated), I will integrate them this evening. > > the changed (not forked!) version of Kom and the few changes for > Seaside > (which need to be integrated) there is no need for a fork!!! > > Those versions should work on both Squeak and Pharo. > > It's not monkey patching, none of the packages touch other stuff any > more than they did before. I just changed Kom so its monkey patching > now > works on both Seaside and Pharo. > > And that's where I need you help testing. > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

So you even got a solution :) Excellent! But this is also a good point because it means that for the future we will have again this kind of discussion.....exciting. Stef On Feb 27, 2009, at 6:06 PM, Michael Rueger wrote: > Philippe Marschall wrote: >> StÃ©phane Ducasse wrote: >>> I have problems to understand why this would be not reasonable that >>> people load a give kom version for seaside on squeak >>> and one for seaside on pharo. >> >> Loading is one thing. What bothers we more is the maintenance >> situation. >> Let's face it, there are far too resources behind something as >> important >> as Kom. Making a fork of it cuts these resources in half. > > Hmm, I think most of the discussion is simply a misunderstanding, I'm > not forking anything. > > With my changes to Pharo (which of course first need to be > integrated), > the changed (not forked!) version of Kom and the few changes for > Seaside > (which need to be integrated) there is no need for a fork!!! > > Those versions should work on both Squeak and Pharo. > > It's not monkey patching, none of the packages touch other stuff any > more than they did before. I just changed Kom so its monkey patching > now > works on both Seaside and Pharo. > > And that's where I need you help testing. > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

you know I guess that I know what is maintenance. >> I have problems to understand why this would be not reasonable that >> people load a give kom version for seaside on squeak >> and one for seaside on pharo. > > Loading is one thing. What bothers we more is the maintenance > situation. > Let's face it, there are far too resources behind something as > important > as Kom. Making a fork of it cuts these resources in half. > > Maintenance is not doing a quick fix now so that it loads. Maintenance > is taking care of something for several years (!) to come, fixing > issues > as they arrive, being there and responding. Removing time from other > activities instead of finding excuses. So what is your suggestion then because so far the only message we got is that we should not change network because KOM is crappy. So ****concretely**** what can we do. So far you have not been that constructive. If we do not have paths for the future then why Seasiders even think about using Pharo. May be you should get stuck in Squeak and this is ok too. Stef

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Michael Rueger

Philippe Marschall wrote: > StÃ©phane Ducasse wrote: >> I have problems to understand why this would be not reasonable that >> people load a give kom version for seaside on squeak >> and one for seaside on pharo. > > Loading is one thing. What bothers we more is the maintenance situation. > Let's face it, there are far too resources behind something as important > as Kom. Making a fork of it cuts these resources in half. Hmm, I think most of the discussion is simply a misunderstanding, I'm not forking anything. With my changes to Pharo (which of course first need to be integrated), the changed (not forked!) version of Kom and the few changes for Seaside (which need to be integrated) there is no need for a fork!!! Those versions should work on both Squeak and Pharo. It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo. And that's where I need you help testing. Michael

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Philippe Marschall

StÃ©phane Ducasse wrote: > On Feb 25, 2009, at 5:59 PM, Michael Rueger wrote: > >> Lukas Renggli wrote: >>>> what seasiders think? >>>> I would be in favor to get a KOM pharo version >>> Having two incompatible versions of Kom makes distribution even more >>> painful as it is today. I would prefer to have compatible versions if >>> this is possible. >> As I said, we are at or at least close to the point where we have to >> make the decision which version to support. If you want to have Pharo >> stay compatible with Squeak, we can just as well abandon Pharo now. >> It's as simple as that. > > No else we would not have done pharo. > The point is more how can we help people migrating to pharo. > Probably having a specific Kom version. You help people if you have a maintained version of Kom (see other mail). If you don't have a maintained web server then you are hurting people. Simply making a fork of Kom is not maintenance, on the contrary. Philippe

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Philippe Marschall

StÃ©phane Ducasse wrote: > I have problems to understand why this would be not reasonable that > people load a give kom version for seaside on squeak > and one for seaside on pharo. Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half. Maintenance is not doing a quick fix now so that it loads. Maintenance is taking care of something for several years (!) to come, fixing issues as they arrive, being there and responding. Removing time from other activities instead of finding excuses. Cheers Philippe

Feb. 27, 2009

[Pharo-project] ENH thisContext arguments

by StÃ©phane Ducasse

May be this can be useful to have that defined in ContextPart arguments "returns the arguments of a message invocation" | arguments numargs | numargs := self method numArgs. arguments := Array new: numargs. 1 to: numargs do: [:i | arguments at: i put: (self tempAt: i) ]. ^ arguments Let me know I can prepare a enh entry in the bug tracker. stef

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

On Feb 27, 2009, at 12:02 PM, Lukas Renggli wrote: > On Fri, Feb 27, 2009 at 10:30 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I have problems to understand why this would be not reasonable that >> people load a give kom version for seaside on squeak >> and one for seaside on pharo. > > The problem is that people load released versions from SqueakMap or > Package Universe. As long as Pharo shares the Squeak Package Universe > there is no way of cleanly deciding which version of Kom to load. ok now we can say that we have one Universe for Pharo so does it help solving the problem? > In the long term (for upcoming version) we will have to decide what > platform to support. I guess this will be Pharo 1.0 as soon as it has > been released. It is too much trouble to keep the installers > up-to-date and try to test and make them work on different versions > and platforms. I imagine that pretty well. > I suggest that people stick with Squeak 3.9.1 or early > versions of Pharo for now. So may be we should tagged one version for alpha-pharo seasider and we take the decision that there will be a KOM for pharo and one for Squeak. Now I can integrate the changes of mike but I need a seaside creating the Pharo-KOM and testing that everything is ok. > > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2009

Re: [Pharo-project] Issue #112: Enhanced colors

by StÃ©phane Ducasse

> http://code.google.com/p/pharo/issues/detail?id=112 > > Who thinks that we should add these colors? These are more than 100 > additional named colors like #paleGoldenrod, #mediumOrchid, #thistle, > etc. > > I'd vote against adding them since I don't see their merit. > > Other opinions? we could keep them as a package. Having colors is useful for us > > > Cheers, > Adrian > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2009

[Pharo-project] Issue #112: Enhanced colors

by Adrian Lienhard

http://code.google.com/p/pharo/issues/detail?id=112 Who thinks that we should add these colors? These are more than 100 additional named colors like #paleGoldenrod, #mediumOrchid, #thistle, etc. I'd vote against adding them since I don't see their merit. Other opinions? Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

Feb. 27, 2009