- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: sort: and sortBlock:

by Mariano Martinez Peck

On Wed, Dec 23, 2009 at 4:58 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > > > I started to implement OrderedSet (OrderedCollection no duplicate) > > but I think that I want probably UniqueOrdered. > > I will publish what I have done and ask for feedback and that other can > > improve. I like the idea of using the TraitsTest to have coherent sets of > > behavior. > > Oh yeah, TreeSet ftw, missed that already sometime! > > > > >> asSortedArray > > > asSortedCollection > > > asSortedCollection: > > > sortBy: > > What bugs me is that #sortBy: does not what it says. I would expect that > > aCollection sortBy: [ :each | each name ] > > does the same as > > aCollection sort: [ :a :b | a name <= b name ] > > if you want that, I can provide a fast implementation of #sortBy: > > In those cases will be cool to write first all the tests than make the things to fail and then write the code to fix them :) But ok...not everybody have that time. > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2009

Re: [Pharo-project] Fwd: All mailinglist messages on gmane are dublicated

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > I don't see them duplicated.Â only comments view is affected, eg http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/17858 --AA

Dec. 23, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > I started to implement OrderedSet (OrderedCollection no duplicate) > but I think that I want probably UniqueOrdered. > I will publish what I have done and ask for feedback and that other can > improve. I like the idea of using the TraitsTest to have coherent sets of > behavior. Oh yeah, TreeSet ftw, missed that already sometime! > > >> asSortedArray > > asSortedCollection > > asSortedCollection: > > sortBy: What bugs me is that #sortBy: does not what it says. I would expect that aCollection sortBy: [ :each | each name ] does the same as aCollection sort: [ :a :b | a name <= b name ] if you want that, I can provide a fast implementation of #sortBy: --AA

Dec. 23, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > So, it seems to HACK (it forces a fault) this MD fault recover to discover > inactive classes and other things. Ok, forget that hack for a moment. > > What questions is, what are these faults? Why a method dictionary can be in > nil ? How is this produced ? And how is it fixed? > > I saw for example this: > > Behaviour>>methodDict > methodDict == nil ifTrue: [self recoverFromMDFaultWithTrace]. > ^ methodDict > > But again...how can that be nil ??? I guess your missing link is ProtoObject >> #cannotInterpret: which is executed by the VM whenever you try to send a message to an object whose class does not have a method dictionary. Further methods that you should look at are ClassDescription >> #induceMDFault ClassDescription >> #recoverFromMDFault ClassDescription >> #recoverFromMDFaultWithTrace and their senders. Except for the call to #cannotInterpret by the VM, all the rest is done in the image (stef got that wrong) and you can go and read the code. All in all, it is a highly sophisticated (read *ugly*) hack and I'd say an evil use of superpowers. --AA

Dec. 23, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by Mariano Martinez Peck

On Wed, Dec 23, 2009 at 2:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Hi folks: I am trying to understand ImageSegment methods like > activeClasses, swapOutInactiveClasses, discoverActiveClasses among others. > One of the comments of those methods says: > > > > "NOTE: discoverActiveClasses uses Squeak's ability to detect and recover > from faults due to a nil method dictionary. It staches the method dict in > with the organization during the time when discovery is in progress (Gag me > with a spoon). This is why the faults need to be cleared promptly before > resuming normal work with the system. It is also important that classes *do > not* refer directly to their method dictionary, but only via the accessor > message." > > > > So, it seems to HACK (it forces a fault) this MD fault recover to > discover inactive classes and other things. Ok, forget that hack for a > moment. > > > > What questions is, what are these faults? Why a method dictionary can be > in nil ? How is this produced ? And how is it fixed? > > > > I saw for example this: > > > > Behaviour>>methodDict > > methodDict == nil ifTrue: [self recoverFromMDFaultWithTrace]. > > ^ methodDict > > > > > > But again...how can that be nil ??? > > VM code put it to nil. > The idea is that the methodDict is stored in the class or method cat > and nil is put in place of the methodDict. > > Then when the VM detects that the methodDict is nil then it copies the > methodDict stored into the category > This way you know which class has been used during your interaction. > > We tried to use it with mathieu but we often got all the classes back on > place. > And it crashed a lot :) > > Thanks Stef. After a discussion with Andreas in Squeak-dev mailing list, I wanted to ask you too. I could perfectly saw that when trying to discover used classes. I also saw the method ClassDescription>> induceMDFault. However, I still have this question: Forget about discovering classes, could be possible that for a certain situation the VM puts a nil to a method directory or always that happens this is done with that intention, through the message induceMDFault ? If it is always through induceMDFault the only sender is to discover used classes with ImageSegment. So...it is used ONLY in that? The possibility of using #instVarAt:put: accidentally is rejected because the recover will search the methodDict in the category (organization). So, if I just set a nil to the methodDict using #instVarAt:put: but I don't "backup" the methodDic in the category, the recover won't work. thanks Mariano ps: yes, I am thinking in clean up all this class discovery to another place than ImageSegment what I wonder if those messages for MD faults should be put off too. > Stef > > > > > Thank you very much. > > > > Marian > > > > _______________________________________________ > > 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. 23, 2009

