- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Igor Stasenko

yes.. and i'd like to add that in some places i replaced senders of rect1 intersect: rect2 with: rect1 intersect: rect2 ifNone: [ self error: 'should not happen']. as it appears, it happens in some places... because of the above inconsistency. -- Best regards, Igor Stasenko.

Feb. 13, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by stephane ducasse

Nicolas what I know is that with igor we fixed all the senders of fractions:offset: and after igor introduced intersect:ifNone: to avoid generating "wrong" rectangles with negative values. I thought that intersect: was deprecated. or the precondition should be clearer. Stef On Feb 13, 2013, at 9:55 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Rectangle>>intersects: has been changed recently (GuillermoPolito 2/8/2013) > rCorner x < origin x ifTrue: [ ^ false ]. > rCorner y < origin y ifTrue: [ ^ false ]. > rOrigin x > corner x ifTrue: [ ^ false ]. > rOrigin y > corner y ifTrue: [ ^ false ]. > > these inequalities have been transformed into <= and >= > Can someone point me to the issue number documenting this change? > > Nicolas >

Feb. 13, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Igor Stasenko

On 13 February 2013 22:55, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Rectangle>>intersects: has been changed recently (GuillermoPolito 2/8/2013) > rCorner x < origin x ifTrue: [ ^ false ]. > rCorner y < origin y ifTrue: [ ^ false ]. > rOrigin x > corner x ifTrue: [ ^ false ]. > rOrigin y > corner y ifTrue: [ ^ false ]. > > these inequalities have been transformed into <= and >= > Can someone point me to the issue number documenting this change? > well, we ran into following issue: (0@0 corner: 10@0) intersects: (0@0 corner: 100@100) => false but: (0@0 corner: 10@0) intersect: (0@0 corner: 100@100) => (0@0) corner: (10@0) but: (0@0 corner: 10@0) intersect: (0@0 corner: 100@100) ifNone: [ nil ] => nil now, since i was on a crusade to replace all senders of #intersect: with #intersect:ifNone: (for a good reason ;) this inconsistency strikes us back.. So, i really wonder whether we should relax conditions in #intersects: and change tests appropriately, or keep them as before.. but then how to deal with the above? > Nicolas -- Best regards, Igor Stasenko.

Feb. 13, 2013

Re: [Pharo-project] [Vm-dev] Fwd: A question about lookup and message reification

by StÃ©phane Ducasse

