May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

Since code.google.com is broken, i putting it here. Embed source code for methods which get uninstalled from their classes. When compiled method is deinstalled from its class, its not managed anymore by development tools and it's hard to predict, how long a method could stay in the image, because if it contains blocks,they could still reference it. This change makes sure that when you deinstall method from its owning class, its source code are preserved in an embedded form inside a trailer. This is in addition to issue #... that one.. cant see it without google working, sorry :) -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

here an example how it works. first evaluate TTT blockValue so it assigns Block with closure returned by methodWithBlock. Now go to #methodWithBlock and change its implementation. And then try to debug TTT blockValue and you can see that when you evaluating a block , it will show you an original source code of method. (Except that there is some bug in debugger, which erasing the text area once you click on frame with block. But when you click it second time it show it normally). On 10 May 2011 16:46, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> oh , and forgot to note, that having a source code available at all >> times is quite useful in cases, >> when your methods using some kind of DSL. Because decompiler can only >> reconstruct a source code of smalltalk methods, >> but not the ones, which were authored using customized parser/compiler >> .. like using Helvetia. >> > > Btw, the change i proposing is _minimal_ and straightforward: > > basicAddSelector: selector withMethod: compiledMethod > Â Â Â Â "Add the message selector with the corresponding compiled method to the > Â Â Â Â receiver's method dictionary. > Â Â Â Â Do this without sending system change notifications" > > Â Â Â Â | oldMethodOrNil | > Â Â Â Â oldMethodOrNil := self lookupSelector: selector. > Â Â Â Â self methodDict at: selector put: compiledMethod. > Â Â Â Â compiledMethod methodClass: self. > Â Â Â Â compiledMethod selector: selector. > > Â Â Â Â "Now flush Pharo's method cache, either by selector or by method" > Â Â Â Â oldMethodOrNil ifNotNil: [ > Â Â Â Â Â Â Â Â oldMethodOrNil flushCache. > ++++ Â Â oldMethodOrNil dropSourcePointer. > Â Â Â Â Â Â Â Â ]. > Â Â Â Â selector flushCache. > > > :) > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

> > oh , and forgot to note, that having a source code available at all > times is quite useful in cases, > when your methods using some kind of DSL. Because decompiler can only > reconstruct a source code of smalltalk methods, > but not the ones, which were authored using customized parser/compiler > .. like using Helvetia. > Btw, the change i proposing is _minimal_ and straightforward: basicAddSelector: selector withMethod: compiledMethod "Add the message selector with the corresponding compiled method to the receiver's method dictionary. Do this without sending system change notifications" | oldMethodOrNil | oldMethodOrNil := self lookupSelector: selector. self methodDict at: selector put: compiledMethod. compiledMethod methodClass: self. compiledMethod selector: selector. "Now flush Pharo's method cache, either by selector or by method" oldMethodOrNil ifNotNil: [ oldMethodOrNil flushCache. ++++ oldMethodOrNil dropSourcePointer. ]. selector flushCache. :) -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

Re: [Pharo-project] About CompiledMethod category returning nil sometimes

by Mariano Martinez Peck

