- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] MIMEdatabase fix?

by Damien Cassou

On Fri, Feb 27, 2009 at 12:02 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > 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. Pharo will probably have its own copy of Universe. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Keith Hodges

> Second the fix is not that ugly. It just sends #asString to something it > expects to be a String. This is not a that uncommon idiom. And we > already have to do something way uglier for ensuring author initials. > How about taking the Author initials stuff from pharo, and publishing it as a package that will load into squeak. Then coding seaside to the new api. This is something I plan to do for squeak anyway at some point, but if you have a need for it now. Also if you have any pressing fixes that squeak needs we can put that fix into lpf for all images 3.7+ Keith

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Lukas Renggli

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. 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 suggest that people stick with Squeak 3.9.1 or early versions of Pharo for now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 27, 2009

Re: [Pharo-project] method missing installing Seaside

by Lukas Renggli

That's a known problem, see "[Pharo-project] MIMEdatabase fix?". As a workaround use an old Pharo image from around December. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 27, 2009

[Pharo-project] method missing installing Seaside

by Esteban Lorenzano

Hi, I downloaded latest pharo-dev from the downloads page, and executed this: Installer universe install: 'Seaside'. But it fails, I'm getting a DNU on MIMEDocument>>resetMIMEdatabase... :( Cheers, Esteban

Feb. 27, 2009

Re: [Pharo-project] Announcements for Pharo?

by Igor Stasenko

2009/2/26 Norbert Hartl <norbert(a)hartl.name>: > On Thu, 2009-02-26 at 07:45 -0800, Michael Rueger wrote: >> Keith Hodges wrote: >> >> >> Â Â We will include it. >> >> >> >> >> >> Thanks, we will try with Pharo then. >> >> Lautaro FernÃ¡ndez >> > I am confused. Surely you would expect a loadable package to remain >> > loadable and only be called up if needed? >> >> Although I'm normally the first to argue against including more stuff >> into the core image I think Announcements need to be part of core. >> This will allow us to have *one* mechanism for signaling/subscribing and >> can over time replace the different variants that are now used and >> provide a solid base for anyone needing such a mechanism. >> In the experimental forks I have worked on having Announcements >> available made all the difference. >> > Does that mean that the EventManager, package System-Object Events and > the methods in Object will be replaced by that? If yes I'm all for it! > I will examine it more closely. > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Feb. 27, 2009