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

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

by Eliot Miranda

On Tue, Nov 30, 2010 at 2:55 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Nov 30, 2010 at 11:45 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Tue, Nov 30, 2010 at 2:33 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Thanks to both for answering me. >>> Now, I have very very newbie question. >>> In my case, JUST BECAUSE i am testing, I directly access the >>> CompiledMethod using MethodDictionary >> #at:ifAbsent: >>> thus, I can intercept and load back the original proxy. >>> >>> Now, if I understood well, when you send a simple message to an object, >>> the method lookup is done at VM side, and there is no call to >>> MethodDictionary >> #at:ifAbsent: >>> >>> So, what I am saying is that someone (the system) can send messages to a >>> SmallInteger that acts as a compiled methods, without accessing it by >>> MethodDictionary >> #at:ifAbsent:. >>> If that message is understood by the SmallInetger, then it will probably >>> answer something different than the original method. >>> >> >> You're forgetting that the VM executes the methods it finds in a method >> dictionary, except if the VM finds other than a CompiledMethod in a method >> dictionary, in which case it sends run:with:in: to it. So the VM won't send >> anything to the SmallInteger method proxy other than run:with:in:. If it >> didn't send run:with:in: it would crash trying to execute the SmallInteger. >> >> > I think we are confusing exatly like we were confusing yesterday with my > supervisors. > > Eliot, one thing is to do this: > > > MyClass methodDict at: #foo put: 5. > MyClass new foo. > > Here I am SURE the VM will send #run:with:in to SmallInteger. > > Now, my question is when I send a MESSAGE to the CompiledMethod, and NOT to > the object which class has installed the compiled method. > > Suppose I do: (MyClass methodDict at: #foo) size. and that I don't > change the implementation of MethodDictionary >> #at:ifAbsent: > > In this case, the VM will just try to send the message size to that > whatever is there. Both, SmallInteger and CompiledMethod understand #size, > but both answer different things... > I cannot intercept this, and I cannot load back the original object. > > This is why with Levento we thought about modifying MethodDictionary >> > #at:ifAbsent: to something like this: > > > at: key ifAbsent: aBlock > > | index value | > index := self findElementOrNil: key. > (self basicAt: index) == nil ifTrue: [ ^ aBlock value ]. > value := array at: index. > (value mareaIsProxy) ifTrue: [value mareaUninstall]. > ^ array at: index > > > But then, my question is if the system may access by another way than that > one. Ok, I should also modify some other methods in MethodDictionary like > #valuesDo: etc,,, > but if I do that, is that enough? or the system can still send messages > without passing there? > > Thanks a lot! > AFAIA there are no other ways than in the VM or explicitly, except in the VM simulator ;). best, Eliot > > mariano > > > > > >> best >> Eliot >> >>> >>> Now, maybe what I am thinking cannot happen. >>> >>> Thanks once again >>> >>> Mariano >>> >>> >>> >>> On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>>> On Tue, 30 Nov 2010, Igor Stasenko wrote: >>>> >>>> .. and then you need to change #do: , #associationsDo: etc etc.. >>>>> >>>> >>>> Or he can subclass MethodDictionary and override those methods. >>>> >>>> >>>> Levente >>>> >>>> >>> >> >

Nov. 30, 2010

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

by Mariano Martinez Peck

