October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help with a bug fix

by Ferlicot D. Cyril

Le 24/10/2015 15:27, Ferlicot D. Cyril a Ã©crit : > Hi, > > I begun to fix a bug, I have a working fix (I think). But I am not > satisfy by a method I made. I think the method can be much better but I > don't have the knowledge and time to improve it now. > > If someone wish to take a look: > https://pharo.fogbugz.com/f/cases/11091/Ensure-the-current-extension-is-alw… > Thanks to Nicolai and Esteban for the help. As Esteban said this change can be confusing so I want to have your opinion guys. Do you think that the protocols of the current extension should be before the normal protocols ? There is an example on the issue at: https://pharo.fogbugz.com/f/cases/11091/Ensure-the-current-extension-is-alw… Should Pharo integrate this slice or not ? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 24, 2015

Re: [Pharo-dev] String>>#expandMacros new line macro rationale

by Gabriel Cotelli

Slice in Inbox https://pharo.fogbugz.com/f/cases/16863/Make-expandMacros-more-consistent-w… On Sat, Oct 24, 2015 at 4:19 AM, stepharo <stepharo(a)free.fr> wrote: > Hi gabriel > >> >> <n> macro is expanded to CR. I was expecting that expands to the line >> ending of the platform, or at least to LF. >> >> Anybody knows if this have some explanation? >> >> I'm tempted to change the <n> expansion to use OSPlatform current >> lineEnding , and add <r> as a valid macro expanding to CR. I think it's >> more consistent with the general use. >> > > Yes > >> What do you think? If there's consensus I would create an issue and >> provide a Slice with the changes and some test cases. >> > Yes I would love that someone or a group of Pharo lover fix the issues > with the encoding. I remember a discussion a while > ago. > >> >> Gabriel >> > > >

Oct. 24, 2015

Re: [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

by Christophe Demarey

Hi Peter, Le 24 oct. 2015 Ã 20:36, Peter UhnÃ¡k a Ã©crit : > bump? :) > > On Tue, Sep 29, 2015 at 12:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > How practical it is to do set-based comparison in TestAsserter>>assertCollection:hasSameElements: ? > > For example #(1 1 2) has same elements as #(1 2) which may make sense for sets, but not for bags. > > The main reason I was using it is that in tests the expected collection may be created by hand, > which means it is very often an array #(...), { ... }, while models very often return OrderedCollections (at least in my case). I introduced #assertCollection:hasSameElements: for this reason. The problem with using sets is that I do not expect that #(1 1 2) has same elements as #(1 2) > > So my question is --- how to compare collections irrespective of type, and possibly of order? > > A) always convert the actual collection toanArray > > B) change difference: behavior for non-sets (ton of work with catastrophic consequences) > > C) extend TAssertable with new methods like > > #assertElementsOf: actualCollection equals: expectedCollection > #assertUnorderedElementsOf: actualCollection equals: expectedCollection This solution has my preference > C.a) directly in Pharo/SUnit yes, for me, it is a very basic assertion that should be available as default. > C.b) in independend SUnit-Extensions repository/project > C.c) just in my project > > D) stop discussing non-problems > > Thanks, > Peter > Christophe

Oct. 24, 2015

Re: [Pharo-dev] ConfigurationOf and Git

by Gabriel Cotelli

In case anyone is interested, I've managed to re-use the BaselineOf definition inside the ConfigurationOf. If you need to do something similar take a look at https://github.com/gcotelli/RenoirSt/tree/master/source/ConfigurationOfReno… This allows to copy this configuration in the corresponding MetaRepoForPharoX for projects managed using BaselineOf. On Thu, Oct 22, 2015 at 5:48 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 10/22/2015 05:31 AM, Ben Coman wrote: > >> On Thu, Oct 22, 2015 at 1:30 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >> >>> >>> On 10/21/2015 05:55 AM, Ben Coman wrote: >>> >>> >>> >>> On Wed, Oct 21, 2015 at 2:49 AM, Dale Henrichs >>> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>>> Here's the documentation for the Metacello github:// repository >>>> description[1]. ... >>>> >>>> In recent versions of Metacello I have made it possible for you to use >>>> pattern matching in the <version identifier> to provide for >>>> symbolic-version-like facility for github references. >>>> >>>> Instead of stableForPharo4 you would associate a semantic version with >>>> the >>>> code that is "stableForPharo4" for example `4.0.0` and use the tag >>>> `v4.0.0` >>>> to mark the commit that is "stableForPharo4". >>>> >>>> Similarly you'd use the tag `v5.0.0` to mark the commit that is >>>> "stableForPharo5". >>>> >>>> Then you'd use the following in your baseline: method (not in a >>>> symbolicVersion method). >>>> >>>> spec for: #'pharo4.0.x' >>>> do: [spec >>>> baseline: 'Project' >>>> with: [ spec repository: 'github://username/Project:v4.?/']]. >>>> spec for: #'pharo5.0.x' >>>> do: [spec >>>> baseline: 'Project' >>>> with: [ spec repository: 'github://username/Project:v5.?/']]. >>>> >>>> If you end up with a new commit that patches a Pharo4 problem, you'd tag >>>> that commit as `v4.0.1` and so on .... The above `v4.?` pattern will >>>> match >>>> `v4.0.1` and you'll pick up that tag the next time you refresh your >>>> build >>>> (i.e., do a `get` on the Project baseline ... which causes a new >>>> download >>>> from Github) ... >>>> >>> >>> Intuitively I would have thought that #'pharo4.0.x' >>> would correspond to repository: 'github://username/Project:v4.0.?/' >>> I seem to be missing something. >>> >>> I guess it's not intuitive to me, because I'm not sure what point you are >>> making:) >>> >> My point was that these two >> 4.0.x >> 4.0.? >> >> seem to correspond better than these two >> 4.0.x >> 4.? >> >> but maybe I looked at this the wrong way. >> So v4.? would also match pharo4.1.0 ? >> > Ah yes, you do have a point there, because v4.? does match 4.1.0. > > Dale > > >

