November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3288 in pharo: OB does not work with editor changes

by pharo＠googlecode.com

Comment #1 on issue 3288 by renggli: OB does not work with editor changes http://code.google.com/p/pharo/issues/detail?id=3288 I don't know, probably. I will fix it as soon as the beta is out.

Nov. 30, 2010

[Pharo-project] Issue 3364 in pharo: Behavior implements #addTraitSelector:withMethod: identically to the version it would obtain from one of its traits

by pharo＠googlecode.com

Status: Verified Owner: adrian.lienhard Labels: Milestone-1.2 New issue 3364 by adrian.lienhard: Behavior implements #addTraitSelector:withMethod: identically to the version it would obtain from one of its traits http://code.google.com/p/pharo/issues/detail?id=3364 The changeset just removes this method: Behavior removeSelector: #addTraitSelector:withMethod: Attachments: RemoveDuplicatedMethodFromTrait.1.cs 154 bytes

Nov. 30, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Igor Stasenko

On 30 November 2010 14:53, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, Nov 30, 2010 at 12:52 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> On Tue, 30 Nov 2010, Mariano Martinez Peck wrote: >> >>> On Sun, Nov 21, 2010 at 5:31 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> Obviously you can't having a single object representation (a tagged >>>> machine word with lowest bit set) >>>> and have two different classes for it. >>>> >>>> >>> Yes, that's true. The thing is that I have a big problem using >>> SmallInteger >>> as proxies....So far I always used a subclass of ProtoObject for the >>> proxies. This is cool because most of the messages are not understood by >>> ProtoObject, thus I can intercept most messages. Now, the problem using >>> SmallInteger as proxies is that there are several methods that ARE >>> understood by both. This is a big problem because the original >>> CompiledMethod is not installed, and the method answers but with a >>> different >>> value. >>> >>> For example, suppose I do something like this: >>> >>> MyClass methodDict at: #foo put: 5. >>> (MyClass >> #foo) size >>> >>> In this case, I would like that size is NOT understood by the proxy and >>> that >>> loads back the original compiled method. But this is not the case since >>> SmallIngeger DOES understand the message #size. Thus, it answers...and >>> something different than the size of the compiled method... >> >> >> That's why you should change MethodDictionary >> #at:ifAbsent: to load the >> CompiledMethod and return that instead of the integer. >> > > Uffff sorry Levente. You are totally right. I forgot we already discussed > this... > Even more, now I checked my MethodDictionary #at:ifAbsent:Â and I have: > > > at: key ifAbsent: aBlock > > Â Â Â | index value | > Â Â Â index := self findElementOrNil: key. > Â Â Â (self basicAt: index) == nil ifTrue: [ ^ aBlock value ]. > Â Â Â value := array at: index. > Â Â Â "(value isProxy) ifTrue: [value mareaUninstall]." > Â Â Â ^ array at: index > .. and then you need to change #do: , #associationsDo: etc etc.. > > notice the comment ;) > > Thanks!!! > > Mariano > > >> >> Levente >> >>> >>> So in summary I have problems with all methods that are understood by >>> both, >>> even all those in Object I think... >>> >>> Best regards, >>> >>> Mariano >>> >>> >>> >>>> On 21 November 2010 16:51, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> wrote: >>>>> >>>>> >>>>> On Sun, Nov 21, 2010 at 12:13 AM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>>> >>>>>> On Sat, 20 Nov 2010, Mariano Martinez Peck wrote: >>>>>> >>>>>>> On Sat, Nov 20, 2010 at 5:41 PM, Levente Uzonyi <leves(a)elte.hu> >>>>>>> wrote: >>>>>>>> >>>>>>>> The only problem is that you can't swap-out a method that's used by >>>> >>>> the >>>>>>>> >>>>>>>> swap-in code. >>>>>>>> >>>>>>>> >>>>>>> Yes, but that's easy to solve. Before swapping everything, I >>>>>>> "simulate" >>>>>>> the >>>>>>> swapping of a dummy CompiledMethod. During that, I mark all the >>>>>>> CompiledMethods that were used to perform that. And then, I exclude >>>> >>>> those >>>>>>> >>>>>>> objects from being swapped :) >>>>>> >>>>>> That won't work, because during the simulation you'll only try a >>>>>> single >>>>>> execution path. Swapping in a real method may invoke methods that >>>> >>>> weren't >>>>>> >>>>>> used during the simulation. For example my implementation uses >>>> >>>> #storeString >>>>>> >>>>>> to serialize the methods and Compiler >> #evaluate: to deserialize >>>>>> them. >>>> >>>> So >>>>>> >>>>>> during deserialization a lot of different methods may be invoked. >>>>> >>>>> Ahhh I got it.... >>>>> >>>>> Are you using Cog? Â because with the SmallInteger I have the problem I >>>>> described with #run:with:in: >>>>> >>>>> Last question....to use SmallIntegers, I need to put some methods in >>>>> SmallInteger, like #run:with:in: Â , #doesNotUnderstand: , Â and all the >>>>> methods related to writing and loading back the original >>>>> compiledMethod. >>>> >>>> Of >>>>> >>>>> course I can put all those methods under a category Â *MyProxyPackage >>>>> Â ... >>>>> but I was thinking if there is another way. I would love to have >>>>> MySmallIntegerProxy that extends from ProtoObject (because I want my >>>> >>>> proxy >>>>> >>>>> to understand as less messages as possible) and that is threated by the >>>> >>>> VM >>>>> >>>>> like a SmallInetger, I mean, that it directly stores the number value >>>>> in >>>> >>>> the >>>>> >>>>> address, and put the last bit in 1. >>>>> >>>>> Is this possible? how much work can it be? >>>>> >>>>> Thanks in advance, >>>>> >>>>> Mariano >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>> >> > > -- Best regards, Igor Stasenko AKA sig.