On Tue, Nov 30, 2010 at 5:14 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > 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. > Hi Dave. Ok...after a couple of hours I could compile a new VM for MacOS with VMMaker 205 and integrating all my changes :) So....this was something I have to do since several months already hehhehe Now, as you guessed, something was related to that. Now, these are the results: normal: Smalltalk garbageCollect 481957728 Smalltalk primBytesLeft 5738200 with -memory 1500m Smalltalk garbageCollect 482093452 Smalltalk primBytesLeft 6444200 Now, at least it is not negative. But I wonder....shouldn't I have more bytes left when I send 1500m ? how can I be sure that the VM is actually tacking into account this parameter? can I check some parameter in Smalltalk vmParameterAt: ? thanks! mariano > 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 11:45 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Tue, Nov 30, 2010 at 2:33 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Thanks to both for answering me. >> Now, I have very very newbie question. >> In my case, JUST BECAUSE i am testing, I directly access the >> CompiledMethod using MethodDictionary >> #at:ifAbsent: >> thus, I can intercept and load back the original proxy. >> >> Now, if I understood well, when you send a simple message to an object, >> the method lookup is done at VM side, and there is no call to >> MethodDictionary >> #at:ifAbsent: >> >> So, what I am saying is that someone (the system) can send messages to a >> SmallInteger that acts as a compiled methods, without accessing it by >> MethodDictionary >> #at:ifAbsent:. >> If that message is understood by the SmallInetger, then it will probably >> answer something different than the original method. >> > > You're forgetting that the VM executes the methods it finds in a method > dictionary, except if the VM finds other than a CompiledMethod in a method > dictionary, in which case it sends run:with:in: to it. So the VM won't send > anything to the SmallInteger method proxy other than run:with:in:. If it > didn't send run:with:in: it would crash trying to execute the SmallInteger. > > I think we are confusing exatly like we were confusing yesterday with my supervisors. Eliot, one thing is to do this: MyClass methodDict at: #foo put: 5. MyClass new foo. Here I am SURE the VM will send #run:with:in to SmallInteger. Now, my question is when I send a MESSAGE to the CompiledMethod, and NOT to the object which class has installed the compiled method. Suppose I do: (MyClass methodDict at: #foo) size. and that I don't change the implementation of MethodDictionary >> #at:ifAbsent: In this case, the VM will just try to send the message size to that whatever is there. Both, SmallInteger and CompiledMethod understand #size, but both answer different things... I cannot intercept this, and I cannot load back the original object. This is why with Levento we thought about modifying MethodDictionary >> #at:ifAbsent: to something like this: at: key ifAbsent: aBlock | index value | index := self findElementOrNil: key. (self basicAt: index) == nil ifTrue: [ ^ aBlock value ]. value := array at: index. (value mareaIsProxy) ifTrue: [value mareaUninstall]. ^ array at: index But then, my question is if the system may access by another way than that one. Ok, I should also modify some other methods in MethodDictionary like #valuesDo: etc,,, but if I do that, is that enough? or the system can still send messages without passing there? Thanks a lot! mariano > best > Eliot > >> >> Now, maybe what I am thinking cannot happen. >> >> Thanks once again >> >> Mariano >> >> >> >> On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Tue, 30 Nov 2010, Igor Stasenko wrote: >>> >>> .. and then you need to change #do: , #associationsDo: etc etc.. >>>> >>> >>> Or he can subclass MethodDictionary and override those methods. >>> >>> >>> Levente >>> >>> >> >

Nov. 30, 2010

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

by Eliot Miranda

On Tue, Nov 30, 2010 at 2:33 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Thanks to both for answering me. > Now, I have very very newbie question. > In my case, JUST BECAUSE i am testing, I directly access the CompiledMethod > using MethodDictionary >> #at:ifAbsent: > thus, I can intercept and load back the original proxy. > > Now, if I understood well, when you send a simple message to an object, the > method lookup is done at VM side, and there is no call to MethodDictionary > >> #at:ifAbsent: > > So, what I am saying is that someone (the system) can send messages to a > SmallInteger that acts as a compiled methods, without accessing it by > MethodDictionary >> #at:ifAbsent:. > If that message is understood by the SmallInetger, then it will probably > answer something different than the original method. > You're forgetting that the VM executes the methods it finds in a method dictionary, except if the VM finds other than a CompiledMethod in a method dictionary, in which case it sends run:with:in: to it. So the VM won't send anything to the SmallInteger method proxy other than run:with:in:. If it didn't send run:with:in: it would crash trying to execute the SmallInteger. best Eliot > > Now, maybe what I am thinking cannot happen. > > Thanks once again > > Mariano > > > > On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Tue, 30 Nov 2010, Igor Stasenko wrote: >> >> .. and then you need to change #do: , #associationsDo: etc etc.. >>> >> >> Or he can subclass MethodDictionary and override those methods. >> >> >> Levente >> >> >