Oct. 24, 2015

Re: [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

by Peter UhnÃ¡k

bump? :) On Tue, Sep 29, 2015 at 12:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > How practical it is to do set-based comparison > in TestAsserter>>assertCollection:hasSameElements: ? > > For example #(1 1 2) has same elements as #(1 2) which may make sense for > sets, but not for bags. > > The main reason I was using it is that in tests the expected collection > may be created by hand, > which means it is very often an array #(...), { ... }, while models very > often return OrderedCollections (at least in my case). > > So my question is --- how to compare collections irrespective of type, and > possibly of order? > > A) always convert the actual collection toanArray > > B) change difference: behavior for non-sets (ton of work with catastrophic > consequences) > > C) extend TAssertable with new methods like > > #assertElementsOf: actualCollection equals: expectedCollection > #assertUnorderedElementsOf: actualCollection equals: expectedCollection > > C.a) directly in Pharo/SUnit > C.b) in independend SUnit-Extensions repository/project > C.c) just in my project > > D) stop discussing non-problems > > Thanks, > Peter >

Oct. 24, 2015

Re: [Pharo-dev] Question about extensions

by Thierry Goubier

Le 24/10/2015 15:41, Ferlicot D. Cyril a Ã©crit : > Le 24/10/2015 15:38, Thierry Goubier a Ã©crit : >> Le 24/10/2015 15:17, Ferlicot D. Cyril a Ã©crit : >>> Hi, >>> >>> If I browse the Fuel's package I see the True and False classes but >>> there is no extension of Fuel on those classes. >>> If I browse Fuel from Monticello I see True and False on *Extensions but >>> there is nothing. >>> >>> Is there a bug or did I missed something ? >>> >> >> Fuel extensions for True and False are on the class side. >> >> Thierry >> > > Oh! Thank you, I didn't though about the class side. That's an UI issue: it's harder to discover than it should be ;) Thierry

Oct. 24, 2015

Re: [Pharo-dev] Question about extensions

by Ferlicot D. Cyril

Le 24/10/2015 15:38, Thierry Goubier a Ã©crit : > Le 24/10/2015 15:17, Ferlicot D. Cyril a Ã©crit : >> Hi, >> >> If I browse the Fuel's package I see the True and False classes but >> there is no extension of Fuel on those classes. >> If I browse Fuel from Monticello I see True and False on *Extensions but >> there is nothing. >> >> Is there a bug or did I missed something ? >> > > Fuel extensions for True and False are on the class side. > > Thierry > Oh! Thank you, I didn't though about the class side. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 24, 2015

Re: [Pharo-dev] Question about extensions

by Thierry Goubier

Le 24/10/2015 15:17, Ferlicot D. Cyril a Ã©crit : > Hi, > > If I browse the Fuel's package I see the True and False classes but > there is no extension of Fuel on those classes. > If I browse Fuel from Monticello I see True and False on *Extensions but > there is nothing. > > Is there a bug or did I missed something ? > Fuel extensions for True and False are on the class side. Thierry

Oct. 24, 2015

Help with a bug fix

by Ferlicot D. Cyril

Hi, I begun to fix a bug, I have a working fix (I think). But I am not satisfy by a method I made. I think the method can be much better but I don't have the knowledge and time to improve it now. If someone wish to take a look: https://pharo.fogbugz.com/f/cases/11091/Ensure-the-current-extension-is-alw… -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 24, 2015

Question about extensions

by Ferlicot D. Cyril

Hi, If I browse the Fuel's package I see the True and False classes but there is no extension of Fuel on those classes. If I browse Fuel from Monticello I see True and False on *Extensions but there is nothing. Is there a bug or did I missed something ? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 24, 2015