Re: [Pharo-project] [update 1.1] #11112

by StÃ©phane Ducasse

>> > > Is there any value to you if I run the test suite on these updates on a > Linux box? Sure Here I guess that we have linux server but we did not put the server on linux yet. The vision is we should get a seed + a config -> returns a report of tests and in that context having it run on several Oses would be cool. Stef

Dec. 23, 2009

Re: [Pharo-project] Maintaining KPF (was Keeping released version image up to date (was did you...)

by StÃ©phane Ducasse

> So would: > http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect… > > Be the KPF IFF the type and status and milestone fields were maintained? I'm not sure because what I saw was more 1.1 updates. Normally we have milestone 1.0 for 1.0 milestone 1.1 for 1.1 and when an issue should be back ported it gets the two tags.

Dec. 23, 2009

Re: [Pharo-project] [update 1.1] #11112

by Stan Shepherd

StÃ©phane Ducasse wrote: > > Yes! > We remove all the updates during the release phase of 1.1 > > Stef > > On Dec 23, 2009, at 12:36 PM, Stan Shepherd wrote: > >> >> Thanks Marcus. >> >> ScriptLoader>>update11086 >> "self new update11086" >> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: >> TheWorldMainDockingBar. >> >> seems to be holding an obsolete reference to TheWorldMainDockingBar. Do >> these methods get cleaned out at some point? >> >> ...Stan >> >> >> >> >> Marcus Denker-4 wrote: >>> >>> 11112 >>> ----- >>> >>> Issue 1652: Behavior >> #allSubclassesDo: depends on #subclassesDo: >>> which >>> is defined in Class and friends only >>> Thanks, Adrian Kuhn >>> Issue 1633: Object allSubInstances appears to loop forever >>> Thanks, Eliot Miranda (from Squeak) >>> Issue 1655: MethodFinder Fixes >>> Thanks, Bert Freudenberg (from Squeak) >>> Issue 1654: SpeedUpCommandHistory >>> Thanks, Eliot Miranda (from Squeak) >>> > > Is there any value to you if I run the test suite on these updates on a Linux box? -- View this message in context: http://n2.nabble.com/update-1-1-11112-tp4207680p4209047.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 23, 2009

Re: [Pharo-project] Issue 1659: WACallSuperImplementationRule>>checkClass: on a SmalllintContext ObjectTracer causes walkback

by Lukas Renggli

> Sorry, I should have worked out that it goes on the Seaside issues list. > This needs updating on http://code.google.com/p/pharo/issues/detail?id=1659 > : still shows wontfix. No problem. > Better still, does google code support moving an issue between projects? I don't think so. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 23, 2009

Re: [Pharo-project] Maintaining KPF (was Keeping released version image up to date (was did you...)

by Stan Shepherd

StÃ©phane Ducasse wrote: > > Right now we have milestone1.0 and milestone1.1 for the fixes that are > integrated in both > But indeed we could have a specific tags. > > Stef >>> >>> >> Is it possible to add a new status in Google Code, of Closed-KPF-1.0? >> Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 >> means >> fixed only in 1.1alpha. >> Making the KPF list becomes trivial. >> And it also captures the knowledge of whether the issue applied to 1.0 at >> the time of closing, rather than someone have to puzzle over it when >> making >> a release. >> ...Stan >> > > So would: http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect… http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect… Be the KPF IFF the type and status and milestone fields were maintained? -- View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-suppor… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 23, 2009