Hi eliot > I repost the mail to the mailing-list since I do not see it in the vm-dev > > did you post to vm-dev? yes but since I'm travelling may be the mail was lost or I could not see appearing because one of my rules pushed it somewhere. I changed machines and I have to get used to 10.8. My mail now decide to use the wrong account :( >> >> Hi >> >> I was reading the following method in the VM code and I have a couple of questions: >> >> - I do not understand why lookupMethodInClass: may return a class. I was thinking that it would return a method. > > > It doesn't matter what it returns as it's return value is always ignored. Ok I will read again the code. reading Slang is still nicer than plain generated C :) > It assigns to newMethod. I suspect it returns currentClass because a) the return type was always sqInt because Slang didn't support void functions, and b) currentClass is a value in hand so probably in a register and hence cheap to return. Ok I was looking for an example to show a real lookup for the students that are implementing ObjVlisp Now I will see if I show them this method. >> - what is the invariant? >> that currentclass always point to the currently looked up class and >> newMethod is the found method? > > > The input arguments are messageSelector, argumentCount and its argument, class. The VM suffers somewhat from being cluttered with global variables, which is I think a legacy of the blue-book specification (the Smalltalk code that was used to implement Interpreter in VMMaker) being derived from the Alto and Dorado implementations in microcode. It would be nicer if there were fewer variables, but e.g. supplying argumentCount as a parameter throughout all the message handling routines can be difficult, especially when things like perform: and MNU change the argumentCount during message send. I clearly see what you mean. > >> - why lookupMethodFor: selector InDictionary: dictionary is defined in StackInterpreter but never used >> only in CoInterpreter? > > > Well, it belongs in StackInterpreter and could be used in the other lookup methods. I was probably considering rewriting the other lookup routines to use lookupMethodFor: InDictionary: but didn't get round to it. ok I see. While reading directly the see code I was wondering why you generate the ifdef for different bytecode set? Is it that you would have to call another object and that it would not have the same instance variables. Because I was thinking that such variation points could be handled by the different interpreter subclasses. >> >> Thanks >> >> >> lookupMethodInClass: class >> | currentClass dictionary found | >> <inline: false> >> self assert: class ~= objectMemory nilObject. >> currentClass := class. >> [currentClass ~= objectMemory nilObject] >> whileTrue: >> [dictionary := objectMemory fetchPointer: MethodDictionaryIndex ofObject: currentClass. >> >> *** trick with the cannotInterpret *** >> dictionary = objectMemory nilObject ifTrue: >> ["MethodDict pointer is nil (hopefully due a swapped out stub) >> -- raise exception #cannotInterpret:." >> self createActualMessageTo: class. >> messageSelector := objectMemory splObj: SelectorCannotInterpret. >> self sendBreak: messageSelector + BaseHeaderSize >> point: (objectMemory lengthOf: messageSelector) >> receiver: nil. >> ^self lookupMethodInClass: (self superclassOf: currentClass)]. >> *** trick with the cannotInterpret end *** >> >> found := self lookupMethodInDictionary: dictionary. >> found ifTrue: [^currentClass]. >> ^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> currentClass := self superclassOf: currentClass]. >> >> "Could not find #doesNotUnderstand: -- unrecoverable error." >> messageSelector = (objectMemory splObj: SelectorDoesNotUnderstand) ifTrue: >> [self error: 'Recursive not understood error encountered']. >> >> "Cound not find a normal message -- raise exception #doesNotUnderstand:" >> self createActualMessageTo: class. >> messageSelector := objectMemory splObj: SelectorDoesNotUnderstand. >> self sendBreak: messageSelector + BaseHeaderSize >> point: (objectMemory lengthOf: messageSelector) >> receiver: nil. >> ^self lookupMethodInClass: class >> >> >> if (found) { >> return currentClass; >> } >> >> >> static sqInt >> lookupMethodInClass(sqInt class) >> { >> // StackInterpreter>>#lookupMethodInClass: DECL_MAYBE_SQ_GLOBAL_STRUCT >> sqInt currentClass; >> sqInt dictionary; >> sqInt found; >> sqInt header; >> sqInt index; >> sqInt length; >> sqInt mask; >> sqInt methodArray; >> sqInt nextSelector; >> sqInt sz; >> sqInt wrapAround; >> >> assert(class != (nilObject())); >> currentClass = class; >> while (currentClass != GIV(nilObj)) { >> dictionary = longAt((currentClass + BaseHeaderSize) + (MethodDictionaryIndex << ShiftForWord)); >> if (dictionary == GIV(nilObj)) { >> >> /* ifTrue: */ >> >> createActualMessageTo(class); >> GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (SelectorCannotInterpret << ShiftForWord)); >> sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize, lengthOf(GIV(messageSelector)), null); >> return lookupMethodInClass(longAt((currentClass + BaseHeaderSize) + (SuperclassIndex << ShiftForWord))); >> } >> /* begin lookupMethodInDictionary: */ >> /* begin fetchWordLengthOf: */ >> /* begin sizeBitsOf: */ >> header = longAt(dictionary); >> sz = ((header & TypeMask) == HeaderTypeSizeAndClass >> ? (longAt(dictionary - (BytesPerWord * 2))) & LongSizeMask >> : header & SizeMask); >> length = ((usqInt) (sz - BaseHeaderSize)) >> ShiftForWord; >> mask = (length - SelectorStart) - 1; >> >> /* messageSelector */ >> >> index = SelectorStart + (mask & (((GIV(messageSelector) & 1) >> ? (GIV(messageSelector) >> 1) >> : (((usqInt) (longAt(GIV(messageSelector)))) >> HashBitsOffset) & HashMaskUnshifted))); >> wrapAround = 0; >> while (1) { >> nextSelector = longAt((dictionary + BaseHeaderSize) + (index << ShiftForWord)); >> if (nextSelector == GIV(nilObj)) { >> found = 0; >> goto l1; >> } >> if (nextSelector == GIV(messageSelector)) { >> methodArray = longAt((dictionary + BaseHeaderSize) + (MethodArrayIndex << ShiftForWord)); >> GIV(newMethod) = longAt((methodArray + BaseHeaderSize) + ((index - SelectorStart) << ShiftForWord)); >> found = 1; >> goto l1; >> } >> index += 1; >> if (index == length) { >> if (wrapAround) { >> found = 0; >> goto l1; >> } >> wrapAround = 1; >> index = SelectorStart; >> } >> } >> found = 0; >> l1: /* end lookupMethodInDictionary: */; >> if (found) { >> return currentClass; >> } >> currentClass = longAt((currentClass + BaseHeaderSize) + (SuperclassIndex << ShiftForWord)); >> } >> if (GIV(messageSelector) == (longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (SelectorDoesNotUnderstand << ShiftForWord)))) { >> error("Recursive not understood error encountered"); >> } >> createActualMessageTo(class); >> GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (SelectorDoesNotUnderstand << ShiftForWord)); >> sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize, lengthOf(GIV(messageSelector)), null); >> return lookupMethodInClass(class); >> } >> >> >> >> > > > > > -- > best, > Eliot

