January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] PharoLauncher as the default Pharo download on pharo.org?

by Sebastian Sastre

On Jan 27, 2014, at 3:00 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> maybe the launcher can be location agnostic and remember somewhere the >> locations of the lasts images that where opened with it and simply offer >> links to open the ones at the lasts, say 7 images, paths. You will even >> evade coupling that to the OS > > > where do you store the images that the launcher creates? Iâm not currently using launcher but if Iâd use it, I want my images pretty much as I already described. Because I move stuff from OS X in development to linux in production Iâd hate things coupled to hidden magic places because it will force me to either search for them every time or complicate git repos (injected resistance) or not use the launcher at all (removing that resistance and the alleged convenience it would fail to provide). Therefore, my suggestion is to keep it location agnostic sebastian o/

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Tudor Girba

Thank you! I can review it tomorrow morning. Doru On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > hhahah, ok, I'm on it > > > On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Yes, please! >> >> Doru >> >> >> On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >> >>> yes, please :) >>> >>> On 28 Jan 2014, at 13:47, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> >>>> So, what to do? >>>> - Don't send ClassModifiedClassDefinition in >>>> SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? >>>> - Implement Trait>>layout ? >>>> - Test for oldClassDefinition isTrait in >>>> ClassModifiedClassDefinition>>isPropagating ? >>>> >>>> >>>> >>> I discussed with Camille and we think it's better this other >>> alternative: to fix class builder to only announce >>> ClassModifiedClassDefinition for the class that really changed its >>> definition. For the subclasses, it won't be announced. This way, it's not >>> necessary to check if it is a propagation. We can remove the two >>> implementors and the unique sender. >>> >>> I verified that this was the behavior of "old class builder" (in Pharo >>> 2). Do you agree? >>> >>> I can submit a slice this afternoon. >>> >>> MartÃn >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Martin Dias

hhahah, ok, I'm on it On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes, please! > > Doru > > > On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> yes, please :) >> >> On 28 Jan 2014, at 13:47, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> >>> So, what to do? >>> - Don't send ClassModifiedClassDefinition in >>> SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? >>> - Implement Trait>>layout ? >>> - Test for oldClassDefinition isTrait in >>> ClassModifiedClassDefinition>>isPropagating ? >>> >>> >>> >> I discussed with Camille and we think it's better this other alternative: >> to fix class builder to only announce ClassModifiedClassDefinition for the >> class that really changed its definition. For the subclasses, it won't be >> announced. This way, it's not necessary to check if it is a propagation. We >> can remove the two implementors and the unique sender. >> >> I verified that this was the behavior of "old class builder" (in Pharo >> 2). Do you agree? >> >> I can submit a slice this afternoon. >> >> MartÃn >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Tudor Girba

Yes, please! Doru On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yes, please :) > > On 28 Jan 2014, at 13:47, Martin Dias <tinchodias(a)gmail.com> wrote: > > >> So, what to do? >> - Don't send ClassModifiedClassDefinition in >> SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? >> - Implement Trait>>layout ? >> - Test for oldClassDefinition isTrait in >> ClassModifiedClassDefinition>>isPropagating ? >> >> >> > I discussed with Camille and we think it's better this other alternative: > to fix class builder to only announce ClassModifiedClassDefinition for the > class that really changed its definition. For the subclasses, it won't be > announced. This way, it's not necessary to check if it is a propagation. We > can remove the two implementors and the unique sender. > > I verified that this was the behavior of "old class builder" (in Pharo 2). > Do you agree? > > I can submit a slice this afternoon. > > MartÃn > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Esteban Lorenzano

yes, please :) On 28 Jan 2014, at 13:47, Martin Dias <tinchodias(a)gmail.com> wrote: > > So, what to do? > - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? > - Implement Trait>>layout ? > - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ? > > > > I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender. > > I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree? > > I can submit a slice this afternoon. > > MartÃn

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Martin Dias

