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 28, 2014, at 12:21 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> Therefore, my suggestion is to keep it location agnostic > > I still don't get it. Do you suggest that the launcher should always > ask the user where to put new images? Here is an idea: you can count the clicks and the cases itâd satisfy Also, if you want to, you can use the OS specific directory as default path for when itâs brand new (after that, my guess is that itâd be more convenient to use the same path as the last opened image) When itâs brand new, you donât print the list and change the path label to âCreate a new image on directory:â and you have a complete non-nonsense experience for nerds and dummies

Jan. 28, 2014

Re: [Pharo-dev] Where to report bugs?

by Marcus Denker

On 28 Jan 2014, at 16:54, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi, > > I tried fogbugz but I failed to connect... > Is there another place. > No. Fogbugz it is. Marcus

Jan. 28, 2014

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

by Tudor Girba

Could you be more specific? Which issue? Doru On Tue, Jan 28, 2014 at 4:50 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It's a duplicate of a closed issue (recently integrated by Sven) > We should maybe join forces :) > > Ben > > On 28 Jan 2014, at 12:41, Martin Dias <tinchodias(a)gmail.com> wrote: > > Done. > https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU > > > > On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> 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" >> > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 28, 2014

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

by Tudor Girba

Thanks, Martin. I will look tomorrow morning. Doru On Tue, Jan 28, 2014 at 4:41 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Done. > https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU > > > > On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> 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" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 28, 2014

Where to report bugs?

by Noury Bouraqadi

Hi, I tried fogbugz but I failed to connect... Is there another place. I wanted to report that changes after a fileIn in Pharo 3.0 seem to be buggy. Class definitions (do it) are ignored and methods are recorded twice. I tried on the latest 30727. Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --

Jan. 28, 2014

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

by Benjamin

Itâs a duplicate of a closed issue (recently integrated by Sven) We should maybe join forces :) Ben On 28 Jan 2014, at 12:41, Martin Dias <tinchodias(a)gmail.com> wrote: > Done. > https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU > > > > On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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

Done. https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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] [Pharo-users] PharoLauncher as the default Pharo download on pharo.org?

by Damien Cassou

On Tue, Jan 28, 2014 at 2:14 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Therefore, my suggestion is to keep it location agnostic I still don't get it. Do you suggest that the launcher should always ask the user where to put new images? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Jan. 28, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30727 Home: https://github.com/pharo-project/pharo-core

Jan. 28, 2014

[pharo-project/pharo-core] d96ff4: 30727

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: d96ff4ca59742c351acb38c77a90d71545ac5698 https://github.com/pharo-project/pharo-core/commit/d96ff4ca59742c351acb38c7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-28 (Tue, 28 Jan 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script380.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30727.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/SmalltalkImage.class/instance/miscellaneous/openLog.st A Tests.package/SmalltalkImageTest.class/instance/helpers/writeToLogWithFileNamed_.st A Tests.package/SmalltalkImageTest.class/instance/testing/testOpenLog.st A Tests.package/TraitCompositionTest.class/instance/testing-comparing/testSyntacticEqualsWithAlias.st A Tests.package/TraitCompositionTest.class/instance/testing-comparing/testSyntacticEqualsWithComplexCompositions.st A Tests.package/TraitCompositionTest.class/instance/testing-comparing/testSyntacticEqualsWithComposition.st A Tests.package/TraitCompositionTest.class/instance/testing-comparing/testSyntacticEqualsWithExclusion.st M Tests.package/TraitsResource.class/README.md A Tests.package/TraitsResource.class/instance/accessing/categoryName.st A Tests.package/TraitsResource.class/instance/accessing/createdClassesAndTraits.st R Tests.package/TraitsResource.class/instance/as yet unclassified/categoryName.st R Tests.package/TraitsResource.class/instance/as yet unclassified/createClassNamed_superclass_uses_.st R Tests.package/TraitsResource.class/instance/as yet unclassified/createTraitNamed_uses_.st R Tests.package/TraitsResource.class/instance/as yet unclassified/createdClassesAndTraits.st R Tests.package/TraitsResource.class/instance/as yet unclassified/setUp.st R Tests.package/TraitsResource.class/instance/as yet unclassified/setUpTranslatingRequiresFixture.st R Tests.package/TraitsResource.class/instance/as yet unclassified/setUpTrivialRequiresFixture.st R Tests.package/TraitsResource.class/instance/as yet unclassified/setUpTwoLevelRequiresFixture.st R Tests.package/TraitsResource.class/instance/as yet unclassified/tearDown.st A Tests.package/TraitsResource.class/instance/running/setUp.st A Tests.package/TraitsResource.class/instance/running/setUpTranslatingRequiresFixture.st A Tests.package/TraitsResource.class/instance/running/setUpTrivialRequiresFixture.st A Tests.package/TraitsResource.class/instance/running/setUpTwoLevelRequiresFixture.st A Tests.package/TraitsResource.class/instance/running/tearDown.st A Tests.package/TraitsResource.class/instance/utility/createClassNamed_superclass_uses_.st A Tests.package/TraitsResource.class/instance/utility/createTraitNamed_uses_.st A Traits.package/TraitAlias.class/instance/comparing/syntacticallyEquals_.st A Traits.package/TraitComposition.class/instance/comparing/syntacticallyEquals_.st A Traits.package/TraitDescription.class/instance/as yet unclassified /syntacticallyEquals_.st A Traits.package/TraitExclusion.class/instance/comparing/syntacticallyEquals_.st A Traits.package/TraitTransformation.class/instance/comparing/syntacticallyEquals_.st Log Message: ----------- 30727 12690 Infinite recursion with #wantsLineEndConversion: on command-line https://pharo.fogbugz.com/f/cases/12690 12689 Implement equality in TraitComposition https://pharo.fogbugz.com/f/cases/12689 http://files.pharo.org/image/30/30727.zip

Jan. 28, 2014