- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Julian Fitzell

Sure, but the issue is not just figuring out which package to load. We have to either branch the packages or create several different packages which have overlapping code in them. Either way, this becomes increasingly complex from a development point of view (testing, merging, backporting, copying code between packages, and so on). As I said, it may be unavoidable, but I'm not looking forward to it. Julian On Mon, Jun 21, 2010 at 1:16 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Julian, > > I am very close to adding version specific attributes for Pharo1.0 and > Pharo1.1 to make this sort of specialization a little easier, but even now > an individual project can add fine-grained attributes that could allow code > to be conditional on a build by build basis ... if needed. > > Dale > > Julian Fitzell wrote: >> >> Hmm... Why did I only receive this email today...? >> >> Anyway, I agree that those methods should probably be in the >> platform-specific package. I guess we were originally trying to >> minimize the amount of implementation required on each platform. As >> long as no platform implements a method and the implementation is the >> same on all platforms, it is convenient to have it in only one place. >> As soon as a platform chooses to implement it, though, we will simply >> have to move it to the platform-specific package. At this point we run >> into the issue of having different platform packages for, say, Pharo >> 1.1 and 1.2. >> >> Perhaps in the end it is simpler just to keep extensions always in the >> platform packages and insist that the generic packages contain only >> GR* classes and grease* extension methods. >> >> I'm not sure about Grease providing reference implementations of all >> methods it tests, though. I'm not convinced that a "gold standard" >> always exists, nor that it will necessarily be implemented by Grease. >> In many cases, we have standardized on methods that already exist in >> Squeak/Pharo or in some other platform. >> >> On Thu, Jun 17, 2010 at 9:30 AM, Dale Henrichs <dhenrich(a)vmware.com> >> wrote: >>> >>> Julian, >>> >>> The Grease-Core package contains a mixture of things (for convenience): >>> the >>> GR* family of classes using a naming convention that is unlikely to >>> collide >>> with platform classes and a collection of extensions to well-known >>> classes >>> using names that could very easily collide with platform methods (or >>> prevent >>> a platform from implementing that method in their base system). >>> >>> The well-known class extension methods could easily be moved to the >>> platform-side, then as platforms adopt the Grease extensions (an obvious >>> goal of Grease in the first place) the platform extensions can be >>> adjusted >>> accordingly...the Grease-Tests for those methods should remain so that >>> from >>> the Grease-Users perspective the behavior for those methods will remain >>> consistent (relative to Grease) over time... >>> >>> It _would be convenient_ to preserve the current well-known class >>> extension >>> method implementations so that when Grease is ported to a new platform >>> the >>> "standard implementation" can be used as a bootstrap. In fact if the >>> well-known class extension methods were moved into a separate platform >>> package, then you'd have the gold standard implementation and the initial >>> pharo/squeak implementation rolled into one. >>> >>> In the end this doesn't sound that awful... >>> >>> Dale >>> >>> Julian Fitzell wrote: >>>> >>>> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>>>> >>>>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>>>> >>>>> - If included with Pharo I suggest to rename all the methods, >>>>> otherwise we will run into big troubles with Seaside and other >>>>> projects that depend on Grease. >>>>> >>>>> >>>>> From a philosophical standpoint, I *hate* that. this means that as a >>>>> plattform, we can not >>>>> grow and improve our libraris anymore? >>>>> Shouldn't be the goal that useful extensions gets adopted by the core? >>>> >>>> We will need to find a way to allow platforms to adopt Grease methods >>>> - I do think this is the end goal. It's a bit of a nightmare from our >>>> point of view because we end up having to have different Grease >>>> versions for different versions of the platforms, but isn't that sort >>>> of unavoidable in the long run anyway? Part of the reason that's so >>>> awful is simply due to the lack of good branching and management tools >>>> in our version control systems... >>>> >>>> Julian >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 22, 2010

Re: [Pharo-project] CogVM

