- Pharo-dev - lists.pharo.org

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

by Tudor Girba

Hi Dale, I did, but there seems to be an error during the bootstrapping of the metacello in a new Pharo image. Cheers, Doru On 27 Dec 2009, at 20:06, Dale Henrichs wrote: > Doru, > > Have you tried 1.0-beta.18 with the "latest gofer"? > > Dale > ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: > > | Hi, > | > | The problem is that Metacello is not quite working with the latest > | Gofer. > | > | Cheers, > | Doru > | > | > | On 27 Dec 2009, at 17:39, Alexandre Bergel wrote: > | > | > Hi Lukas, > | > > | > In a fresh 10502 I evaluated: > | > -=-=-=-=-=-=-=-=-= > | > [ Gofer gofer load ] > | > on: Error > | > do: [ :err | err retry ]. > | > Gofer gofer recompile. > | > Gofer new > | > squeaksource: 'Mondrian'; > | > addPackage: 'ConfigurationOfMondrian'; > | > load. > | > (Smalltalk at: #ConfigurationOfMondrian) perform: #loadLastStable. > | > -=-=-=-=-=-=-=-=-= > | > > | > I have the same error. > | > The error comes from: > | > > | > -=-=-=-=-=-=-=-=-= > | > MetacelloMCProject>>updateProject > | > "load the latest version of the configuration package" > | > > | > | mcLoader | > | > (mcLoader := self loader) == nil > | > ifTrue: [ mcLoader := self project loaderClass on: nil ]. > | > mcLoader doingLoads: [ > | > | gofer | > | > gofer := Gofer new. > | > MCWorkingCopy > | > managersForClass: self configuration class > | > do: [:mgr | > | > gofer add: (GoferPackageReference name: mgr packageName > | > repository: mgr repositoryGroup) versionReference. > | > Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' ]. > | > gofer load ]. > | > ^true > | > -=-=-=-=-=-=-=-=-= > | > > | > Cheers, > | > Alexandre > | > > | > On 27 Dec 2009, at 17:27, Lukas Renggli wrote: > | > > | >>> After proceeding these warnings, I have a rollback: MNU > | >>> GoferPackageReference class>>name:repository: > | >> > | >> Can you evaluate > | >> > | >> [ Gofer gofer load ] > | >> on: Error > | >> do: [ :err | err retry ]. > | >> Gofer gofer recompile. > | >> > | >> ? I don't have any senders of #name:repository: to > | >> GoferPackageReference. > | >> > | >> 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 > | >> > | > > | > -- > | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | > Alexandre Bergel http://www.bergel.eu > | > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | > > | > > | > > | > > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > | -- > | www.tudorgirba.com > | > | "From an abstract enough point of view, any two things are similar." -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Dec. 27, 2009

Re: [Pharo-project] Fwd: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use))

by StÃ©phane Ducasse

Thanks David. I will look at the methodTrailer fixes soon. Now my knowledge is limited in this area and I would prefer to have marcus have a look. I will at least check the code and see if it looks ok. Stef On Dec 27, 2009, at 8:25 PM, David T. Lewis wrote: > Note, the change sets for this update are also on Mantis > http://bugs.squeak.org/view.php?id=5205 > along with discussion of other approaches to the problem. > > These changes are now in Squeak trunk. > > Dave > > On Sun, Dec 27, 2009 at 09:19:46PM +0200, Igor Stasenko wrote: >> ---------- Forwarded message ---------- >> From: David T. Lewis <lewis(a)mail.msen.com> >> Date: 2009/12/27 >> Subject: Re: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR >> (Re: CompiledMethodTrailers ready for use)) >> To: The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org> >> >> >> I have put the updates for large changes and sources files into the >> inbox. I would appreciate if someone can review this before moving >> into trunk. >> >> There are three mcz updates: >> ??Files-dtl.62 >> ??System-dtl.205 >> ??Kernel-dtl.347 >> >> Important: The changes *must* be loaded in the order listed above. >> This will require a configuration map update when the changes are >> moved to trunk. >> >> The use of ExpandedSourceFileArray takes effect after the first >> image restart. To change back to using the StandardSourceFileArray, >> the procedure is as follows: >> >> ??1) Evaluate 'StandardSourceFileArray install' >> ??2) Edit SourceFileArray class>>concreteClass to answer >> ?? ??StandardSourceFileArray rather than ExpandedSourceFileArray. >> >> Thanks, >> Dave >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

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