Nov. 30, 2010

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

by Mariano Martinez Peck

Thanks to both for answering me. Now, I have very very newbie question. In my case, JUST BECAUSE i am testing, I directly access the CompiledMethod using MethodDictionary >> #at:ifAbsent: thus, I can intercept and load back the original proxy. Now, if I understood well, when you send a simple message to an object, the method lookup is done at VM side, and there is no call to MethodDictionary >> #at:ifAbsent: So, what I am saying is that someone (the system) can send messages to a SmallInteger that acts as a compiled methods, without accessing it by MethodDictionary >> #at:ifAbsent:. If that message is understood by the SmallInetger, then it will probably answer something different than the original method. Now, maybe what I am thinking cannot happen. Thanks once again Mariano On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 30 Nov 2010, Igor Stasenko wrote: > > .. and then you need to change #do: , #associationsDo: etc etc.. >> > > Or he can subclass MethodDictionary and override those methods. > > > Levente > >

Nov. 30, 2010

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

by pharo＠googlecode.com

Comment #5 on issue 3288 by renggli: OB does not work with editor changes http://code.google.com/p/pharo/issues/detail?id=3288 Sure, please fork OB for 1.2. I will fix (or merge) it as soon as the beta is out.

Nov. 30, 2010

Re: [Pharo-project] [squeak-dev] Web Services - SoapOpera problems

by StÃ©phane Ducasse

thanks for reporting that. Indeed we should improve on that level. Stef On Nov 30, 2010, at 7:47 PM, CÃ©drick BÃ©ler wrote: > Hi all, > > I'd like to try some webservice experiments. I loaded the last version of SoapOpera but then, I struggled a lot and I still can't make it work. > > First, I needed authentication and I didn't found how to do that in SOAP. I managed to make it work by hacking Kom. > Does someone knows how to do that properly or if it's not possible? > > Second, I just can't make it work (whereas I can in PHP and it's dead simple :( with SoapClient). I have an error message saying that the interface is not known... After investigating a bit, I think that the problem is there is no "interpretation" of the wsdl file that describe the set of services. > > Can people confirm if I'm wrong or not ? > What's the current state of SoapOpera development ? Are there alternatives ? > > TIA > > ps: in PHP > > $client = new SoapClient($WSDL, array('login'=> $LOGIN,'password'=> $PASS)); > $client->TDOptionsPromotion( "whatever parameters"); > > in Smalltalk (not the example I tried but something else that nearly works, except I get one value, the last one, instead of an array of five) > > call := (SoapCallEntry tcpHost: 'footballpool.dataaccess.eu' port: 80) newCall. > call targetObjectURI: 'data/info.wso'. > call namespace: 'http://footballpool.dataaccess.eu'. > call methodName: 'TopGoalScorers'. > call addParameterNamed: 'iTopN' value: '5'. > call invokeAndReturn.

Nov. 30, 2010

Re: [Pharo-project] Issue 3365 in pharo: TextEditorTest fails because of editor changes

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3365 by aplantec: TextEditorTest fails because of editor changes http://code.google.com/p/pharo/issues/detail?id=3365 In fact 5 tests were concerned. in inbox SLICE-Issue-3365-TextEditorTest-fails-because-of-editor-changes

Nov. 30, 2010

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

by pharo＠googlecode.com

Comment #4 on issue 3288 by aplantec: OB does not work with editor changes http://code.google.com/p/pharo/issues/detail?id=3288 it's for 1.2

Nov. 30, 2010

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

by Levente Uzonyi

On Tue, 30 Nov 2010, Igor Stasenko wrote: > .. and then you need to change #do: , #associationsDo: etc etc.. Or he can subclass MethodDictionary and override those methods. Levente

Nov. 30, 2010