Nov. 30, 2010

Re: [Pharo-project] [Vm-dev] Problem with #garbageCollect and -memory parameter

by David T. Lewis

Hi, I'm away and cannot check this right now, but if you look in the SqS/VMMaker archive there there are a number of recent updates that may address this problem. See the Montecello update comments for VMMaker-dtl.188, VMMaker-dtl.199, and VMMaker-dtl.200 for summaries. These updates would not be in any of the released VMs at this point, but I have a hunch that they will take care of this problem. Dave On Tue, Nov 30, 2010 at 02:43:50PM +0100, Mariano Martinez Peck wrote: > > Hi folks. I am using the standard SqueakVM 4.2.5beta1U. > If I run normaly the VM with a normal Pharo image and I print Smalltalk > garbageCollect -> I get something like 492130460 > > Now...if I run the vm with the parameter -memory 1500m and I then print > Smalltalk garbageCollect -> I get a NEGATIVE number like: -619402660 > > I guess there is a problem in somewhere like ObjectMemory >> bytesLeft: > but I don't know... > > Anyway, the problem in my case is in SmalltalkImage: > > okayToProceedEvenIfSpaceIsLow > "Return true if either there is enough memory to do so safely or if the > user gives permission after being given fair warning." > > self garbageCollectMost > self lowSpaceThreshold ifTrue: [^ true]. > "quick" > self garbageCollect > self lowSpaceThreshold ifTrue: [^ true]. "work > harder" > > ^ self confirm: > 'WARNING: There is not enough space to start the low space watcher. > If you proceed, you will not be warned again, and the system may > run out of memory and crash. If you do proceed, you can start the > low space notifier when more space becomes available simply by > opening and then closing a debugger (e.g., by hitting Cmd-period.) > Do you want to proceed?' > > > Since both of the first answers false because, of course garbageCollectMost > and garbageCollect are negative.... > then I have that poup all the time. > > To fix this I have to posibilities: > > 1) Just patch this particular method to: > > self garbageCollectMost. > self primBytesLeft > self lowSpaceThreshold ifTrue: [^ true]. "quick" > self garbageCollect > self primBytesLeft > self lowSpaceThreshold ifTrue: [^ true]. "work harder" > > Notice that primBytesLeft is answering correct. Wait..I don't know if > correct, but at least possitive: 5691396 > I think this is possitive because the primitive is not receiving a > parameter, and thus, Interpreter >> primitiveBytesLeft > evaluates the first part of the method, which just does self sizeOfFree: > freeBlock , and not the second part where it does self bytesLeft: aBool. > > 2) understand why it is negative and fix it from the VM side (I have no idea > how to do this). > > Now, in addition, I wonder if there may be other places broken because of > this....I am having some crashed and I don't know why :( > > Thanks in advance, > > Mariano

Nov. 30, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Mariano Martinez Peck

On Tue, Nov 30, 2010 at 12:52 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 30 Nov 2010, Mariano Martinez Peck wrote: > > On Sun, Nov 21, 2010 at 5:31 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> Obviously you can't having a single object representation (a tagged >>> machine word with lowest bit set) >>> and have two different classes for it. >>> >>> >>> Yes, that's true. The thing is that I have a big problem using >> SmallInteger >> as proxies....So far I always used a subclass of ProtoObject for the >> proxies. This is cool because most of the messages are not understood by >> ProtoObject, thus I can intercept most messages. Now, the problem using >> SmallInteger as proxies is that there are several methods that ARE >> understood by both. This is a big problem because the original >> CompiledMethod is not installed, and the method answers but with a >> different >> value. >> >> For example, suppose I do something like this: >> >> MyClass methodDict at: #foo put: 5. >> (MyClass >> #foo) size >> >> In this case, I would like that size is NOT understood by the proxy and >> that >> loads back the original compiled method. But this is not the case since >> SmallIngeger DOES understand the message #size. Thus, it answers...and >> something different than the size of the compiled method... >> > > > That's why you should change MethodDictionary >> #at:ifAbsent: to load the > CompiledMethod and return that instead of the integer. > > Uffff sorry Levente. You are totally right. I forgot we already discussed this... Even more, now I checked my MethodDictionary #at:ifAbsent: and I have: at: key ifAbsent: aBlock | index value | index := self findElementOrNil: key. (self basicAt: index) == nil ifTrue: [ ^ aBlock value ]. value := array at: index. "(value isProxy) ifTrue: [value mareaUninstall]." ^ array at: index notice the comment ;) Thanks!!! Mariano > > Levente > > > >> So in summary I have problems with all methods that are understood by >> both, >> even all those in Object I think... >> >> Best regards, >> >> Mariano >> >> >> >> On 21 November 2010 16:51, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Sun, Nov 21, 2010 at 12:13 AM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>>> >>>>> On Sat, 20 Nov 2010, Mariano Martinez Peck wrote: >>>>> >>>>> On Sat, Nov 20, 2010 at 5:41 PM, Levente Uzonyi <leves(a)elte.hu> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> The only problem is that you can't swap-out a method that's used by >>>>>>> >>>>>> the >>> >>>> swap-in code. >>>>>>> >>>>>>> >>>>>>> Yes, but that's easy to solve. Before swapping everything, I >>>>>> "simulate" >>>>>> the >>>>>> swapping of a dummy CompiledMethod. During that, I mark all the >>>>>> CompiledMethods that were used to perform that. And then, I exclude >>>>>> >>>>> those >>> >>>> objects from being swapped :) >>>>>> >>>>> >>>>> That won't work, because during the simulation you'll only try a single >>>>> execution path. Swapping in a real method may invoke methods that >>>>> >>>> weren't >>> >>>> used during the simulation. For example my implementation uses >>>>> >>>> #storeString >>> >>>> to serialize the methods and Compiler >> #evaluate: to deserialize them. >>>>> >>>> So >>> >>>> during deserialization a lot of different methods may be invoked. >>>>> >>>> >>>> Ahhh I got it.... >>>> >>>> Are you using Cog? because with the SmallInteger I have the problem I >>>> described with #run:with:in: >>>> >>>> Last question....to use SmallIntegers, I need to put some methods in >>>> SmallInteger, like #run:with:in: , #doesNotUnderstand: , and all the >>>> methods related to writing and loading back the original compiledMethod. >>>> >>> Of >>> >>>> course I can put all those methods under a category *MyProxyPackage >>>> ... >>>> but I was thinking if there is another way. I would love to have >>>> MySmallIntegerProxy that extends from ProtoObject (because I want my >>>> >>> proxy >>> >>>> to understand as less messages as possible) and that is threated by the >>>> >>> VM >>> >>>> like a SmallInetger, I mean, that it directly stores the number value in >>>> >>> the >>> >>>> address, and put the last bit in 1. >>>> >>>> Is this possible? how much work can it be? >>>> >>>> Thanks in advance, >>>> >>>> Mariano >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >>> >> >

Nov. 30, 2010

Re: [Pharo-project] Issue 3360 in pharo: TextConverter handling of binary streams is wrong

by pharo＠googlecode.com

Comment #1 on issue 3360 by sven.van.caekenberghe: TextConverter handling of binary streams is wrong http://code.google.com/p/pharo/issues/detail?id=3360 ZnUTF8Encoder seems about 20% faster than UTF8Converter based on the following benchmark (which adds too many characters with multibyte encodings I guess): [ 100 timesRepeat: [ZnCharacterEncoderTests new testUTF8EncoderAuto] ] timeToRun. [ 100 timesRepeat: [ | in tmp out | in := String withAll: ((1 to: 3072) collect: [ :each | Character value: each ]). tmp := in convertToWithConverter: UTF8TextConverter new. out := tmp convertFromWithConverter: UTF8TextConverter new. self assert: in = out ] ] timeToRun. Note that tmp is a ByteString not a ByteArray.. Sven

Nov. 30, 2010

Re: [Pharo-project] Issue 3362 in pharo: Another fix for MethodReference

by pharo＠googlecode.com

Comment #2 on issue 3362 by marianopeck: Another fix for MethodReference http://code.google.com/p/pharo/issues/detail?id=3362 I am lost with the changes but in 1.1 MethodReference does have an accessor for classSymbol

Nov. 30, 2010

[Pharo-project] Problem with #garbageCollect and -memory parameter

by Mariano Martinez Peck

Hi folks. I am using the standard SqueakVM 4.2.5beta1U. If I run normaly the VM with a normal Pharo image and I print Smalltalk garbageCollect -> I get something like 492130460 Now...if I run the vm with the parameter -memory 1500m and I then print Smalltalk garbageCollect -> I get a NEGATIVE number like: -619402660 I guess there is a problem in somewhere like ObjectMemory >> bytesLeft: but I don't know... Anyway, the problem in my case is in SmalltalkImage: okayToProceedEvenIfSpaceIsLow "Return true if either there is enough memory to do so safely or if the user gives permission after being given fair warning." self garbageCollectMost > self lowSpaceThreshold ifTrue: [^ true]. "quick" self garbageCollect > self lowSpaceThreshold ifTrue: [^ true]. "work harder" ^ self confirm: 'WARNING: There is not enough space to start the low space watcher. If you proceed, you will not be warned again, and the system may run out of memory and crash. If you do proceed, you can start the low space notifier when more space becomes available simply by opening and then closing a debugger (e.g., by hitting Cmd-period.) Do you want to proceed?' Since both of the first answers false because, of course garbageCollectMost and garbageCollect are negative.... then I have that poup all the time. To fix this I have to posibilities: 1) Just patch this particular method to: self garbageCollectMost. self primBytesLeft > self lowSpaceThreshold ifTrue: [^ true]. "quick" self garbageCollect self primBytesLeft > self lowSpaceThreshold ifTrue: [^ true]. "work harder" Notice that primBytesLeft is answering correct. Wait..I don't know if correct, but at least possitive: 5691396 I think this is possitive because the primitive is not receiving a parameter, and thus, Interpreter >> primitiveBytesLeft evaluates the first part of the method, which just does self sizeOfFree: freeBlock , and not the second part where it does self bytesLeft: aBool. 2) understand why it is negative and fix it from the VM side (I have no idea how to do this). Now, in addition, I wonder if there may be other places broken because of this....I am having some crashed and I don't know why :( Thanks in advance, Mariano

Nov. 30, 2010

Re: [Pharo-project] Issue 3362 in pharo: Another fix for MethodReference

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.2 Comment #1 on issue 3362 by marcus.denker: Another fix for MethodReference http://code.google.com/p/pharo/issues/detail?id=3362 12266

Nov. 30, 2010

[Pharo-project] [update 1.2] #12266

by Marcus Denker

12266 ----- Issue 3191: SparseLargeArray Issue 3363: #isSafeVM calls deprecated method Issue 3362: Another fix for MethodReference -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Nov. 30, 2010