December 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] better name for #aggregateRuns:

by Thomas Dupriez

#splitByGroupingWhile: The 'split' indicates it's a method to split a collection, and the 'GroupingWhile' expresses how it's done: by grouping elements while they make the block evaluate to the same value. Le 12/12/2017 Ã 10:50, Sven Van Caekenberghe a Ã©critÂ : > #splitWhile: because the block does not define separators but its value indicates runs ? > >> On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >> >> >> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >>> Hi, >>> >>> do you have some proposals for a better name for the message named #aggregateRuns? >>> >>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>> >>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>> >>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>> >>> The current comment is: >>> "Answer a new collection of the same species as the >>> receiver with elements being collections (of the receiver >>> species) containing those elements of the receiver >>> for which the given block consecutively evaluates to >>> the same object." >>> >>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >>> >>> Cheers, >>> -- Pavel >>

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Sven Van Caekenberghe

#splitWhile: because the block does not define separators but its value indicates runs ? > On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] > > > Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >> Hi, >> >> do you have some proposals for a better name for the message named #aggregateRuns? >> >> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >> >> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >> >> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >> >> The current comment is: >> "Answer a new collection of the same species as the >> receiver with elements being collections (of the receiver >> species) containing those elements of the receiver >> for which the given block consecutively evaluates to >> the same object." >> >> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >> >> Cheers, >> -- Pavel > >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Pavel Krivanek

maybe something in the direction of splitOnThresholds:? 2017-12-12 10:38 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > We already have #splitOn: with slightly different behavior: > > (#(1 2 3 4 1 2 3 5 6 ) splitOn: [ :each | each = 4]) > > So splitOnEach: and splitWhen: would be probably confusing > > 2017-12-12 10:34 GMT+01:00 Thomas Dupriez <thomas.dupriez@ens-paris- > saclay.fr>: > >> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >> >> >> >> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >> >>> Hi, >>> >>> do you have some proposals for a better name for the message named >>> #aggregateRuns? >>> >>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>> >>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>> >>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>> >>> The current comment is: >>> "Answer a new collection of the same species as the >>> receiver with elements being collections (of the receiver >>> species) containing those elements of the receiver >>> for which the given block consecutively evaluates to >>> the same object." >>> >>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-Sequ >>> enceableCollection-aggregateRuns >>> >>> Cheers, >>> -- Pavel >>> >> >> >> >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Pavel Krivanek

We already have #splitOn: with slightly different behavior: (#(1 2 3 4 1 2 3 5 6 ) splitOn: [ :each | each = 4]) So splitOnEach: and splitWhen: would be probably confusing 2017-12-12 10:34 GMT+01:00 Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr>: > #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] > > > > Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : > >> Hi, >> >> do you have some proposals for a better name for the message named >> #aggregateRuns? >> >> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >> >> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >> >> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >> >> The current comment is: >> "Answer a new collection of the same species as the >> receiver with elements being collections (of the receiver >> species) containing those elements of the receiver >> for which the given block consecutively evaluates to >> the same object." >> >> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-Sequ >> enceableCollection-aggregateRuns >> >> Cheers, >> -- Pavel >> > > >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Thomas Dupriez

#(1 2 3 4 1 2 3 5 6 ) splitWhen:Â [ :each | each = 4] Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©critÂ : > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:Â [ :each | each = 4]) > Â Â >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:Â [ :each | each = 4]) > Â Â >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns:Â [ :each | (each \\ 3) = 0]) > Â Â >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… > > Cheers, > -- Pavel

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Denis Kudriashov

Hi #(1 2 3 4 1 2 3 5 6 ) collectGroupsWhere: [ :each | each = 4]) 2017-12-12 10:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to- > SequenceableCollection-aggregateRuns > > Cheers, > -- Pavel >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Alistair Grant

Hi Pavel, On 12 December 2017 at 10:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… > > Cheers, > -- Pavel #groupAround: #selectAround: Cheers, Alistair

Dec. 12, 2017

better name for #aggregateRuns:

by Pavel Krivanek

Hi, do you have some proposals for a better name for the message named #aggregateRuns? (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). The current comment is: "Answer a new collection of the same species as the receiver with elements being collections (of the receiver species) containing those elements of the receiver for which the given block consecutively evaluates to the same object." https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… Cheers, -- Pavel

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Denis Kudriashov