by Levente Uzonyi

On Mon, 21 Jun 2010, Laval Jannik wrote: > Hi all, > > I just try the new Cog VM, > I have a bug with MessageTally. > > You can reproduce it with: > "MessageTally spyOn:[1]" > > It does not understand "-". > Could someone reproduce it and have an idea to fix it ? It's easy to fix it, just replace code like this: SmalltalkImage current getVMParameters keysAndValuesDo: [ :idx :gcVal | gcStats at: idx put: (gcVal - (gcStats at: idx))]. with this: Smalltalk getVMParameters keysAndValuesDo: [ :idx :gcVal | gcVal ifNotNil: [ gcStats at: idx put: (gcVal - (gcStats at: idx)) ] ]. in MessageTally's #spyAllEvery:on:, #spyEvery:on: and #spyEvery:onProcess:forMilliseconds: (I think these are the same in Pharo and Squeak. If not, then just look at the senders of #getVMParameters). Levente > > Cheers, > Jannik > > On Jun 21, 2010, at 18:04 , Serge Stinckwich wrote: > >> On Mon, Jun 21, 2010 at 10:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Some people asked me how I got Pharo to run on Cog on OS X. Here's how: >>> >>> 1. Download the Cog source-code from >>> <http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz>, open the Xcode >>> project CoreVM.xcodeproj, and compile the thing. For those who want to >>> skip this step I've put the resulting binaries here: >>> <http://www.lukas-renggli.ch/dropbox/cog-osx.zip>. >>> >>> 2. Open a (copy of a) Pharo image in an **old** VM and file-in the >>> appropriate change-set (there is one for Pharo 1.0 and one for Pharo >>> 1.1) from the following issue report: >>> <http://code.google.com/p/pharo/issues/detail?id=2579>. Save the image >>> and quit. >>> >>> 3. Open the image in the Cog VM. Note that if you safe the image, you >>> won't be able to open it again in a non-Cog VM. >>> >>> Hopefully John will provide a properly built binary soon :-) >> >> Thank you Lukas ! >> >> Quite impressive in some of my highly CPU-intensive robot simulations !!! >> Strange that the VM Cog icon is Croquet ;-) >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > --- > Jannik Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 21, 2010

Re: [Pharo-project] the pharosearch looks nice!

by Alexandre Bergel

Really cool! Alexandre On 21 Jun 2010, at 10:48, Mariano Martinez Peck wrote: > http://www.google.com/cse/home?cx=002648833966092822604:lxyrxyhpyv8&ie=UTF-8 > > http://magaloma.seasidehosting.st/ > > This is cool Nico, Thanks :) > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 21, 2010

Re: [Pharo-project] [update 1.2] #12011

by laurent laffont

On Mon, Jun 21, 2010 at 10:55 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > 12011 > ----- > > - Issue 2555: WideString asByteString does not return a ByteString. > Thanks Henrik! > - Issue 2580: COG primitive:error: pragma does not work. Thanks > Eliot/Henrik > - Issue 2581: COG Float access methods > - Issue 2579: Necessary Image Changes For Cog To Work > Cool :) Laurent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 21, 2010

[Pharo-project] [update 1.2] #12011

by StÃ©phane Ducasse

12011 ----- - Issue 2555: WideString asByteString does not return a ByteString. Thanks Henrik! - Issue 2580: COG primitive:error: pragma does not work. Thanks Eliot/Henrik - Issue 2581: COG Float access methods - Issue 2579: Necessary Image Changes For Cog To Work

June 21, 2010

Re: [Pharo-project] CogVM

by Nicolas Cellier

