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

Re: [Pharo-project] Issue with gofer/metacello

by StÃ©phane Ducasse

On Dec 27, 2009, at 8:33 PM, Lukas Renggli wrote: >> It is a shame :) > > I agree, but we do not have the resources to maintain two branches. > >> I really wanted to use Pharo 1.1, at least for development. The UI is so >> much faster. > > It would be cool if that could be back-ported to 1.0. no :) we too should not branch. don't dream it is better than we do a 1.1 release faster than get stuck with a 1.0 > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

Where in the PharoTaskForces. Thanks. Stef On Dec 27, 2009, at 8:29 PM, Adrian Kuhn wrote: > Adrian Kuhn <akuhn@...> writes: > >> NB: #shuffle: does not produce all permutations with the same likelihood! It >> should be changed. I can provide the correct implementation. Also then, >> #shuffle: times should be removed. That is nonsense, a broken shuffle does >> no get better the longer you shuffle :) > > Fix uploaded. > > cheers, > AA > > > -- > 2nd Workshop on Software Search et cetera... > Submit papers by January 19, 2010. http://bit.ly/suite2010 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

Adrian I imagine that we clarified some of the flatCollectAsSet:.. I do not remember but we moved method names around because they were not fitting well. Now for shuffle I do not know if we used them and I would remove it. Stef On Dec 27, 2009, at 7:56 PM, Adrian Kuhn wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> here are the collection extensions we use in Moose. I copied them to >> PharoTaskForces so that we can discuss and tweak the code if wanted. > > Just missed #collectAsSet: and #groupedBy: yesterday :) Given that I have > written all of these extensions (except #copyEmpty: and #groupedBy: which are > provided by VW as far I recall) I am of course baised, but also pleased to > see them being used and possibly included in Pharo. > > There is also a #trasitiveClosure: extensions, which was ported by Oscar > already, see http://www.squeaksource.com/CodePhoo but with different > semantics than in the original Codefoo. > > An (incomplete) documentation of Codefoo can be found here > http://scg.unibe.ch/staff/adriankuhn/codefoo > > NB: #shuffle: does not produce all permutations with the same likelihood! It > should be changed. I can provide the correct implementation. Also then, > #shuffle: times should be removed. That is nonsense, a broken shuffle does > no get better the longer you shuffle :) > > cheers, > AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

Re: [Pharo-project] Collection>>select: aBlock ifNoneTakeAsDefault: aDefaultValue

by StÃ©phane Ducasse

The question is how much will we have to backport. Because we do not have that horse power to do that for each little details. I would only backport really important fixes. Stef On Dec 27, 2009, at 7:58 PM, Nicolas Cellier wrote: > 2009/12/27 Lukas Renggli <renggli(a)gmail.com>: >>> Julian: we (stef and I) have something we don't understand. The >>> implementation of ifEmpty: is like this in Pharo: >>> >>> Collection >> ifEmpty: aBlock >>> "Evaluate the block if I'm empty" >>> >>> self isEmpty ifTrue: [ ^aBlock value ] >> >> In Pharo 1.0rc1 it looks like this: >> >> Collection>>ifEmpty: aBlock >> "Evaluate the block if I'm empty" >> >> ^ self isEmpty ifTrue: aBlock >> >> Lukas >> > > It sounds stupid to return nil if not empty. > Should the change in 1.1 be backported ? > > Nicolas > >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 27, 2009

[Pharo-project] Issue 1182: Right clicking in the System browser brings up the debugger

by Danny Chan

Hi! This issue http://code.google.com/p/pharo/issues/detail?id=1182 is closed, but I see the same behaviour in the current pharo1.0-10502-rc1dev09.12.2 image. I also get the same exception when I press escape in the code pane. Danny

Dec. 27, 2009

[Pharo-project] Issue 1704: Cancelling "extract method" refactoring raises OR2UICancellationError

by Danny Chan

Hi! In the current 1.0 release candidate I get an UICancellationError when I select some source code, choose "refactor source/extract method", and then cancel the dialog asking for the selector name. Danny

Dec. 27, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Lukas Renggli

> It is a shame :) I agree, but we do not have the resources to maintain two branches. > I really wanted to use Pharo 1.1, at least for development. Â The UI is so > much faster. It would be cool if that could be back-ported to 1.0. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 27, 2009

Re: [Pharo-project] moose collection extensions

by Adrian Kuhn

Adrian Kuhn <akuhn@...> writes: > NB: #shuffle: does not produce all permutations with the same likelihood! It > should be changed. I can provide the correct implementation. Also then, > #shuffle: times should be removed. That is nonsense, a broken shuffle does > no get better the longer you shuffle :) Fix uploaded. cheers, AA -- 2nd Workshop on Software Search et cetera... Submit papers by January 19, 2010. http://bit.ly/suite2010

Dec. 27, 2009

Re: [Pharo-project] Loading latest Seaside 3.0 in latest Pharo 1.1

by Lukas Renggli

> Is there a proper and simple way to do this with Gofer ? Not at the moment. Seaside 3.0 itself probably works in Pharo 1.1, but some of its dependencies do not. I don't think we will support Pharo 1.1 in the near future, at least not as long as there is no release candidate. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 27, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Ramiro Diaz Trepat

It is a shame :) I really wanted to use Pharo 1.1, at least for development. The UI is so much faster. On Sun, Dec 27, 2009 at 7:23 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > I get problems trying to load Seaside30 using > > [Gofer new > > squeaksource: 'Seaside30'; > > package: 'LoadOrderTests'; > > load] > > valueSupplyingAnswers: { > > {'Load Seaside'. true}. > > {'SqueakSource User Name'. ''}. > > {'SqueakSource Password'. ''}. > > {'Run tests'. false}}. > > You shouldn't use Pharo 1.1 for Seaside 3.0. It is very unlikely to work. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 27, 2009