2017-12-12 8:52 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > I think this was added because on windows if we did not rebuild accessors, > some offsets were nil in external structures. Can that still be an issue? > Not only Windows. Problem was in Pharo 6 where external OSWindow not worked because of nil offsets. And Bloc solved it by manual initialisation after loading code. > > Cheers, > Andrei > > On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> >> On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Should the rebuild changes be logged? >> Maybe we can have EpMonitor suspendDuring: [â¦] >> >> >> no they not. >> what should be suspended is field regeneration on bloc config ;) >> >> Esteban >> >> >> MartÃn >> >> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> :) This looks interesting: >>> >>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a >>> rebuild with this author. >>> >>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>>> honestly, this should not be happening. >>>> Now, I have no idea why it is happening at all ;) >>>> >>>> I mean, there is no automatic process that would have a UFFI name there >>>> (the only place where this can happen is on #rebuildFieldAccessors and that >>>> will use an UFFIGenerator author, not just UFFI. >>>> And also that method needs to be executed by handâ¦ >>>> >>>> weirdâ¦ can you search for UFFI in system? >>>> >>>> Esteban >>>> >>>> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> It happens not only from lgit-classes but from other FFI-Subclasses >>>> too, for example AthensCairoMatrix. >>>> >>>> And some methods have a strange version history (see screenshot). >>>> The timestamp of all of the UFFI changes are during loading gtoolkit. >>>> Maybe during loading we have multiple reinitializations that will >>>> recreate autogenerated methods, again and again ? >>>> >>>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>> But these aren't method changes. >>>>> The class definition is changed. (see screenshot) >>>>> It looks like it adds new class variables, even though they were >>>>> alreday in the original fresh image. >>>>> >>>>> >>>>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >>>>> >>>>>> Without taking a closer look, those are probably auto generated >>>>>> methods. >>>>>> >>>>>> Max >>>>>> >>>>>> >>>>>> >>>>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) >>>>>> wrote: >>>>>> >>>>>> How come, loading a github project writes strange code change entries >>>>>> for classes >>>>>> like >>>>>> LGitFetchOptions >>>>>> LGitRemoteCallbacks >>>>>> ... >>>>>> >>>>>> For example, in a Pharo 6.1 image I load bloc like this: >>>>>> >>>>>> Metacello new >>>>>> baseline: 'Bloc'; >>>>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >>>>>> load: #core >>>>>> >>>>>> In my Epicea code change window I see this entries (see screenshot). >>>>>> And the final "new" version of this classes, (class definitions) just >>>>>> look like the >>>>>> original class definition in a fresh image. >>>>>> >>>>>> >>>>>> >>>>> >>>> <PharoScreenshot.1.png> >>>> >>>> >>>> >>> >> >> >

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Esteban Lorenzano

> On 12 Dec 2017, at 08:52, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > I think this was added because on windows if we did not rebuild accessors, some offsets were nil in external structures. Can that still be an issue? it should not. and even if thatâs the case, you do not need to regenerate accessors: executing #compileFields instead #rebuildFieldAccessors should solve any initialisation problems without actually regenerate all structures, which is what you are doing :) Esteban > > Cheers, > Andrei > > On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > >> On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> Should the rebuild changes be logged? >> Maybe we can have EpMonitor suspendDuring: [â¦] > > no they not. > what should be suspended is field regeneration on bloc config ;) > > Esteban > >> >> MartÃn >> >> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> :) This looks interesting: >> >> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a rebuild with this author. >> >> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> honestly, this should not be happening. >> Now, I have no idea why it is happening at all ;) >> >> I mean, there is no automatic process that would have a UFFI name there (the only place where this can happen is on #rebuildFieldAccessors and that will use an UFFIGenerator author, not just UFFI. >> And also that method needs to be executed by handâ¦ >> >> weirdâ¦ can you search for UFFI in system? >> >> Esteban >> >>> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>> >>> It happens not only from lgit-classes but from other FFI-Subclasses too, for example AthensCairoMatrix. >>> >>> And some methods have a strange version history (see screenshot). >>> The timestamp of all of the UFFI changes are during loading gtoolkit. >>> Maybe during loading we have multiple reinitializations that will recreate autogenerated methods, again and again ? >>> >>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >>> But these aren't method changes. >>> The class definition is changed. (see screenshot) >>> It looks like it adds new class variables, even though they were alreday in the original fresh image. >>> >>> >>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >>> Without taking a closer look, those are probably auto generated methods. >>> >>> Max >>> >>> >>> >>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>) wrote: >>> >>>> How come, loading a github project writes strange code change entries for classes >>>> like >>>> LGitFetchOptions >>>> LGitRemoteCallbacks >>>> ... >>>> >>>> For example, in a Pharo 6.1 image I load bloc like this: >>>> >>>> Metacello new >>>> baseline: 'Bloc'; >>>> repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src'; >>>> load: #core >>>> >>>> In my Epicea code change window I see this entries (see screenshot). >>>> And the final "new" version of this classes, (class definitions) just look like the >>>> original class definition in a fresh image. >>>> >>>> >>> >>> >>> <PharoScreenshot.1.png> >> >> >> > >

Dec. 12, 2017