Not sure. You may have to replay some VMMaker changes newer than Eliot base... See Levente recent message http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-June/151471.html Nicolas 2010/6/21 Laval Jannik <jannik.laval(a)gmail.com>: > Hi all, > > I just try the new Cog VM, > I have a bug with MessageTally. > > You can reproduce it with: > "MessageTally spyOn:[1]" > > It does not understand "-". > Could someone reproduce it and have an idea to fix it ? > > Cheers, > Jannik > > On Jun 21, 2010, at 18:04 , Serge Stinckwich wrote: > >> On Mon, Jun 21, 2010 at 10:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Some people asked me how I got Pharo to run on Cog on OS X. Here's how: >>> >>> 1. Download the Cog source-code from >>> <http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz>, open the Xcode >>> project CoreVM.xcodeproj, and compile the thing. For those who want to >>> skip this step I've put the resulting binaries here: >>> <http://www.lukas-renggli.ch/dropbox/cog-osx.zip>. >>> >>> 2. Open a (copy of a) Pharo image in an **old** VM and file-in the >>> appropriate change-set (there is one for Pharo 1.0 and one for Pharo >>> 1.1) from the following issue report: >>> <http://code.google.com/p/pharo/issues/detail?id=2579>. Save the image >>> and quit. >>> >>> 3. Open the image in the Cog VM. Note that if you safe the image, you >>> won't be able to open it again in a non-Cog VM. >>> >>> Hopefully John will provide a properly built binary soon :-) >> >> Thank you Lukas ! >> >> Quite impressive in some of my highly CPU-intensive robot simulations !!! >> Strange that the VM Cog icon is Croquet ;-) >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > --- > Jannik Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 21, 2010

Re: [Pharo-project] CogVM

by Laval Jannik

Hi all, I just try the new Cog VM, I have a bug with MessageTally. You can reproduce it with: "MessageTally spyOn:[1]" It does not understand "-". Could someone reproduce it and have an idea to fix it ? Cheers, Jannik On Jun 21, 2010, at 18:04 , Serge Stinckwich wrote: > On Mon, Jun 21, 2010 at 10:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> Some people asked me how I got Pharo to run on Cog on OS X. Here's how: >> >> 1. Download the Cog source-code from >> <http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz>, open the Xcode >> project CoreVM.xcodeproj, and compile the thing. For those who want to >> skip this step I've put the resulting binaries here: >> <http://www.lukas-renggli.ch/dropbox/cog-osx.zip>. >> >> 2. Open a (copy of a) Pharo image in an **old** VM and file-in the >> appropriate change-set (there is one for Pharo 1.0 and one for Pharo >> 1.1) from the following issue report: >> <http://code.google.com/p/pharo/issues/detail?id=2579>. Save the image >> and quit. >> >> 3. Open the image in the Cog VM. Note that if you safe the image, you >> won't be able to open it again in a non-Cog VM. >> >> Hopefully John will provide a properly built binary soon :-) > > Thank you Lukas ! > > Quite impressive in some of my highly CPU-intensive robot simulations !!! > Strange that the VM Cog icon is Croquet ;-) > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project --- Jannik Laval

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Michael Roberts