Feb. 13, 2013

[Pharo-project] Rectangle>>intersects: change Rationale

by Nicolas Cellier

Rectangle>>intersects: has been changed recently (GuillermoPolito 2/8/2013) rCorner x < origin x ifTrue: [ ^ false ]. rCorner y < origin y ifTrue: [ ^ false ]. rOrigin x > corner x ifTrue: [ ^ false ]. rOrigin y > corner y ifTrue: [ ^ false ]. these inequalities have been transformed into <= and >= Can someone point me to the issue number documenting this change? Nicolas

Feb. 13, 2013

Re: [Pharo-project] Fwd: A question about lookup and message reification

by Eliot Miranda

On Wed, Feb 13, 2013 at 12:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Stef, > > On Wed, Feb 13, 2013 at 11:40 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> I repost the mail to the mailing-list since I do not see it in the vm-dev >> > > did you post to vm-dev? > > >> >> Stef >> >> >> Hi >> >> I was reading the following method in the VM code and I have a couple of >> questions: >> >> - I do not understand why lookupMethodInClass: may return a class. I was >> thinking that it would return a method. >> >> > It doesn't matter what it returns as it's return value is always ignored. > It assigns to newMethod. I suspect it returns currentClass because a) the > return type was always sqInt because Slang didn't support void functions, > and b) currentClass is a value in hand so probably in a register and hence > cheap to return. > > >> - what is the invariant? >> that currentclass always point to the currently looked up class and >> newMethod is the found method? >> >> > The input arguments are messageSelector, argumentCount and its argument, > class. The VM suffers somewhat from being cluttered with global variables, > which is I think a legacy of the blue-book specification (the Smalltalk > code that was used to implement Interpreter in VMMaker) being derived from > the Alto and Dorado implementations in microcode. It would be nicer if > there were fewer variables, but e.g. supplying argumentCount as a parameter > throughout all the message handling routines can be difficult, especially > when things like perform: and MNU change the argumentCount during message > send. > and so argumentCount must be the number of objects on the stack minus one, messageSelector must be an object (any object). The argument "class" must be a behavior-like object that is on a list of behavior-like objects linked through the superclass field that terminates with nil. Each object on the chain must have either nil or a method dictionary-like object in its method dictionary. > - why lookupMethodFor: selector InDictionary: dictionary is defined in >> StackInterpreter but never used >> only in CoInterpreter? >> >> > Well, it belongs in StackInterpreter and could be used in the other lookup > methods. I was probably considering rewriting the other lookup routines to > use lookupMethodFor: InDictionary: but didn't get round to it. > > >> Thanks >> >> >> lookupMethodInClass: class >> | currentClass dictionary found | >> <inline: false> >> self assert: class ~= objectMemory nilObject. >> currentClass := class. >> [currentClass ~= objectMemory nilObject] >> whileTrue: >> [dictionary := objectMemory fetchPointer: MethodDictionaryIndex ofObject: >> currentClass. >> >> *** trick with the cannotInterpret *** >> dictionary = objectMemory nilObject ifTrue: >> ["MethodDict pointer is nil (hopefully due a swapped out stub) >> -- raise exception #cannotInterpret:." >> self createActualMessageTo: class. >> messageSelector := objectMemory splObj: SelectorCannotInterpret. >> self sendBreak: messageSelector + BaseHeaderSize >> point: (objectMemory lengthOf: messageSelector) >> receiver: nil. >> ^self lookupMethodInClass: (self superclassOf: currentClass)]. >> *** trick with the cannotInterpret end *** >> >> found := self lookupMethodInDictionary: dictionary. >> found ifTrue: [^currentClass]. >> ^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> currentClass := self superclassOf: currentClass]. >> >> "Could not find #doesNotUnderstand: -- unrecoverable error." >> messageSelector = (objectMemory splObj: SelectorDoesNotUnderstand) >> ifTrue: >> [self error: 'Recursive not understood error encountered']. >> >> "Cound not find a normal message -- raise exception #doesNotUnderstand:" >> self createActualMessageTo: class. >> messageSelector := objectMemory splObj: SelectorDoesNotUnderstand. >> self sendBreak: messageSelector + BaseHeaderSize >> point: (objectMemory lengthOf: messageSelector) >> receiver: nil. >> ^self lookupMethodInClass: class >> >> >> if (found) { >> return currentClass; >> } >> >> >> static sqInt >> lookupMethodInClass(sqInt class) >> { >> // StackInterpreter>>#lookupMethodInClass: DECL_MAYBE_SQ_GLOBAL_STRUCT >> sqInt currentClass; >> sqInt dictionary; >> sqInt found; >> sqInt header; >> sqInt index; >> sqInt length; >> sqInt mask; >> sqInt methodArray; >> sqInt nextSelector; >> sqInt sz; >> sqInt wrapAround; >> >> assert(class != (nilObject())); >> currentClass = class; >> while (currentClass != GIV(nilObj)) { >> dictionary = longAt((currentClass + BaseHeaderSize) + >> (MethodDictionaryIndex << ShiftForWord)); >> if (dictionary == GIV(nilObj)) { >> >> /* ifTrue: */ >> >> createActualMessageTo(class); >> GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + >> (SelectorCannotInterpret << ShiftForWord)); >> sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize, >> lengthOf(GIV(messageSelector)), null); >> return lookupMethodInClass(longAt((currentClass + BaseHeaderSize) + >> (SuperclassIndex << ShiftForWord))); >> } >> /* begin lookupMethodInDictionary: */ >> /* begin fetchWordLengthOf: */ >> /* begin sizeBitsOf: */ >> header = longAt(dictionary); >> sz = ((header & TypeMask) == HeaderTypeSizeAndClass >> ? (longAt(dictionary - (BytesPerWord * 2))) & LongSizeMask >> : header & SizeMask); >> length = ((usqInt) (sz - BaseHeaderSize)) >> ShiftForWord; >> mask = (length - SelectorStart) - 1; >> >> /* messageSelector */ >> >> index = SelectorStart + (mask & (((GIV(messageSelector) & 1) >> ? (GIV(messageSelector) >> 1) >> : (((usqInt) (longAt(GIV(messageSelector)))) >> HashBitsOffset) & >> HashMaskUnshifted))); >> wrapAround = 0; >> while (1) { >> nextSelector = longAt((dictionary + BaseHeaderSize) + (index << >> ShiftForWord)); >> if (nextSelector == GIV(nilObj)) { >> found = 0; >> goto l1; >> } >> if (nextSelector == GIV(messageSelector)) { >> methodArray = longAt((dictionary + BaseHeaderSize) + (MethodArrayIndex << >> ShiftForWord)); >> GIV(newMethod) = longAt((methodArray + BaseHeaderSize) + ((index - >> SelectorStart) << ShiftForWord)); >> found = 1; >> goto l1; >> } >> index += 1; >> if (index == length) { >> if (wrapAround) { >> found = 0; >> goto l1; >> } >> wrapAround = 1; >> index = SelectorStart; >> } >> } >> found = 0; >> l1: /* end lookupMethodInDictionary: */; >> if (found) { >> return currentClass; >> } >> currentClass = longAt((currentClass + BaseHeaderSize) + (SuperclassIndex >> << ShiftForWord)); >> } >> if (GIV(messageSelector) == (longAt((GIV(specialObjectsOop) + >> BaseHeaderSize) + (SelectorDoesNotUnderstand << ShiftForWord)))) { >> error("Recursive not understood error encountered"); >> } >> createActualMessageTo(class); >> GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) >> + (SelectorDoesNotUnderstand << ShiftForWord)); >> sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize, >> lengthOf(GIV(messageSelector)), null); >> return lookupMethodInClass(class); >> } >> >> >> >> >> >> > > > -- > best, > Eliot > -- best, Eliot

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Camillo Bruni

On 2013-02-13, at 21:04, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > How can I test that? > > Really it feels sluggish when scrolling lists, that is wrong, taking the latest 1.4 and the latest 2.0 there is a massive visual difference in scrolling speed on a huge list. I looked for senders of #name with 1583 items in 2.0 and 1408 in 1.4. Taking the scroll-thumb on the right, in 2.0 the list scrolls smoothly whereas in 1.4 it jumps. which version where you comparing? > autocomplete with Spotlight etc. Didn't have that with my 1.4. What did you run here? Actually Spotlight could run slower ;) but I doubt that as well > I am using a Mac with a Core2Duo CPU. RAM is of no concern (8GB). > > Phil > > 2013/2/13 stephane ducasse <stephane.ducasse(a)free.fr>: >> >> On Feb 13, 2013, at 6:39 PM, phil(a)highoctane.be wrote: >> >>> Don't know if this is related but the 2.0 image seems to runs slower >>> on my box (20543 now). >> >> this is strange because people told me exactly the inverse yesterday (comparing to 1.4). >> So this is difficult to assess. >> >> Stef >> >>> >>> Also a question: why is there a ZnServer in the StartUpList ? I saw >>> discussions on the loading of .changes if there is none in the image >>> folder. >>> >>> Phil >>> >>> 2013/2/13 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>> On 13 Feb 2013, at 18:17, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Is this related to that large list of [delaySemaphore wait] in >>>>> Delay>>wait that I do see in the Process Browser? This thing wasn't so >>>>> large in the past. >>>> >>>> Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image. >>>> >>>>> Phil >>>>> >>>>> 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> My personal take about this issue: >>>>>> >>>>>> - when image starting up, all Delays should be reset by unblocking all >>>>>> waiting processes (regardless how much extra time there left to be >>>>>> waiting). >>>>>> >>>>>> Because, to my opinion, a code which uses delays to cross session >>>>>> boundaries will fail badly anyways, >>>>>> so imo it is better to have delays unblocked the process prematurely, >>>>>> rather than blocking it for next 2^30 milliseconds (or any random big >>>>>> number around that). >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>> >>>> >>> >> >> >

Feb. 13, 2013

Re: [Pharo-project] OSProcess and CommandShell in Pharo 2.0

by David T. Lewis

Thanks a lot Sean! Dave On Wed, Feb 13, 2013 at 07:16:25AM -0800, Sean P. DeNigris wrote: > I think we have it now: > - ConfigurationOfOSProcess and ConfigurationOfCommandShell have been updated > to work in 1.4 and 2.0 > - Each config has been copied to its project repo (e.g. sqs/CommandShell). I > was starting to get confused with all the locations > (sqs/MetacelloRepository, xyz/MetaRepoForAbc, etc). I think it's a more sane > model to keep the configs with the project and then mirror them as > necessary. Metacello was designed to manage dialect dependencies, so there > should be no need to fork a ConfigurationOfXyz. The only issue we have is > when we don't have access to the project's repo, for which it'd be great if > we implement per-project inboxes ( maybe in StHub, hint, hint ;) ) > > Anyway, thanks to David and Steph for all the hard work getting this > working. OSP and CommandShell are vitally important projects and it's great > to know that they will continue working well in Pharo for the foreseeable > future :) > > > > -- > View this message in context: http://forum.world.st/OSProcess-and-CommandShell-in-Pharo-2-0-tp4669674.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2013

