- Pharo-dev - lists.pharo.org

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

by Nicolai Hess

2015-10-25 0:58 GMT+02:00 Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com>: > 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 ? > I like it. But maybe we can add an option in Nautilus settings for this. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

Oct. 25, 2015

Re: [Pharo-dev] [Vm-dev] [squeak-dev] The Trunk: Network-topa.166.mcz

by Levente Uzonyi

I don't see how using KISS would have any effect on this problem - the problem of setting the initial state of the generator. I also don't see how could KISS be implemented in Smalltalk efficiently. Levente On Thu, 22 Oct 2015, Nicolas Cellier wrote: > For these reasons, I often prefer the Marsaglia's KISS > > 2015-10-22 17:57 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 22 Oct 2015, at 2:49 , Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > > > > > On 22.10.2015, at 14:37, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > >> On Thu, Oct 22, 2015 at 06:28:09AM +0000, commits(a)source.squeak.org wrote: > >>> Tobias Pape uploaded a new version of Network to project The Trunk: > >>> http://source.squeak.org/trunk/Network-topa.166.mcz > >>> > >>> ==================== Summary ==================== > >>> > >>> Name: Network-topa.166 > >>> Author: topa > >>> Time: 21 October 2015, 8:26:14.656 pm > >>> UUID: d6d9910f-fa67-4c69-9a89-030c81233e90 > >>> Ancestors: Network-topa.165 > >>> > >>> UUIDGenerator > >>> - Use new Random>>#nextBytes:into:startingAt: (needs Kernel-ul.960) for even more speed > >>> - Fix UUIDGenerator class>>#initialize to correctly register at startup > >>> - Do not reset default on startup but rather reseed TheRandom > >>> > >>> Timings improved:Â '1,190,000 per second. 842 nanoseconds per run.' (0.25 times slower than primitive version) > >>> > >> > >> This is outstanding. The UUID plugin has long been a source of problems in > >> the VM, partly due to issues in various Linux distributions. > >> > >> http://bugs.squeak.org/view.php?id=7358 > >> > >> Making the plugin unnecessary is a big improvement. > > > > Thats what I thought. > > Probably we want to present this (Mersenne PRNG + new UUID gen) to > > the Pharo core developers (cc) so that we can just remove the UUID plugin > > from the VMs (cc vm-dev)? > > > > Best regards > >Â Â Â Â -Tobias > > In the release version of Squeak 5.0, the Mersenne Twister is initialized using a single seed restricted to 32bit. > Has this been changed since to use a wider ranged value? > Otherwise, you run into problems with potential collisions from separate image starts rather too fast for UUID uses... (IMHO) > > Cheers, > Henry > > > >

Oct. 24, 2015

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