Ok so there are a number of separate concerns. I was looking at grease core but the thread suggests the methods should be in the platform part so that is a non issue. If they are in the platform part then in this case they are intended to be adopted anyway. Fine Regarding "improving the core" I assume you mean the core image. The core image from a build point of view is just a bunch of well known versioned packages. If another group is already maintaining a mc package of code that is really nice to put into the core then the only Point I was trying to make was to include it directly as a versioned unit rather than copy and branch it. Of course if the code is not packaged then it can go into the pharo repo naturally. The argument wasn't at all about not including code. And the cost was not about adding methods. It was about the mechanics of the build and maintenance. In this case grease is special because of its philosophy but what I'm trying to say would apply to any package that is well maintained externally. Cheers Mike On 21 Jun 2010, at 20:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The idea of marcus is that this is important to improve the core > even at the expense of adding > some methods. This is why we added the regex and in fact we could > rewrite a lot of part. > Now this is not that simple. > Stef > > >>> but do we want all grease? >>> >> >> Well. Not sure. Grease core is not that big. It has other useful >> stuff in. I was in part commenting on the philosophy markus was >> referring to. I have a different point of view. If we just copy >> the extensions we have to maintain our own branch. And we can not >> use any extensions that reference grease classes. Then what happens >> if we really want an extension like that? We copy classes too?that >> would not make a lot of sense to me. >> >> So what do you think? >> mike >> >> >>> Stef >>> >>> On Jun 17, 2010, at 6:42 PM, Michael Roberts wrote: >>> >>>> I'm missing something. Why do we need to adopt the (copy of) >>>> methods and not just adopt the package as lukas said? I thought >>>> we wanted core to get smaller over time and better modularised >>>> anyway? We would just need to track a stable version rather than >>>> maintaining our own branch. Surely it is worse to copy the >>>> methods renamed or not but put them in a pharo specific package? >>>> >>>> >>>> Cheers mike >>>> >>>> On 17 Jun 2010, at 14:14, Julian Fitzell <jfitzell(a)gmail.com> >>>> wrote: >>>> >>>>> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>>>>> >>>>>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>>>>> >>>>>> - If included with Pharo I suggest to rename all the methods, >>>>>> otherwise we will run into big troubles with Seaside and other >>>>>> projects that depend on Grease. >>>>>> >>>>>> >>>>>> From a philosophical standpoint, I *hate* that. this means that >>>>>> as a >>>>>> plattform, we can not >>>>>> grow and improve our libraris anymore? >>>>>> Shouldn't be the goal that useful extensions gets adopted by >>>>>> the core? >>>>> >>>>> We will need to find a way to allow platforms to adopt Grease >>>>> methods >>>>> - I do think this is the end goal. It's a bit of a nightmare >>>>> from our >>>>> point of view because we end up having to have different Grease >>>>> versions for different versions of the platforms, but isn't that >>>>> sort >>>>> of unavoidable in the long run anyway? Part of the reason that's >>>>> so >>>>> awful is simply due to the lack of good branching and management >>>>> tools >>>>> in our version control systems... >>>>> >>>>> Julian >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Dale Henrichs

Julian, I am very close to adding version specific attributes for Pharo1.0 and Pharo1.1 to make this sort of specialization a little easier, but even now an individual project can add fine-grained attributes that could allow code to be conditional on a build by build basis ... if needed. Dale Julian Fitzell wrote: > Hmm... Why did I only receive this email today...? > > Anyway, I agree that those methods should probably be in the > platform-specific package. I guess we were originally trying to > minimize the amount of implementation required on each platform. As > long as no platform implements a method and the implementation is the > same on all platforms, it is convenient to have it in only one place. > As soon as a platform chooses to implement it, though, we will simply > have to move it to the platform-specific package. At this point we run > into the issue of having different platform packages for, say, Pharo > 1.1 and 1.2. > > Perhaps in the end it is simpler just to keep extensions always in the > platform packages and insist that the generic packages contain only > GR* classes and grease* extension methods. > > I'm not sure about Grease providing reference implementations of all > methods it tests, though. I'm not convinced that a "gold standard" > always exists, nor that it will necessarily be implemented by Grease. > In many cases, we have standardized on methods that already exist in > Squeak/Pharo or in some other platform. > > On Thu, Jun 17, 2010 at 9:30 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Julian, >> >> The Grease-Core package contains a mixture of things (for convenience): the >> GR* family of classes using a naming convention that is unlikely to collide >> with platform classes and a collection of extensions to well-known classes >> using names that could very easily collide with platform methods (or prevent >> a platform from implementing that method in their base system). >> >> The well-known class extension methods could easily be moved to the >> platform-side, then as platforms adopt the Grease extensions (an obvious >> goal of Grease in the first place) the platform extensions can be adjusted >> accordingly...the Grease-Tests for those methods should remain so that from >> the Grease-Users perspective the behavior for those methods will remain >> consistent (relative to Grease) over time... >> >> It _would be convenient_ to preserve the current well-known class extension >> method implementations so that when Grease is ported to a new platform the >> "standard implementation" can be used as a bootstrap. In fact if the >> well-known class extension methods were moved into a separate platform >> package, then you'd have the gold standard implementation and the initial >> pharo/squeak implementation rolled into one. >> >> In the end this doesn't sound that awful... >> >> Dale >> >> Julian Fitzell wrote: >>> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>>> >>>> - If included with Pharo I suggest to rename all the methods, >>>> otherwise we will run into big troubles with Seaside and other >>>> projects that depend on Grease. >>>> >>>> >>>> From a philosophical standpoint, I *hate* that. this means that as a >>>> plattform, we can not >>>> grow and improve our libraris anymore? >>>> Shouldn't be the goal that useful extensions gets adopted by the core? >>> We will need to find a way to allow platforms to adopt Grease methods >>> - I do think this is the end goal. It's a bit of a nightmare from our >>> point of view because we end up having to have different Grease >>> versions for different versions of the platforms, but isn't that sort >>> of unavoidable in the long run anyway? Part of the reason that's so >>> awful is simply due to the lack of good branching and management tools >>> in our version control systems... >>> >>> Julian >>> >>> _______________________________________________ >>> 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