Hi Stef. From what I can see, the category can be nil only when CompiledMethods are created for DoIts but not for regular CompiledMethods. Even those which are under 'as yet unclassified' answer that and not nil. (CompiledMethod allInstances select: [ :each | (each category isNil and: [(each selector beginsWith: #DoIt) not]) ]) size answers 0 in my image. (CompiledMethod allInstances select: [ :each | each category isNil ] thenCollect: [:each | each selector]) asSet -->> a Set(#DoIt #DoItIn:) So...only those guys answers nil. Is that important? If so, we already have the message: CompiledMethod >> isSelfEvaluating ^self methodClass notNil and: [(#(#DoIt #DoItIn: nil) includes: self selector) not] that answers false for those do its. Hence, we could patch to something like this: CompiledMethod >> category self isSelfEvaluating ifFalse: [^ 'evaluating']. ^self methodClass organization categoryOfElement:self selector There is another solution: the CM to answers its category delegates to "^self methodClass organization categoryOfElement:self selector" for do-its, the methodClass is always "UndefinedObject" So.....I can create a category called "evaluation" in UndefinedObject and put these two new methods: DoIt "When execution code from a workspace or similar places the Compiler creates a dummy CompiledMethod whose methodClass is UndefinedObject. When such CompiledMethods are ask its category, it answers nil, since the selector is search in the organization of the methodClass, which in this case is UndefinedObject. Hence, implementing this mehtod here will make such CompiledMethods to answer the category where this method is. " DoItIn: nonImportant "When execution code from a workspace or similar places the Compiler creates a dummy CompiledMethod whose methodClass is UndefinedObject. When such CompiledMethods are ask its category, it answers nil, since the selector is search in the organization of the methodClass, which in this case is UndefinedObject. Hence, implementing this mehtod here will make such CompiledMethods to answer the category where this method is. " So....now: (CompiledMethod allInstances select: [ :each | each isSelfEvaluating not ] thenCollect: [:each| each category ]) asSet --->a Set(#evaluation) I am not sure which of the both solution is the best nor the impact of them, Cheers Mariano On Mon, May 9, 2011 at 11:35 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > With cyrille we experience sometimes CompiledMethod with nil category and > this can break hard some problem. > We were thinking but not sure that it would be good to make sure that nil > is not returned but 'as yet unclassified' > What do you think? > Do you have any idea of potential problem? > > Stef > -- Mariano http://marianopeck.wordpress.com

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

On 10 May 2011 16:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 May 2011 13:33, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 10.05.2011 12:44, Igor Stasenko wrote: >>> >>> On 10 May 2011 11:27, Mariano Martinez Peck<marianopeck(a)gmail.com> Â wrote: >>>> >>>> On Tue, May 10, 2011 at 10:59 AM, Igor Stasenko<siguctua(a)gmail.com> >>>> Â wrote: >>>>> >>>>> On 10 May 2011 09:48, Mariano Martinez Peck<marianopeck(a)gmail.com> >>>>> Â wrote: >>>>>> >>>>>> On Tue, May 10, 2011 at 9:41 AM, Marcus Denker<marcus.denker(a)inria.fr> >>>>>> wrote: >>>>>>> >>>>>>> On May 10, 2011, at 9:32 AM, Mariano Martinez Peck wrote: >>>>>>> >>>>>>>> what is even worst, is that even after removing those correct CM, and >>>>>>>> doing a GC etc...they still don't disappear. >>>>>>>> >>>>>>> There is >>>>>>> >>>>>>> Â Â Â Â ScriptLoader new cleanUpMethods >>>>>>> >>>>>>> This is called from #cleanUpForRelease and normally should make sure >>>>>>> there >>>>>>> are no old methods. >>>>>>> >>>>>> >>>>>> hehehehe if I do: ScriptLoader new cleanUpForRelease, then inspect >>>>>> ((CompiledMethod allInstances select: Â [:each | each trailer kind = >>>>>> #VarLengthSourcePointer] ) ) >>>>>> >>>>>> they are not GC'ed and if then I click on the first element in the >>>>>> inspector.... VM CRASH!!! Â with both, InterpreterVM and CogVM. >>>>>> >>>>>> :( >>>>>> >>>>> okay. it seems i found the offender. Its a CompiledMethod >>>>> class>>cleanUp. >>>>> It changing a source pointer of all non-installed methods to 0. >>>> >>>> Good catch!!! Â :) Â Anyway, why CompiledMethod class>>cleanUp would like >>>> to >>>> destroy source pointers??? >>>> If I understood correctly (please correct me), all compiled methods will >>>> loose the pointer to sources and hence they will be decompiled after when >>>> they are ask their source! >>> >>> Yes, if you wipe the sourcePointer, there is no way how you can get a >>> source code of method. >> >> I believe the "not getting the source code" was on purpose. >> It's done f.ex. as part of condenseChanges, as the source pointers would >> have been invalid anyways. >> The intent I believe is that you should get decompiled source if you inspect >> old(but still referenced) CompiledMethods, instead of a bogus display of >> some random part of the new changes file, and remove error handling in >> source lookup where pointer could potentially be beyond end of file. >> >> This of course worked much faster before trailers, when setSourcePointer: >> actually modified the instance inline, rather than become'ing a copy, >> nowadays I agree with Igor that it'd probably be more conceptually clean to >> the empty MethodTrailer in destroySourcePointer :) >> >> Just remember to make sure such instances decompile as expected to uphold >> why the zapping was done in the first place. >> If we're lucky, Â it won't crash the VM either ;) >> > > Actually , in #destroySourcePointer setting sourcePointer = 0 is pretty useless. > Since now, we can embed source code in trailer, we can replace a > senders of it with #dropSourcePointer. > Then you don't have to decompile the method, even if its no longer > installed and cannot be located in .sources or .changes files anymore. > > We could even do this at the method installation time: > Â - if a newly installed method replacing an old one, > we tell old one to drop its source pointer immediately. > > Then, by definition, you cannot have non-installed methods with wrong > source pointer, and all those methods will still be able to show you > an original source code. > > Sounds like an idea? > oh , and forgot to note, that having a source code available at all times is quite useful in cases, when your methods using some kind of DSL. Because decompiler can only reconstruct a source code of smalltalk methods, but not the ones, which were authored using customized parser/compiler .. like using Helvetia. >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

On 10 May 2011 13:33, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 10.05.2011 12:44, Igor Stasenko wrote: >> >> On 10 May 2011 11:27, Mariano Martinez Peck<marianopeck(a)gmail.com> Â wrote: >>> >>> On Tue, May 10, 2011 at 10:59 AM, Igor Stasenko<siguctua(a)gmail.com> >>> Â wrote: >>>> >>>> On 10 May 2011 09:48, Mariano Martinez Peck<marianopeck(a)gmail.com> >>>> Â wrote: >>>>> >>>>> On Tue, May 10, 2011 at 9:41 AM, Marcus Denker<marcus.denker(a)inria.fr> >>>>> wrote: >>>>>> >>>>>> On May 10, 2011, at 9:32 AM, Mariano Martinez Peck wrote: >>>>>> >>>>>>> what is even worst, is that even after removing those correct CM, and >>>>>>> doing a GC etc...they still don't disappear. >>>>>>> >>>>>> There is >>>>>> >>>>>> Â Â Â Â ScriptLoader new cleanUpMethods >>>>>> >>>>>> This is called from #cleanUpForRelease and normally should make sure >>>>>> there >>>>>> are no old methods. >>>>>> >>>>> >>>>> hehehehe if I do: ScriptLoader new cleanUpForRelease, then inspect >>>>> ((CompiledMethod allInstances select: Â [:each | each trailer kind = >>>>> #VarLengthSourcePointer] ) ) >>>>> >>>>> they are not GC'ed and if then I click on the first element in the >>>>> inspector.... VM CRASH!!! Â with both, InterpreterVM and CogVM. >>>>> >>>>> :( >>>>> >>>> okay. it seems i found the offender. Its a CompiledMethod >>>> class>>cleanUp. >>>> It changing a source pointer of all non-installed methods to 0. >>> >>> Good catch!!! Â :) Â Anyway, why CompiledMethod class>>cleanUp would like >>> to >>> destroy source pointers??? >>> If I understood correctly (please correct me), all compiled methods will >>> loose the pointer to sources and hence they will be decompiled after when >>> they are ask their source! >> >> Yes, if you wipe the sourcePointer, there is no way how you can get a >> source code of method. > > I believe the "not getting the source code" was on purpose. > It's done f.ex. as part of condenseChanges, as the source pointers would > have been invalid anyways. > The intent I believe is that you should get decompiled source if you inspect > old(but still referenced) CompiledMethods, instead of a bogus display of > some random part of the new changes file, and remove error handling in > source lookup where pointer could potentially be beyond end of file. > > This of course worked much faster before trailers, when setSourcePointer: > actually modified the instance inline, rather than become'ing a copy, > nowadays I agree with Igor that it'd probably be more conceptually clean to > the empty MethodTrailer in destroySourcePointer :) > > Just remember to make sure such instances decompile as expected to uphold > why the zapping was done in the first place. > If we're lucky, Â it won't crash the VM either ;) > Actually , in #destroySourcePointer setting sourcePointer = 0 is pretty useless. Since now, we can embed source code in trailer, we can replace a senders of it with #dropSourcePointer. Then you don't have to decompile the method, even if its no longer installed and cannot be located in .sources or .changes files anymore. We could even do this at the method installation time: - if a newly installed method replacing an old one, we tell old one to drop its source pointer immediately. Then, by definition, you cannot have non-installed methods with wrong source pointer, and all those methods will still be able to show you an original source code. Sounds like an idea? > Cheers, > Henry > -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

[Pharo-project] Small question in OSProcess

by Adrien BARREAU

Hi all, I just have a little question: Is there a way to change the working directory of my terminal with something in OSProcess? I mean: - I know I can change the working directory of the current process with "OSProcess thisOSProcess chDir: '/'" but of course it does nothing on the terminal - "OSProcess thisOSProcess command: 'cd /'" does absolutly nothing I hope it's clean enough. Regards, Adrien.

May 10, 2011

[Pharo-project] moose = smalltalk ambassador

by Tudor Girba

Hi, Moose (http://moosetechnology.org) is a Smalltalk ambassador. Actually, I think it's the best ambassador we have right now to persuade professional developers to look into Smalltalk. Let me tell you why. Moose is a platform for software and data analysis and includes components like: Glamour, Mondrian or PetitParser. Moose solves a real and important problem that developers (both Smalltalkers and non-Smalltalkers) have: how to improve the productivity of the effort spent on assessment. Moose is an innovation in this domain because it enables a completely different approach through which developers craft their own tools fast (http://humane-assessment.com) The cool thing is that they build these tools by programming Smalltalk in Pharo, and thus they get to learn the language and the platform first. Moose also comes with exposure. For example, this year I will be presenting Moose and humane assessment at some large industry oriented conferences: - Jazoon (http://jazoon.com) - GotoCon Aarhus (http://gotocon.com/aarhus-2011/) - GotoCon Amsterdam (http://gotocon.com/amsterdam-2011/) All in all, if you want to promote Smalltalk, and Pharo in particular, you might want to look into it. And you are always welcome to contribute, follow us and make noise: - http://www.moosetechnology.org - http://twitter.com/#!/moosetechnology - http://www.facebook.com/pages/moosetechnologyorg/152851281427491 Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

May 10, 2011

Re: [Pharo-project] NetNameResolver localHostName - Mac OS always returns an ip address string

by Luc Fabresse

Hi Nick, I just read your message and we faced this problem with Jannik working on the implementation of the network library Ocean. Using the 4.2.5beta1U Squeak VM and 1.3 Pharo image, there is primitives in the Socket plusgin to achieve what you are looking for: hostname := String new: NetNameResolver primHostNameSize. NetNameResolver primHostNameResult: hostname. hostname I do not remember if these primitives are also present in CogVM. Hope it helps, #Luc 2011/4/26 Nick Ager <nick.ager(a)gmail.com> > Hi, > > When I call the following on my Mac: > > NetNameResolver localHostName > > > the result is an ip address string eg '192.168.4.174' > > Is there some configuration work required on the Mac to ensure that > #localHostName returns a name rather than ip address. > Currently: > > $ hostname > Nick-Agers-MacBook-Pro2.local > > $ cat /etc/hosts > cat /etc/hosts > 127.0.0.1 localhost > > # The following lines are desirable for IPv6 capable hosts > ::1 ip6-localhost ip6-loopback > fe00::0 ip6-localnet > ff00::0 ip6-mcastprefix > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > ff02::3 ip6-allhosts > > I'd be happy with #localHostName returning the hostname or an entry in > /etc/hosts > > I've tested on Pharo 1.1.1 & 1.2.1 both using a COG vm > > Thanks > > Nick >

May 10, 2011

Re: [Pharo-project] compiled VM with Alien for JNIPort

by Igor Stasenko

On 10 May 2011 00:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, May 9, 2011 at 1:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 9 May 2011 21:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Mon, May 9, 2011 at 11:27 AM, laurent laffont >> > <laurent.laffont(a)gmail.com> >> > wrote: >> >> >> >> On Mon, May 9, 2011 at 4:02 PM, laurent laffont >> >> <laurent.laffont(a)gmail.com> wrote: >> >>> >> >>> Hi, >> >>> >> >>> is there a compiled VM available with Alien for OSX ? I want to use >> >>> JNIPort. >> >> >> >> >> >> Second question, if I need to compile the VM, which one should I use >> >> for >> >> Alien ? Cog is OK ? >> > >> > Yes. Â Cog is OK. >> >> And what plugin? NewsqueakIA32ABIPlugin, right? > > No, just IA32ABIPlugin. Â The difference between the two is only > thatÂ NewsqueakIA32ABIPlugin implements immutability checks. > Okay. So, Laurent, you can use one of the latest Cog VMs. This plugin are included as internal into VM by default. To check it you can just run: Smalltalk listBuiltinModules select: [:name | name beginsWith: 'IA32'] -- Best regards, Igor Stasenko AKA sig.

May 10, 2011