Re: [Pharo-project] Fwd: A question about lookup and message reification

by Eliot Miranda

Hi Stef, On Wed, Feb 13, 2013 at 11:40 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I repost the mail to the mailing-list since I do not see it in the vm-dev > did you post to vm-dev? > > Stef > > > Hi > > I was reading the following method in the VM code and I have a couple of > questions: > > - I do not understand why lookupMethodInClass: may return a class. I was > thinking that it would return a method. > > It doesn't matter what it returns as it's return value is always ignored. It assigns to newMethod. I suspect it returns currentClass because a) the return type was always sqInt because Slang didn't support void functions, and b) currentClass is a value in hand so probably in a register and hence cheap to return. > - what is the invariant? > that currentclass always point to the currently looked up class and > newMethod is the found method? > > The input arguments are messageSelector, argumentCount and its argument, class. The VM suffers somewhat from being cluttered with global variables, which is I think a legacy of the blue-book specification (the Smalltalk code that was used to implement Interpreter in VMMaker) being derived from the Alto and Dorado implementations in microcode. It would be nicer if there were fewer variables, but e.g. supplying argumentCount as a parameter throughout all the message handling routines can be difficult, especially when things like perform: and MNU change the argumentCount during message send. - why lookupMethodFor: selector InDictionary: dictionary is defined in > StackInterpreter but never used > only in CoInterpreter? > > Well, it belongs in StackInterpreter and could be used in the other lookup methods. I was probably considering rewriting the other lookup routines to use lookupMethodFor: InDictionary: but didn't get round to it. > Thanks > > > lookupMethodInClass: class > | currentClass dictionary found | > <inline: false> > self assert: class ~= objectMemory nilObject. > currentClass := class. > [currentClass ~= objectMemory nilObject] > whileTrue: > [dictionary := objectMemory fetchPointer: MethodDictionaryIndex ofObject: > currentClass. > > *** trick with the cannotInterpret *** > dictionary = objectMemory nilObject ifTrue: > ["MethodDict pointer is nil (hopefully due a swapped out stub) > -- raise exception #cannotInterpret:." > self createActualMessageTo: class. > messageSelector := objectMemory splObj: SelectorCannotInterpret. > self sendBreak: messageSelector + BaseHeaderSize > point: (objectMemory lengthOf: messageSelector) > receiver: nil. > ^self lookupMethodInClass: (self superclassOf: currentClass)]. > *** trick with the cannotInterpret end *** > > found := self lookupMethodInDictionary: dictionary. > found ifTrue: [^currentClass]. > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > currentClass := self superclassOf: currentClass]. > > "Could not find #doesNotUnderstand: -- unrecoverable error." > messageSelector = (objectMemory splObj: SelectorDoesNotUnderstand) ifTrue: > [self error: 'Recursive not understood error encountered']. > > "Cound not find a normal message -- raise exception #doesNotUnderstand:" > self createActualMessageTo: class. > messageSelector := objectMemory splObj: SelectorDoesNotUnderstand. > self sendBreak: messageSelector + BaseHeaderSize > point: (objectMemory lengthOf: messageSelector) > receiver: nil. > ^self lookupMethodInClass: class > > > if (found) { > return currentClass; > } > > > static sqInt > lookupMethodInClass(sqInt class) > { > // StackInterpreter>>#lookupMethodInClass: DECL_MAYBE_SQ_GLOBAL_STRUCT > sqInt currentClass; > sqInt dictionary; > sqInt found; > sqInt header; > sqInt index; > sqInt length; > sqInt mask; > sqInt methodArray; > sqInt nextSelector; > sqInt sz; > sqInt wrapAround; > > assert(class != (nilObject())); > currentClass = class; > while (currentClass != GIV(nilObj)) { > dictionary = longAt((currentClass + BaseHeaderSize) + > (MethodDictionaryIndex << ShiftForWord)); > if (dictionary == GIV(nilObj)) { > > /* ifTrue: */ > > createActualMessageTo(class); > GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + > (SelectorCannotInterpret << ShiftForWord)); > sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize, > lengthOf(GIV(messageSelector)), null); > return lookupMethodInClass(longAt((currentClass + BaseHeaderSize) + > (SuperclassIndex << ShiftForWord))); > } > /* begin lookupMethodInDictionary: */ > /* begin fetchWordLengthOf: */ > /* begin sizeBitsOf: */ > header = longAt(dictionary); > sz = ((header & TypeMask) == HeaderTypeSizeAndClass > ? (longAt(dictionary - (BytesPerWord * 2))) & LongSizeMask > : header & SizeMask); > length = ((usqInt) (sz - BaseHeaderSize)) >> ShiftForWord; > mask = (length - SelectorStart) - 1; > > /* messageSelector */ > > index = SelectorStart + (mask & (((GIV(messageSelector) & 1) > ? (GIV(messageSelector) >> 1) > : (((usqInt) (longAt(GIV(messageSelector)))) >> HashBitsOffset) & > HashMaskUnshifted))); > wrapAround = 0; > while (1) { > nextSelector = longAt((dictionary + BaseHeaderSize) + (index << > ShiftForWord)); > if (nextSelector == GIV(nilObj)) { > found = 0; > goto l1; > } > if (nextSelector == GIV(messageSelector)) { > methodArray = longAt((dictionary + BaseHeaderSize) + (MethodArrayIndex << > ShiftForWord)); > GIV(newMethod) = longAt((methodArray + BaseHeaderSize) + ((index - > SelectorStart) << ShiftForWord)); > found = 1; > goto l1; > } > index += 1; > if (index == length) { > if (wrapAround) { > found = 0; > goto l1; > } > wrapAround = 1; > index = SelectorStart; > } > } > found = 0; > l1: /* end lookupMethodInDictionary: */; > if (found) { > return currentClass; > } > currentClass = longAt((currentClass + BaseHeaderSize) + (SuperclassIndex > << ShiftForWord)); > } > if (GIV(messageSelector) == (longAt((GIV(specialObjectsOop) + > BaseHeaderSize) + (SelectorDoesNotUnderstand << ShiftForWord)))) { > error("Recursive not understood error encountered"); > } > createActualMessageTo(class); > GIV(messageSelector) = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + > (SelectorDoesNotUnderstand << ShiftForWord)); > sendBreakpointreceiver(GIV(messageSelector) + BaseHeaderSize, > lengthOf(GIV(messageSelector)), null); > return lookupMethodInClass(class); > } > > > > > > -- best, Eliot

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by phil＠highoctane.be

How can I test that? Really it feels sluggish when scrolling lists, autocomplete with Spotlight etc. Didn't have that with my 1.4. I am using a Mac with a Core2Duo CPU. RAM is of no concern (8GB). Phil 2013/2/13 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Feb 13, 2013, at 6:39 PM, phil(a)highoctane.be wrote: > >> Don't know if this is related but the 2.0 image seems to runs slower >> on my box (20543 now). > > this is strange because people told me exactly the inverse yesterday (comparing to 1.4). > So this is difficult to assess. > > Stef > >> >> Also a question: why is there a ZnServer in the StartUpList ? I saw >> discussions on the loading of .changes if there is none in the image >> folder. >> >> Phil >> >> 2013/2/13 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> On 13 Feb 2013, at 18:17, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Is this related to that large list of [delaySemaphore wait] in >>>> Delay>>wait that I do see in the Process Browser? This thing wasn't so >>>> large in the past. >>> >>> Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image. >>> >>>> Phil >>>> >>>> 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: >>>>> My personal take about this issue: >>>>> >>>>> - when image starting up, all Delays should be reset by unblocking all >>>>> waiting processes (regardless how much extra time there left to be >>>>> waiting). >>>>> >>>>> Because, to my opinion, a code which uses delays to cross session >>>>> boundaries will fail badly anyways, >>>>> so imo it is better to have delays unblocked the process prematurely, >>>>> rather than blocking it for next 2^30 milliseconds (or any random big >>>>> number around that). >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>> >>> >> > >

Feb. 13, 2013