June 21, 2010

Re: [Pharo-project] Issue 2290: window placement strategy

by Laval Jannik

Hi Mariano, Thank you for your remarks On Jun 21, 2010, at 15:23 , Mariano Martinez Peck wrote: > Hi Jannik. I have just test them and I really like them. Regardless the particular strategy, using a strategy, and thus being able to easily swich and extend, is just great. > > Now, a couple of observations: > > - It is not completely clear for me what it is each option. What is standard? if tomorrow the standard change? I would try to avoid such names and put something better. Random ? I don't know. > What is reverse stragger ?? You're right, I use the name already existing in Squeak/Pharo. We should change them. Reverse Stragger is the one used in Squeak/Pharo: random, which is not a random but a placement where it is the better (hummmm, not sure it works fine). Standard is a placement where the screen is divided in four space (top left, top right, bottom left, bottom right) and window are placed in each of these spaces. > > - I think it should be also documented if possible in the settings browser, what does each option mean. Yes, I will do this, or someone with a better english :))) > > - I think that for 1.2 we are quite free to change and do what we want. So, we can change the default. I think cascade is the better. What I really think is that we need something deterministic. Fixed. Not random. Not surprise. Maybe not all of you agree. I would like to hear other opinions. Again, you're right. I make the cascade setting because the other are not easy to use when I use my big screen. Reverse Stragger is cool on a 15 inches, but on a larger screen it is really difficult. I leave it to Reverse Stragger to not change the habit. Now, I think Cascade is better. Other opinions ? Cheers, Jannik > > Cheers > > Mariano > > On Sat, Jun 12, 2010 at 9:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks jannik I will have a look > > On Jun 12, 2010, at 9:27 PM, Laval Jannik wrote: > > > Hi all, > > > > I made a setting for placement strategy. > > By default, it is reversed stragger (which is the one by default since Pharo exists). > > And I create one I have named "Cascade", which place the new window above the current active window, or if there is no active window, the window is placed at the cursor position. > > > > The change is available in SLICE-Issue-2290-windowsStrategy. > > The setting is available in the SettingBrowser in Appearance>Morphic>Windows>Window position strategy. > > > > Now, it is possible to create new strategy positions by creating a new strategy in RealEstateAgent (category strategy - there is also three strategies), and by modifying the method RealEstateAgent >>usedStrategySettingsOn: to add an entry in the menu. > > > > I hope that this change will be integrated in 1.2. > > > > Cheers, > > --- > > Jannik Laval > > > > > > _______________________________________________ > > 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 --- Jannik Laval

June 21, 2010