- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [squeak-dev] [BUG][FIX] CompiledMethodTrailer

by Mariano Martinez Peck

On Tue, May 10, 2011 at 1:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Okay, seems like i found the bug. > > > (CompiledMethodTrailer new sourcePointer: 0) testEncoding > > fails. > > And it happens only when you pass 0 as source pointer!! > Such an obscure case! > So...this means that after a day and a half of work of the whole community we finally fix it?? I am happy. Thanks Igor and the rest who helped as well :) Now...I am not sure if I understand. I saw your changes and you test. But my question is what happen with those incorrect CM that are arround. It means that the next build image, when it does the CompiledMethod cleanUp and destroy the sourcePointers, I will let correct CMs ? Does it mean that if I build a dev image now with such fix, I won't have these weird CMs bothering me? Ok....I am trying now.... Thanks a lot to everybody for the effort, Mariano > > @squeakers, for the context, check the discussion "Problem with > CompiledMethodTrailer" > in pharo-dev list. > > On 10 May 2011 12:47, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > >> > >> > > >> > I must be wrong, because the dev image when it is build, it calls all > >> > cleanUp methods for classes, so CompiledMethod class >> cleanUp shuld > >> > have > >> > been called, but if I take the Pharo1.3 result, I can see the source > >> > code > >> > (not decompiled) > >> > > >> > >> But you can't see the source of those methods in browser, because > >> browser works only with installed methods > >> while cleanup touching only non-installed ones. > > > > > > grrrr sorry, I forgot about the #isInstalled ... I went directly to see > > #destroySourcePointer > > heheheh > > > >> > >> >> > >> >> When i do this, my image hangs. > >> > > >> > I have just tried and it crash!!! Actually, I evaluated > CompiledMethod > >> > cleanUp. And just after cmd+b in CompiledMethod (to browse it) -> > crash > >> > How it is possilbe it didn't crash while building the dev image? or > >> > the > >> > first time I browse a class? > >> > maybe this incorrect CM are created by the build process just after > the > >> > cleanUp ? > >> > > >> I don't know yet. > >> Maybe there is some test, which breaking them when it runs? Or tests > >> are not run on those images? > > > > I was thinking exactly the same. But no, this image has not run the > tests. > > There are other images specially to download from hudson that are those > > after running tests :( > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- Mariano http://marianopeck.wordpress.com

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

The fix in http://code.google.com/p/pharo/issues/detail?id=4186 now one thing left: we need to get rid of hanging methods with corrupted trailers. And we do it like this: (CompiledMethod allInstances select: [:m | m isInstalled not and: [ m trailer kind = #VarLengthSourcePointer ]] ) do: [:each | each at: each size put: 0 ] This will replace a corrupted trailer with empty one. -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

Re: [Pharo-project] [BUG][FIX] CompiledMethodTrailer

by Igor Stasenko

And here the test , which covering this issue. -- Best regards, Igor Stasenko AKA sig.

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Henrik Sperre Johansen

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 ;) Cheers, Henry

May 10, 2011

[Pharo-project] [BUG][FIX] CompiledMethodTrailer

by Igor Stasenko

Okay, seems like i found the bug. (CompiledMethodTrailer new sourcePointer: 0) testEncoding fails. And it happens only when you pass 0 as source pointer!! Such an obscure case! @squeakers, for the context, check the discussion "Problem with CompiledMethodTrailer" in pharo-dev list. On 10 May 2011 12:47, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> > >> > I must be wrong, because the dev image when it is build, it calls all >> > cleanUp methods for classes, so CompiledMethod class >> cleanUp shuld >> > have >> > been called, but if I take the Pharo1.3 result, I can see the source >> > code >> > (not decompiled) >> > >> >> But you can't see the source of those methods in browser, because >> browser works only with installed methods >> while cleanup touching only non-installed ones. > > > grrrr sorry, I forgot about the #isInstalled ... I went directly to see > #destroySourcePointer > heheheh > >> >> >> >> >> When i do this, my image hangs. >> > >> > I have just tried and it crash!!!Â Actually, I evaluated CompiledMethod >> > cleanUp. And just after cmd+b in CompiledMethod (to browse it) -> crash >> > How it is possilbe it didn't crash while building the dev image?Â Â or >> > the >> > first time I browse a class? >> > maybe this incorrect CM are created by the build process just after the >> > cleanUp ? >> > >> I don't know yet. >> Maybe there is some test, which breaking them when it runs? Or tests >> are not run on those images? > > I was thinking exactly the same. But no, this image has not run the tests. > There are other images specially to download from hudson that are those > after running tests :( > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

May 10, 2011