Re: [Pharo-dev] Modification on CollectionsExtensions
Great! Thank you! 2013/6/21 Tudor Girba > Thanks again. > > I committed the change you proposed. So, now we have flatCollect: using > writeStream. > > Cheers, > Doru > > > On Tue, Jun 11, 2013 at 3:18 PM, Sebastian Tleye wrote: > >> Hello, >> >> Fixing some bugs in Traits we realized that it would be good idea to use >> CollectionsExtensions package (it has some useful functions), also it would >> be great to include CollectionsExtensions in Pharo 3.0. >> >> One "problem" we found is that CollectionsExtensions is depending on a >> Nile Package (that's not a desired feature). >> In the method Collection>>flatCollect: there is a line refering to a nile >> function "nsWriteStream". >> >> If i change "nsWriteStream" for "writeStream" the dependency disapears. >> >> I also run all the tests and they are working, so i was wondering if it >> would be possible to commit the change. >> >> Thanks. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
Re: [Pharo-dev] Modification on CollectionsExtensions
Thanks again. I committed the change you proposed. So, now we have flatCollect: using writeStream. Cheers, Doru On Tue, Jun 11, 2013 at 3:18 PM, Sebastian Tleye wrote: > Hello, > > Fixing some bugs in Traits we realized that it would be good idea to use > CollectionsExtensions package (it has some useful functions), also it would > be great to include CollectionsExtensions in Pharo 3.0. > > One "problem" we found is that CollectionsExtensions is depending on a > Nile Package (that's not a desired feature). > In the method Collection>>flatCollect: there is a line refering to a nile > function "nsWriteStream". > > If i change "nsWriteStream" for "writeStream" the dependency disapears. > > I also run all the tests and they are working, so i was wondering if it > would be possible to commit the change. > > Thanks. > -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Modification on CollectionsExtensions
Moose is running (smoothly :)) on Pharo 2.0 since several months now. The idea is to merge the efforts to have more people working on top of the latest Pharo. There are two reasons for it: - first, we are too small of a community to split our efforts - second, often the Moose projects are directly relevant for Pharo and the other way around Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow." On 13.06.2013, at 23:24, "Sean P. DeNigris" wrote: > Tudor Girba-2 wrote >> We will release Moose at the end of this month and we will move to Pharo >> 3.0 > > I'm impressed! Did you move Moose to Pharo 2.0 before it was released? I > have been hesitant to move my projects to the alpha/beta versions because we > are making so much progress (i.e. breaking things, lol)... > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-dev-Modification-on-CollectionsExtensions-tp4692784p4693234.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] Modification on CollectionsExtensions
Tudor Girba-2 wrote > We will release Moose at the end of this month and we will move to Pharo > 3.0 I'm impressed! Did you move Moose to Pharo 2.0 before it was released? I have been hesitant to move my projects to the alpha/beta versions because we are making so much progress (i.e. breaking things, lol)... - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Modification-on-CollectionsExtensions-tp4692784p4693234.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Modification on CollectionsExtensions
First, thanks for looking at CollectionsExtensions. But, please do not remove flatCollect: yet! This is used everywhere in Moose. We will release Moose at the end of this month and we will move to Pharo 3.0, and then we can do what we want. Doru -- www.tudorgirba.com "Every thing has its own flow." On 12.06.2013, at 17:41, Stéphane Ducasse wrote: > but pay attention because in 2.0 you will need it. > :) > > On Jun 12, 2013, at 4:13 PM, Guillaume Larcheveque > wrote: > >> Ok so if everyone agree I will remove the flatCollect: method from >> CollectionExtensions since Sebastian made the correction in Pharo 3.0. >> >> >> 2013/6/12 Stéphane Ducasse >>> >>> On Jun 12, 2013, at 1:02 PM, Sebastian Tleye wrote: >>> ok, i understood, Discussing with Marcus we believe that it would be better to keep Collecition>>gather: and add Collection>>flatCollect: (with the same implementation) and put a comment in gather: saying that is kept for compatibility purposes. flatCollect: will be included in Pharo and will be removed from CollectionExtensions. >>> >>> + 1 >>> >> >> >> >> -- >> Guillaume Larcheveque >
Re: [Pharo-dev] Modification on CollectionsExtensions
but pay attention because in 2.0 you will need it. :) On Jun 12, 2013, at 4:13 PM, Guillaume Larcheveque wrote: > Ok so if everyone agree I will remove the flatCollect: method from > CollectionExtensions since Sebastian made the correction in Pharo 3.0. > > > 2013/6/12 Stéphane Ducasse > > On Jun 12, 2013, at 1:02 PM, Sebastian Tleye wrote: > >> ok, i understood, >> >> Discussing with Marcus we believe that it would be better to keep >> Collecition>>gather: and add Collection>>flatCollect: (with the same >> implementation) and put a comment in gather: saying that is kept for >> compatibility purposes. >> >> flatCollect: will be included in Pharo and will be removed from >> CollectionExtensions. >> > > + 1 > >> > > > > -- > Guillaume Larcheveque >
Re: [Pharo-dev] Modification on CollectionsExtensions
Ok so if everyone agree I will remove the flatCollect: method from CollectionExtensions since Sebastian made the correction in Pharo 3.0. 2013/6/12 Stéphane Ducasse > > On Jun 12, 2013, at 1:02 PM, Sebastian Tleye wrote: > > ok, i understood, > > Discussing with Marcus we believe that it would be better to keep > Collecition>>gather: and add Collection>>flatCollect: (with the same > implementation) and put a comment in gather: saying that is kept for > compatibility purposes. > > flatCollect: will be included in Pharo and will be removed from > CollectionExtensions. > > > + 1 > > >> -- *Guillaume Larcheveque*
Re: [Pharo-dev] Modification on CollectionsExtensions
On Jun 12, 2013, at 1:02 PM, Sebastian Tleye wrote: > ok, i understood, > > Discussing with Marcus we believe that it would be better to keep > Collecition>>gather: and add Collection>>flatCollect: (with the same > implementation) and put a comment in gather: saying that is kept for > compatibility purposes. > > flatCollect: will be included in Pharo and will be removed from > CollectionExtensions. > + 1 >
Re: [Pharo-dev] Modification on CollectionsExtensions
+ 1 guys a name and an implementation body are two separate entities. > >> #gather: directly applies the stream fusion technique as its >> implementation, so is faster than the current implementation of >> #flatCollect: >> >> Stef's saying "why not move #gather:'s implemenation to #flatCollect:, >> and make the old #gather: call the new #flatCollect:" > > Er, and that would mean moving #flatCollect: out of > CollectionsExtensions into the base image. > >> frank >> >> On 12 June 2013 10:33, Sebastian Tleye wrote: >>> As far as i know the implementation of gather: is faster than the >>> implementation of flatCollect: >>> >>> >>> 2013/6/12 Stéphane Ducasse Why not the inverse. They are much more users of flatCollect: then gather: and again gather: sucks. It does not convey that this is a mapcan ie happening the results of each iteration into the So flatCollect: is 10 times more explicit and better. you flatten the results of the collect: Stef I think the simplest solution is to keep both and that flatCollect directly call gather: If you agree with that, I will correct the moose extension package 2013/6/11 Stéphane Ducasse > > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: > > If they are not different so a better way would be replace > #flatenCollect: by #gather: > but anyway, moose people should decide and commit the change since i am > not a moose developer. > > > 2013/6/11 Marcus Denker >> >> >> On Jun 11, 2013, at 4:24 PM, Frank Shearar >> wrote: >> >>> On 11 June 2013 14:18, Sebastian Tleye wrote: Hello, Fixing some bugs in Traits we realized that it would be good idea to use CollectionsExtensions package (it has some useful functions), also it would be great to include CollectionsExtensions in Pharo 3.0. >>> >>> Is this the HPI library? I seem to recall TraitClasses [1] using it. >> >> CollectionExtension is from Moose. >> >> the Trait based Stream refactoring was done some years ago but has not >> been used >> or maintained. >> >>Marcus > > > -- Guillaume Larcheveque >>> >
Re: [Pharo-dev] Modification on CollectionsExtensions
sorry, gather will call flatCollect: is not the same code. 2013/6/12 Sebastian Tleye > ok, i understood, > > Discussing with Marcus we believe that it would be better to keep > Collecition>>gather: and add Collection>>flatCollect: (with the same > implementation) and put a comment in gather: saying that is kept for > compatibility purposes. > > flatCollect: will be included in Pharo and will be removed from > CollectionExtensions. > > > > > 2013/6/12 Frank Shearar > >> On 12 June 2013 10:54, Frank Shearar wrote: >> > #gather: directly applies the stream fusion technique as its >> > implementation, so is faster than the current implementation of >> > #flatCollect: >> > >> > Stef's saying "why not move #gather:'s implemenation to #flatCollect:, >> > and make the old #gather: call the new #flatCollect:" >> >> Er, and that would mean moving #flatCollect: out of >> CollectionsExtensions into the base image. >> >> > frank >> > >> > On 12 June 2013 10:33, Sebastian Tleye wrote: >> >> As far as i know the implementation of gather: is faster than the >> >> implementation of flatCollect: >> >> >> >> >> >> 2013/6/12 Stéphane Ducasse >> >>> >> >>> Why not the inverse. >> >>> They are much more users of flatCollect: then gather: >> >>> >> >>> and again gather: sucks. It does not convey that this is a mapcan >> >>> ie happening the results of each iteration into the >> >>> >> >>> So flatCollect: is 10 times more explicit and better. >> >>> you flatten the results of the collect: >> >>> >> >>> Stef >> >>> >> >>> >> >>> I think the simplest solution is to keep both and that flatCollect >> >>> directly call gather: >> >>> >> >>> If you agree with that, I will correct the moose extension package >> >>> >> >>> >> >>> 2013/6/11 Stéphane Ducasse >> >> gather: sucks as a name. >> flatCollect: is much better so do not remove it. >> >> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye >> wrote: >> >> If they are not different so a better way would be replace >> #flatenCollect: by #gather: >> but anyway, moose people should decide and commit the change since i >> am >> not a moose developer. >> >> >> 2013/6/11 Marcus Denker >> > >> > >> > On Jun 11, 2013, at 4:24 PM, Frank Shearar > > >> > wrote: >> > >> > > On 11 June 2013 14:18, Sebastian Tleye wrote: >> > >> Hello, >> > >> >> > >> Fixing some bugs in Traits we realized that it would be good >> idea to >> > >> use >> > >> CollectionsExtensions package (it has some useful functions), >> also it >> > >> would >> > >> be great to include CollectionsExtensions in Pharo 3.0. >> > > >> > > Is this the HPI library? I seem to recall TraitClasses [1] using >> it. >> > >> > CollectionExtension is from Moose. >> > >> > the Trait based Stream refactoring was done some years ago but has >> not >> > been used >> > or maintained. >> > >> > Marcus >> >> >> >> >>> >> >>> >> >>> >> >>> -- >> >>> Guillaume Larcheveque >> >>> >> >>> >> >> >> >> >
Re: [Pharo-dev] Modification on CollectionsExtensions
ok, i understood, Discussing with Marcus we believe that it would be better to keep Collecition>>gather: and add Collection>>flatCollect: (with the same implementation) and put a comment in gather: saying that is kept for compatibility purposes. flatCollect: will be included in Pharo and will be removed from CollectionExtensions. 2013/6/12 Frank Shearar > On 12 June 2013 10:54, Frank Shearar wrote: > > #gather: directly applies the stream fusion technique as its > > implementation, so is faster than the current implementation of > > #flatCollect: > > > > Stef's saying "why not move #gather:'s implemenation to #flatCollect:, > > and make the old #gather: call the new #flatCollect:" > > Er, and that would mean moving #flatCollect: out of > CollectionsExtensions into the base image. > > > frank > > > > On 12 June 2013 10:33, Sebastian Tleye wrote: > >> As far as i know the implementation of gather: is faster than the > >> implementation of flatCollect: > >> > >> > >> 2013/6/12 Stéphane Ducasse > >>> > >>> Why not the inverse. > >>> They are much more users of flatCollect: then gather: > >>> > >>> and again gather: sucks. It does not convey that this is a mapcan > >>> ie happening the results of each iteration into the > >>> > >>> So flatCollect: is 10 times more explicit and better. > >>> you flatten the results of the collect: > >>> > >>> Stef > >>> > >>> > >>> I think the simplest solution is to keep both and that flatCollect > >>> directly call gather: > >>> > >>> If you agree with that, I will correct the moose extension package > >>> > >>> > >>> 2013/6/11 Stéphane Ducasse > > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye > wrote: > > If they are not different so a better way would be replace > #flatenCollect: by #gather: > but anyway, moose people should decide and commit the change since i > am > not a moose developer. > > > 2013/6/11 Marcus Denker > > > > > > On Jun 11, 2013, at 4:24 PM, Frank Shearar > > wrote: > > > > > On 11 June 2013 14:18, Sebastian Tleye wrote: > > >> Hello, > > >> > > >> Fixing some bugs in Traits we realized that it would be good idea > to > > >> use > > >> CollectionsExtensions package (it has some useful functions), > also it > > >> would > > >> be great to include CollectionsExtensions in Pharo 3.0. > > > > > > Is this the HPI library? I seem to recall TraitClasses [1] using > it. > > > > CollectionExtension is from Moose. > > > > the Trait based Stream refactoring was done some years ago but has > not > > been used > > or maintained. > > > > Marcus > > > > >>> > >>> > >>> > >>> -- > >>> Guillaume Larcheveque > >>> > >>> > >> > >
Re: [Pharo-dev] Modification on CollectionsExtensions
On 12 June 2013 10:54, Frank Shearar wrote: > #gather: directly applies the stream fusion technique as its > implementation, so is faster than the current implementation of > #flatCollect: > > Stef's saying "why not move #gather:'s implemenation to #flatCollect:, > and make the old #gather: call the new #flatCollect:" Er, and that would mean moving #flatCollect: out of CollectionsExtensions into the base image. > frank > > On 12 June 2013 10:33, Sebastian Tleye wrote: >> As far as i know the implementation of gather: is faster than the >> implementation of flatCollect: >> >> >> 2013/6/12 Stéphane Ducasse >>> >>> Why not the inverse. >>> They are much more users of flatCollect: then gather: >>> >>> and again gather: sucks. It does not convey that this is a mapcan >>> ie happening the results of each iteration into the >>> >>> So flatCollect: is 10 times more explicit and better. >>> you flatten the results of the collect: >>> >>> Stef >>> >>> >>> I think the simplest solution is to keep both and that flatCollect >>> directly call gather: >>> >>> If you agree with that, I will correct the moose extension package >>> >>> >>> 2013/6/11 Stéphane Ducasse gather: sucks as a name. flatCollect: is much better so do not remove it. On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: If they are not different so a better way would be replace #flatenCollect: by #gather: but anyway, moose people should decide and commit the change since i am not a moose developer. 2013/6/11 Marcus Denker > > > On Jun 11, 2013, at 4:24 PM, Frank Shearar > wrote: > > > On 11 June 2013 14:18, Sebastian Tleye wrote: > >> Hello, > >> > >> Fixing some bugs in Traits we realized that it would be good idea to > >> use > >> CollectionsExtensions package (it has some useful functions), also it > >> would > >> be great to include CollectionsExtensions in Pharo 3.0. > > > > Is this the HPI library? I seem to recall TraitClasses [1] using it. > > CollectionExtension is from Moose. > > the Trait based Stream refactoring was done some years ago but has not > been used > or maintained. > > Marcus >>> >>> >>> >>> -- >>> Guillaume Larcheveque >>> >>> >>
Re: [Pharo-dev] Modification on CollectionsExtensions
#gather: directly applies the stream fusion technique as its implementation, so is faster than the current implementation of #flatCollect: Stef's saying "why not move #gather:'s implemenation to #flatCollect:, and make the old #gather: call the new #flatCollect:" frank On 12 June 2013 10:33, Sebastian Tleye wrote: > As far as i know the implementation of gather: is faster than the > implementation of flatCollect: > > > 2013/6/12 Stéphane Ducasse >> >> Why not the inverse. >> They are much more users of flatCollect: then gather: >> >> and again gather: sucks. It does not convey that this is a mapcan >> ie happening the results of each iteration into the >> >> So flatCollect: is 10 times more explicit and better. >> you flatten the results of the collect: >> >> Stef >> >> >> I think the simplest solution is to keep both and that flatCollect >> directly call gather: >> >> If you agree with that, I will correct the moose extension package >> >> >> 2013/6/11 Stéphane Ducasse >>> >>> gather: sucks as a name. >>> flatCollect: is much better so do not remove it. >>> >>> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: >>> >>> If they are not different so a better way would be replace >>> #flatenCollect: by #gather: >>> but anyway, moose people should decide and commit the change since i am >>> not a moose developer. >>> >>> >>> 2013/6/11 Marcus Denker On Jun 11, 2013, at 4:24 PM, Frank Shearar wrote: > On 11 June 2013 14:18, Sebastian Tleye wrote: >> Hello, >> >> Fixing some bugs in Traits we realized that it would be good idea to >> use >> CollectionsExtensions package (it has some useful functions), also it >> would >> be great to include CollectionsExtensions in Pharo 3.0. > > Is this the HPI library? I seem to recall TraitClasses [1] using it. CollectionExtension is from Moose. the Trait based Stream refactoring was done some years ago but has not been used or maintained. Marcus >>> >>> >>> >> >> >> >> -- >> Guillaume Larcheveque >> >> >
Re: [Pharo-dev] Modification on CollectionsExtensions
As far as i know the implementation of gather: is faster than the implementation of flatCollect: 2013/6/12 Stéphane Ducasse > Why not the inverse. > They are much more users of flatCollect: then gather: > > and again gather: sucks. It does not convey that this is a mapcan > ie happening the results of each iteration into the > > So flatCollect: is 10 times more explicit and better. > you flatten the results of the collect: > > Stef > > > I think the simplest solution is to keep both and that flatCollect > directly call gather: > > If you agree with that, I will correct the moose extension package > > > 2013/6/11 Stéphane Ducasse > >> gather: sucks as a name. >> flatCollect: is much better so do not remove it. >> >> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: >> >> If they are not different so a better way would be replace >> #flatenCollect: by #gather: >> but anyway, moose people should decide and commit the change since i am >> not a moose developer. >> >> >> 2013/6/11 Marcus Denker >> >>> >>> On Jun 11, 2013, at 4:24 PM, Frank Shearar >>> wrote: >>> >>> > On 11 June 2013 14:18, Sebastian Tleye wrote: >>> >> Hello, >>> >> >>> >> Fixing some bugs in Traits we realized that it would be good idea to >>> use >>> >> CollectionsExtensions package (it has some useful functions), also it >>> would >>> >> be great to include CollectionsExtensions in Pharo 3.0. >>> > >>> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >>> >>> CollectionExtension is from Moose. >>> >>> the Trait based Stream refactoring was done some years ago but has not >>> been used >>> or maintained. >>> >>> Marcus >>> >> >> >> > > > -- > *Guillaume Larcheveque* > > >
Re: [Pharo-dev] Modification on CollectionsExtensions
Why not the inverse. They are much more users of flatCollect: then gather: and again gather: sucks. It does not convey that this is a mapcan ie happening the results of each iteration into the So flatCollect: is 10 times more explicit and better. you flatten the results of the collect: Stef > I think the simplest solution is to keep both and that flatCollect directly > call gather: > > If you agree with that, I will correct the moose extension package > > > 2013/6/11 Stéphane Ducasse > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: > >> If they are not different so a better way would be replace #flatenCollect: >> by #gather: >> but anyway, moose people should decide and commit the change since i am not >> a moose developer. >> >> >> 2013/6/11 Marcus Denker >> >> On Jun 11, 2013, at 4:24 PM, Frank Shearar wrote: >> >> > On 11 June 2013 14:18, Sebastian Tleye wrote: >> >> Hello, >> >> >> >> Fixing some bugs in Traits we realized that it would be good idea to use >> >> CollectionsExtensions package (it has some useful functions), also it >> >> would >> >> be great to include CollectionsExtensions in Pharo 3.0. >> > >> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >> >> CollectionExtension is from Moose. >> >> the Trait based Stream refactoring was done some years ago but has not been >> used >> or maintained. >> >> Marcus >> > > > > > -- > Guillaume Larcheveque >
Re: [Pharo-dev] Modification on CollectionsExtensions
+1 2013/6/12 Guillaume Larcheveque > I think the simplest solution is to keep both and that flatCollect > directly call gather: > > If you agree with that, I will correct the moose extension package > > > 2013/6/11 Stéphane Ducasse > >> gather: sucks as a name. >> flatCollect: is much better so do not remove it. >> >> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: >> >> If they are not different so a better way would be replace >> #flatenCollect: by #gather: >> but anyway, moose people should decide and commit the change since i am >> not a moose developer. >> >> >> 2013/6/11 Marcus Denker >> >>> >>> On Jun 11, 2013, at 4:24 PM, Frank Shearar >>> wrote: >>> >>> > On 11 June 2013 14:18, Sebastian Tleye wrote: >>> >> Hello, >>> >> >>> >> Fixing some bugs in Traits we realized that it would be good idea to >>> use >>> >> CollectionsExtensions package (it has some useful functions), also it >>> would >>> >> be great to include CollectionsExtensions in Pharo 3.0. >>> > >>> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >>> >>> CollectionExtension is from Moose. >>> >>> the Trait based Stream refactoring was done some years ago but has not >>> been used >>> or maintained. >>> >>> Marcus >>> >> >> >> > > > -- > *Guillaume Larcheveque* > >
Re: [Pharo-dev] Modification on CollectionsExtensions
I think the simplest solution is to keep both and that flatCollect directly call gather: If you agree with that, I will correct the moose extension package 2013/6/11 Stéphane Ducasse > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: > > If they are not different so a better way would be replace #flatenCollect: > by #gather: > but anyway, moose people should decide and commit the change since i am > not a moose developer. > > > 2013/6/11 Marcus Denker > >> >> On Jun 11, 2013, at 4:24 PM, Frank Shearar >> wrote: >> >> > On 11 June 2013 14:18, Sebastian Tleye wrote: >> >> Hello, >> >> >> >> Fixing some bugs in Traits we realized that it would be good idea to >> use >> >> CollectionsExtensions package (it has some useful functions), also it >> would >> >> be great to include CollectionsExtensions in Pharo 3.0. >> > >> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >> >> CollectionExtension is from Moose. >> >> the Trait based Stream refactoring was done some years ago but has not >> been used >> or maintained. >> >> Marcus >> > > > -- *Guillaume Larcheveque*
Re: [Pharo-dev] Modification on CollectionsExtensions
gather: sucks as a name. flatCollect: is much better so do not remove it. On Jun 11, 2013, at 4:53 PM, Sebastian Tleye wrote: > If they are not different so a better way would be replace #flatenCollect: by > #gather: > but anyway, moose people should decide and commit the change since i am not a > moose developer. > > > 2013/6/11 Marcus Denker > > On Jun 11, 2013, at 4:24 PM, Frank Shearar wrote: > > > On 11 June 2013 14:18, Sebastian Tleye wrote: > >> Hello, > >> > >> Fixing some bugs in Traits we realized that it would be good idea to use > >> CollectionsExtensions package (it has some useful functions), also it would > >> be great to include CollectionsExtensions in Pharo 3.0. > > > > Is this the HPI library? I seem to recall TraitClasses [1] using it. > > CollectionExtension is from Moose. > > the Trait based Stream refactoring was done some years ago but has not been > used > or maintained. > > Marcus >
Re: [Pharo-dev] Modification on CollectionsExtensions
Yes please go ahead. Stef On Jun 11, 2013, at 4:49 PM, Sebastian Tleye wrote: > I don't know, i should see the implementation, i just want to remove the > dependency between CollectionsExtensions and Nile and one way to do it is > modifying #flatCollect: implementation. > > if they are the same #flatCollect: could be remove safely replaced. > > > 2013/6/11 Camille Teruel > > On 11 juin 2013, at 15:18, Sebastian Tleye wrote: > > > Hello, > > > > Fixing some bugs in Traits we realized that it would be good idea to use > > CollectionsExtensions package (it has some useful functions), also it would > > be great to include CollectionsExtensions in Pharo 3.0. > > > > One "problem" we found is that CollectionsExtensions is depending on a Nile > > Package (that's not a desired feature). > > In the method Collection>>flatCollect: there is a line refering to a nile > > function "nsWriteStream". > > How this #flatCollect: is different from #gather: anyway? > > > > > If i change "nsWriteStream" for "writeStream" the dependency disapears. > > > > I also run all the tests and they are working, so i was wondering if it > > would be possible to commit the change. > > > > Thanks. > > >
Re: [Pharo-dev] Modification on CollectionsExtensions
If they are not different so a better way would be replace #flatenCollect: by #gather: but anyway, moose people should decide and commit the change since i am not a moose developer. 2013/6/11 Marcus Denker > > On Jun 11, 2013, at 4:24 PM, Frank Shearar > wrote: > > > On 11 June 2013 14:18, Sebastian Tleye wrote: > >> Hello, > >> > >> Fixing some bugs in Traits we realized that it would be good idea to use > >> CollectionsExtensions package (it has some useful functions), also it > would > >> be great to include CollectionsExtensions in Pharo 3.0. > > > > Is this the HPI library? I seem to recall TraitClasses [1] using it. > > CollectionExtension is from Moose. > > the Trait based Stream refactoring was done some years ago but has not > been used > or maintained. > > Marcus >
Re: [Pharo-dev] Modification on CollectionsExtensions
On Jun 11, 2013, at 4:54 PM, Sebastian Tleye wrote: > If they are not different so a better way would be replace #flatenCollect: by > #gather: > but anyway, moose people should decide and commit the change since i am not a > moose developer. > > The moose people should have taken the lead to get the extension integrated a *long* time ago… nothing happens by itself. Marcus > 2013/6/11 Marcus Denker > > On Jun 11, 2013, at 4:24 PM, Frank Shearar wrote: > > > On 11 June 2013 14:18, Sebastian Tleye wrote: > >> Hello, > >> > >> Fixing some bugs in Traits we realized that it would be good idea to use > >> CollectionsExtensions package (it has some useful functions), also it would > >> be great to include CollectionsExtensions in Pharo 3.0. > > > > Is this the HPI library? I seem to recall TraitClasses [1] using it. > > CollectionExtension is from Moose. > > the Trait based Stream refactoring was done some years ago but has not been > used > or maintained. > > Marcus >
Re: [Pharo-dev] Modification on CollectionsExtensions
On Jun 11, 2013, at 4:24 PM, Frank Shearar wrote: > On 11 June 2013 14:18, Sebastian Tleye wrote: >> Hello, >> >> Fixing some bugs in Traits we realized that it would be good idea to use >> CollectionsExtensions package (it has some useful functions), also it would >> be great to include CollectionsExtensions in Pharo 3.0. > > Is this the HPI library? I seem to recall TraitClasses [1] using it. CollectionExtension is from Moose. the Trait based Stream refactoring was done some years ago but has not been used or maintained. Marcus
Re: [Pharo-dev] Modification on CollectionsExtensions
I don't know, i should see the implementation, i just want to remove the dependency between CollectionsExtensions and Nile and one way to do it is modifying #flatCollect: implementation. if they are the same #flatCollect: could be remove safely replaced. 2013/6/11 Camille Teruel > > On 11 juin 2013, at 15:18, Sebastian Tleye wrote: > > > Hello, > > > > Fixing some bugs in Traits we realized that it would be good idea to use > CollectionsExtensions package (it has some useful functions), also it would > be great to include CollectionsExtensions in Pharo 3.0. > > > > One "problem" we found is that CollectionsExtensions is depending on a > Nile Package (that's not a desired feature). > > In the method Collection>>flatCollect: there is a line refering to a > nile function "nsWriteStream". > > How this #flatCollect: is different from #gather: anyway? > > > > > If i change "nsWriteStream" for "writeStream" the dependency disapears. > > > > I also run all the tests and they are working, so i was wondering if it > would be possible to commit the change. > > > > Thanks. > > >
Re: [Pharo-dev] Modification on CollectionsExtensions
On 11 June 2013 15:37, Camille Teruel wrote: > > On 11 juin 2013, at 15:18, Sebastian Tleye wrote: > >> Hello, >> >> Fixing some bugs in Traits we realized that it would be good idea to use >> CollectionsExtensions package (it has some useful functions), also it would >> be great to include CollectionsExtensions in Pharo 3.0. >> >> One "problem" we found is that CollectionsExtensions is depending on a Nile >> Package (that's not a desired feature). >> In the method Collection>>flatCollect: there is a line refering to a nile >> function "nsWriteStream". > > How this #flatCollect: is different from #gather: anyway? Functionally, it's no different. frank >> If i change "nsWriteStream" for "writeStream" the dependency disapears. >> >> I also run all the tests and they are working, so i was wondering if it >> would be possible to commit the change. >> >> Thanks. > >
Re: [Pharo-dev] Modification on CollectionsExtensions
On 11 juin 2013, at 15:18, Sebastian Tleye wrote: > Hello, > > Fixing some bugs in Traits we realized that it would be good idea to use > CollectionsExtensions package (it has some useful functions), also it would > be great to include CollectionsExtensions in Pharo 3.0. > > One "problem" we found is that CollectionsExtensions is depending on a Nile > Package (that's not a desired feature). > In the method Collection>>flatCollect: there is a line refering to a nile > function "nsWriteStream". How this #flatCollect: is different from #gather: anyway? > > If i change "nsWriteStream" for "writeStream" the dependency disapears. > > I also run all the tests and they are working, so i was wondering if it would > be possible to commit the change. > > Thanks.
Re: [Pharo-dev] Modification on CollectionsExtensions
On 11 June 2013 14:18, Sebastian Tleye wrote: > Hello, > > Fixing some bugs in Traits we realized that it would be good idea to use > CollectionsExtensions package (it has some useful functions), also it would > be great to include CollectionsExtensions in Pharo 3.0. Is this the HPI library? I seem to recall TraitClasses [1] using it. frank [1] https://github.com/lauritzthamsen/TraitClasses > One "problem" we found is that CollectionsExtensions is depending on a Nile > Package (that's not a desired feature). > In the method Collection>>flatCollect: there is a line refering to a nile > function "nsWriteStream". > > If i change "nsWriteStream" for "writeStream" the dependency disapears. > > I also run all the tests and they are working, so i was wondering if it > would be possible to commit the change. > > Thanks.