> > > So, what to do? > - Don't send ClassModifiedClassDefinition in > SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? > - Implement Trait>>layout ? > - Test for oldClassDefinition isTrait in > ClassModifiedClassDefinition>>isPropagating ? > > > I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender. I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree? I can submit a slice this afternoon. MartÃn

Jan. 28, 2014

Re: [Pharo-dev] PharoLauncher as the default Pharo download on pharo.org?

by Yuriy Tymchuk

Now, everyone can make his own luncher, right? ;) Uko On 28 Jan 2014, at 12:32, Stephan Eggermont <stephan(a)stack.nl> wrote: > Bestlem wrote >> I think this is a misreading of Apple's directory design. It is for more >> than preferences and caches but for all app-specific files > > No, it is not. Library is meant for shared libraries, like vm plugins, > and preferences and caches. Nothing more. > > Apple is changing this with the app sandbox model, > but we have no way to adopt that now. The effort needed > to do that well is not available, nor should it be a > priority. The centralized code signing model apple suggests is > fundamentally evil and designed to take away your freedoms. > >> For example Amazon's Kindle app puts the ebooks in ~/Library/Application >> Support/Kindle and these seem to me similar to Pharo images > > They have an explicit goal of making it impossible to manipulate > ebooks outside the kindle application. That makes them evil, > and the solution to avoid, if possible. > > Damien Cassou wrote: >> I changed the default directories on all systems: >> >> - mac: ~/Library/Application Support/Pharo/images >> - win: %APPDATA%\Pharo\images >> - unix: ~/.local/share/Pharo/images > > Please donât. > > Stephan

Jan. 28, 2014

A doodle for finding good sprint dates for Lille

by Marcus Denker

We need to find good dates for Friday Sprints... the idea is that we will try do small ones every Friday, and once a month a larger one. (In addtion, we need to check to do hangouts againâ¦) I make this public so that if someone wants to come to lille, add the time you could make it.. we then will take a date for the big sprint where most people can join. http://doodle.com/ka3rk9w3rxpxa7fu

Jan. 28, 2014

Re: [Pharo-dev] PharoLauncher as the default Pharo download on pharo.org?

by Stephan Eggermont

Bestlem wrote >I think this is a misreading of Apple's directory design. It is for more >than preferences and caches but for all app-specific files No, it is not. Library is meant for shared libraries, like vm plugins, and preferences and caches. Nothing more. Apple is changing this with the app sandbox model, but we have no way to adopt that now. The effort needed to do that well is not available, nor should it be a priority. The centralized code signing model apple suggests is fundamentally evil and designed to take away your freedoms. >For example Amazon's Kindle app puts the ebooks in ~/Library/Application >Support/Kindle and these seem to me similar to Pharo images They have an explicit goal of making it impossible to manipulate ebooks outside the kindle application. That makes them evil, and the solution to avoid, if possible. Damien Cassou wrote: >I changed the default directories on all systems: > >- mac: ~/Library/Application Support/Pharo/images >- win: %APPDATA%\Pharo\images >- unix: ~/.local/share/Pharo/images Please donât. Stephan

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Nicolai Hess

2014-01-27 Martin Dias <tinchodias(a)gmail.com> > > > > On Mon, Jan 27, 2014 at 7:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I opened an issue: >> https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU >> >> I marked it as a show stopper because right now you cannot load a package >> with Traits in the image. >> >> I am not sure about triggering the event for subclasses, but I can >> certainly understand that it can be useful for tools. However, the problem >> is that we are trying to figure out isPropagation after we trigger it, >> instead of doing it while triggering for a subclass. So, one possibility >> would be to distinguish between ClassModified and SuperclassModified. I >> tried to search in the code quickly but could not locate the exact place. I >> will try again later if nobody beats me to it. >> > > +1 > I think not much people is interested in SuperclassModified. ClassModified > is the more interesting one. It requires, for example, the browser to be > refreshed, the package to be marked as dirty, or the change to be logged. > But SuperclassModified... ? > So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ? Nicolai

Jan. 28, 2014