- Pharo-dev - lists.pharo.org

[Pharo-project] Progress while updating

by Torsten Bergmann

When updating from Pharo2.0a Latest update: #20559 to Pharo2.0a Latest update: #20560 There is no progress bar visible. I'm not sure - in #20557 there was a change on progress bar and the issue http://code.google.com/p/pharo/issues/detail?id=7110 does not really describe what the problem really was that have been solved. Thanks T.

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Guillermo Polito

On Wed, Feb 20, 2013 at 2:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > but aside of making things work, > i really wonder why become on methods makes VM crash. > we should have an easily reproducible case for study. > These? (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1 > > > -- > Best regards, > Igor Stasenko. > >

Feb. 20, 2013

Re: [Pharo-project] Pharo 2 changes management

by Norbert Hartl

Am 20.02.2013 um 11:34 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > On Feb 20, 2013, at 11:25 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 20.02.2013 um 11:17 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> there is a problem with the package definition, I think (PetitXPath != Petitxpath), and new RPackage cannot detect they are the same... in fact, IMO that exposes an old PackageInfo bug, not an RPackage problem, so I think the real solution is to commit a package with a good package name. >> >> So, what are the rules. Does the case sensitivity also reflect in method extensions? Meaning do I need to call the extension *petitXPath or even *PetitXPath? > > nono, method extensions remains the same (case insensitive). What I mean is that I made a mistake when I create the PetitXPath package originally (I committed with a bad mc name)... that's the origin of your problem now (yep, once again, my fault :). > But it shouldn't happen with other well-formed packages. And in my opinion, best way to proceed is to create a package as it should be and re-commit, because is not a MC problem, nor an RPackage problem, is a problem with that specific package. > Hmm, can't get it to work. Now I have problems to get the method extensions into the package. Because of the Petitxpath being written lower case I had to remove the working copy. I created a new package with the letters in proper upper-/lowercase. The changes diff looks ok now but method extensions are not be part of the package. If I write the package and look at them use the "browse" button in monticello browser I can see that they are not included in the package. Norbert >> >>> Also, it does not looks like you have the lastest image... you should be seeing something like this: >>> >> Yeah, I made the screenshot with an older image. I retried it then with updating the image first. But seeing that the result ist the same made me send the old screenshot. > > fiuuuuu... I was worried :) > > Esteban > >> Norbert >> >>> <Screen Shot 2013-02-20 at 11.15.07 AM.png> >>> >>> >>> (notice the diff morph has a bar in the middle, also two text label on top). >>> >>> >>> On Feb 20, 2013, at 11:08 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>>> I opened a fresh pharo 2 (#20559) and loaded PetitXPath. Modifying a method does not mark the package dirty in monticello browser. And If I press the "changes" button I can see >>>> >>>> <Bildschirmfoto 2013-02-20 um 11.00.54.png> >>>> >>>> That basically shows all the code that is in the package. But from my own change I cannot see anything in there. >>>> >>>> Norbert >>> >> >

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Igor Stasenko

but aside of making things work, i really wonder why become on methods makes VM crash. we should have an easily reproducible case for study. -- Best regards, Igor Stasenko.

Feb. 20, 2013

[Pharo-project] Inbox in SmalltalkHub ?

by Serge Stinckwich

Dear all, If I remember correctly, in previous version of SmalltalkHub, there was an inbox for every project. Apparently this is not more the case in current version ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Feb. 20, 2013

[Pharo-project] [update 2.0] #20560

by Esteban Lorenzano

20560 ----- Issue 7535: [SPEC] ClassMethodBrowser double initialization http://code.google.com/p/pharo/issues/detail?id=7535 Issue 7546: add failing windows NB tests as windows-only known failures http://code.google.com/p/pharo/issues/detail?id=7546 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Examples-EstebanLorenzano.18.diff http://ss3.gemstone.com/ss/Pharo20/NativeBoost-Win32-EstebanLorenzano.35.di… http://ss3.gemstone.com/ss/Pharo20/NativeBoost-Tests-EstebanLorenzano.50.di… http://ss3.gemstone.com/ss/Pharo20/NativeBoost-Examples-EstebanLorenzano.16… http://ss3.gemstone.com/ss/Pharo20/NativeBoost-Core-EstebanLorenzano.111.di…

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Marcus Denker

On Feb 20, 2013, at 1:41 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Wed, Feb 20, 2013 at 1:35 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Why do we create new methods at all? *every* existing, installed > method has enough space > at the end for any kind of trailer. > > So can't we just write the source in the file, get the offset, then > put that offset in the *existing* > method? > > But isn't that circumstantial? I mean, today we have source pointers inside all compiled methods, but there is infrastructure to do something different in the future... > If we do anything, after we have done that, there will be no condensing necessary... > Anyway, I'm in hacky mode now, so I didn't think to much, just made it work :P > :-)

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Guillermo Polito

On Wed, Feb 20, 2013 at 1:35 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > Why do we create new methods at all? *every* existing, installed > method has enough space > at the end for any kind of trailer. > > So can't we just write the source in the file, get the offset, then > put that offset in the *existing* > method? > But isn't that circumstantial? I mean, today we have source pointers inside all compiled methods, but there is infrastructure to do something different in the future... Anyway, I'm in hacky mode now, so I didn't think to much, just made it work :P > > Marcus > > On Wed, Feb 20, 2013 at 12:26 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > > Ok, so I did that, and have this. So the condense looks finished, but > when > > returning to the UI thread, canvas is nil? > > > > Hmm, I think we should stop the UI thread also and spawn a new one after > > condensing... > > > > Error: MessageNotUnderstood: receiver of "finish" is nil > > UndefinedObject(Object)>>error: > > WorldState>>displayWorldSafely: in Block: [:t2 :t3 | ... > > BlockClosure>>cull:cull: > > BlockClosure>>ifError: in Block: [:t2 | t1 cull: t2 description cull: t2 > > receiver] > > BlockClosure>>cull: > > MethodContext(ContextPart)>>handleSignal: in Block: [self > > exceptionHandlerBlock cull: exception] > > BlockClosure>>ensure: > > MethodContext(ContextPart)>>handleSignal: > > MessageNotUnderstood(Exception)>>signal > > UndefinedObject(Object)>>doesNotUnderstand: #finish > > WorldState>>displayWorld:submorphs: > > > > On Wed, Feb 20, 2013 at 12:15 PM, Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> > >> On Feb 20, 2013, at 12:13 PM, Guillermo Polito < > guillermopolito(a)gmail.com> > >> wrote: > >> > >> Ok, I tried the following: > >> > >> - changed the become in #setSourcePointer: by an #at:put: in the method > >> dict > >> - before exporting the sources, I run the shutdown and after, I run the > >> startup lists. > >> - I ran the condense sources like > >> > >> [ Smalltalk condenseSources ] forkAt: Processor highestPriority. > >> > >> > >> Then, the export runs ok, but there is a crash in the CompiledMethod > >> class>>cleanUp > >> > >> > >> I think the cleanup is not necessary when condensingâ¦ it touches only > >> methods > >> that are *not* installed in classes. > >> We should remove that call from the condense method. > >> > >> Segmentation fault > >> > >> > >> Smalltalk stack dump: > >> 0xbffbe2d0 M ByteString class(String class)>new: 528605460: a(n) > >> ByteString class > >> 0xbffbe2f8 M ByteString(SequenceableCollection)>copyReplaceFrom:to:with: > >> 531139536: a(n) ByteString > >> 0xbffbe31c M ByteString(SequenceableCollection)>, 531139536: a(n) > >> ByteString > >> 0xbffbe33c M CompiledMethodTrailer>encode 570089224: a(n) > >> CompiledMethodTrailer > >> 0xbffbe35c M CompiledMethodTrailer>createMethod:class:header: 570089224: > >> a(n) CompiledMethodTrailer > >> 0xbffbe39c M CompiledMethod>copyWithTrailerBytes: 530925156: a(n) > >> CompiledMethod > >> 0xbffbe3bc M CompiledMethod>zapSourcePointer 530925156: a(n) > >> CompiledMethod > >> 0xbffbe3d4 M [] in CompiledMethod class>cleanUp 528604864: a(n) > >> CompiledMethod class > >> > >> On Wed, Feb 20, 2013 at 12:00 PM, Igor Stasenko <siguctua(a)gmail.com> > >> wrote: > >>> > >>> i thinking that become is unnecessary, > >>> it can be just at:put: into method dictionary, > >>> so eventually all methods will be updated (after restarting permanent > >>> processes) > >>> > >>> On 20 February 2013 11:13, Guillermo Polito <guillermopolito(a)gmail.com > > > >>> wrote: > >>> > I summon Eliot :). > >>> > > >>> > > >>> > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker > >>> > <marcus.denker(a)inria.fr> > >>> > wrote: > >>> >> > >>> >> > >>> >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito > >>> >> <guillermopolito(a)gmail.com> > >>> >> wrote: > >>> >> > >>> >> 'cause you don't know if the method has trailer or not I think... > >>> >> There > >>> >> are empty trailers and trailers embedding source (directly in the > >>> >> image)... > >>> >> isn't it? > >>> >> > >>> >> Not for those methods installed in classesâ¦ we are updating an > >>> >> existing > >>> >> pointer here. > >>> >> > >>> >> Marcus > >>> >> > >>> >> > >>> >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker > >>> >> <marcus.denker(a)inria.fr> > >>> >> wrote: > >>> >>> > >>> >>> > >>> >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito > >>> >>> <guillermopolito(a)gmail.com> wrote: > >>> >>> > >>> >>> Hi! > >>> >>> > >>> >>> There is this bug open I was taking a look yesterday: > >>> >>> > >>> >>> > >>> >>> > >>> >>> > http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milest… > >>> >>> > >>> >>> The condense sources compacts the changes and source files, and > adds > >>> >>> a > >>> >>> new method trailer to a compiled method with it's new source > pointer. > >>> >>> In > >>> >>> order to do that, it does a #becomeForward: to the method. > >>> >>> > >>> >>> CompiledMethod>>setSourcePointer: srcPointer > >>> >>> "We can't change the trailer of existing method, since > >>> >>> it could have completely different format. Therefore we need to > >>> >>> generate a copy with new trailer, containing an scrPointer, and > then > >>> >>> #become it" > >>> >>> | trailer copy | > >>> >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer. > >>> >>> copy := self copyWithTrailerBytes: trailer. > >>> >>> >>> self becomeForward: copy. > >>> >>> ^ copy > >>> >>> > >>> >>> So far, with simple methods, so good. > >>> >>> > >>> >>> However, there are cases, in which becoming the compiled method, > >>> >>> breaks > >>> >>> processes, sometimes getting a crash in the VM. For example: > >>> >>> > >>> >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 > >>> >>> > >>> >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 > >>> >>> inFile: 1 > >>> >>> > >>> >>> My assumption is that the #becomeForward: of compiled methods do > not > >>> >>> get > >>> >>> well with the stack mapping in the vm... But just guessing. > >>> >>> > >>> >>> > >>> >>> I wonder why we don't just update the pointer. > >>> >>> That is: we keep the method the same, rewrite the pointer, and > >>> >>> nothing > >>> >>> else. > >>> >>> > >>> >>> Marcus > >>> >>> > >>> >> > >>> >> > >>> > > >>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko. > >>> > >> > >> > > > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > >

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Guillermo Polito

So, this (hacky) changeset does the trick. [ Smalltalk condenseSources ] forkAt: Processor highestPriority. works.. Resuming: - changed the becomeForward by an at:put: - a little hack/fix to serialize unicode chars in the sources file (Japanese environment) - removed the progress bar stuff from condenseChanges - before condensing process the shutdown list - after condensing process the startup list - do not cleanup methods - after processing the startuplist, kill current UIProcess and start a new one - run the condense changes in highest priority so it does not get preempted by inconsistent processes. On Wed, Feb 20, 2013 at 12:26 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Ok, so I did that, and have this. So the condense looks finished, but when > returning to the UI thread, canvas is nil? > > Hmm, I think we should stop the UI thread also and spawn a new one after > condensing... > > Error: MessageNotUnderstood: receiver of "finish" is nil > UndefinedObject(Object)>>error: > WorldState>>displayWorldSafely: in Block: [:t2 :t3 | ... > BlockClosure>>cull:cull: > BlockClosure>>ifError: in Block: [:t2 | t1 cull: t2 description cull: t2 > receiver] > BlockClosure>>cull: > MethodContext(ContextPart)>>handleSignal: in Block: [self > exceptionHandlerBlock cull: exception] > BlockClosure>>ensure: > MethodContext(ContextPart)>>handleSignal: > MessageNotUnderstood(Exception)>>signal > UndefinedObject(Object)>>doesNotUnderstand: #finish > WorldState>>displayWorld:submorphs: > > On Wed, Feb 20, 2013 at 12:15 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Feb 20, 2013, at 12:13 PM, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Ok, I tried the following: >> >> - changed the become in #setSourcePointer: by an #at:put: in the method >> dict >> - before exporting the sources, I run the shutdown and after, I run the >> startup lists. >> - I ran the condense sources like >> >> [ Smalltalk condenseSources ] forkAt: Processor highestPriority. >> >> >> Then, the export runs ok, but there is a crash in the CompiledMethod >> class>>cleanUp >> >> >> I think the cleanup is not necessary when condensingâ¦ it touches only >> methods >> that are *not* installed in classes. >> We should remove that call from the condense method. >> >> Segmentation fault >> >> >> Smalltalk stack dump: >> 0xbffbe2d0 M ByteString class(String class)>new: 528605460: a(n) >> ByteString class >> 0xbffbe2f8 M ByteString(SequenceableCollection)>copyReplaceFrom:to:with: >> 531139536: a(n) ByteString >> 0xbffbe31c M ByteString(SequenceableCollection)>, 531139536: a(n) >> ByteString >> 0xbffbe33c M CompiledMethodTrailer>encode 570089224: a(n) >> CompiledMethodTrailer >> 0xbffbe35c M CompiledMethodTrailer>createMethod:class:header: 570089224: >> a(n) CompiledMethodTrailer >> 0xbffbe39c M CompiledMethod>copyWithTrailerBytes: 530925156: a(n) >> CompiledMethod >> 0xbffbe3bc M CompiledMethod>zapSourcePointer 530925156: a(n) >> CompiledMethod >> 0xbffbe3d4 M [] in CompiledMethod class>cleanUp 528604864: a(n) >> CompiledMethod class >> >> On Wed, Feb 20, 2013 at 12:00 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> i thinking that become is unnecessary, >>> it can be just at:put: into method dictionary, >>> so eventually all methods will be updated (after restarting permanent >>> processes) >>> >>> On 20 February 2013 11:13, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> > I summon Eliot :). >>> > >>> > >>> > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker < >>> marcus.denker(a)inria.fr> >>> > wrote: >>> >> >>> >> >>> >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito < >>> guillermopolito(a)gmail.com> >>> >> wrote: >>> >> >>> >> 'cause you don't know if the method has trailer or not I think... >>> There >>> >> are empty trailers and trailers embedding source (directly in the >>> image)... >>> >> isn't it? >>> >> >>> >> Not for those methods installed in classesâ¦ we are updating an >>> existing >>> >> pointer here. >>> >> >>> >> Marcus >>> >> >>> >> >>> >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker < >>> marcus.denker(a)inria.fr> >>> >> wrote: >>> >>> >>> >>> >>> >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito >>> >>> <guillermopolito(a)gmail.com> wrote: >>> >>> >>> >>> Hi! >>> >>> >>> >>> There is this bug open I was taking a look yesterday: >>> >>> >>> >>> >>> >>> >>> http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milest… >>> >>> >>> >>> The condense sources compacts the changes and source files, and adds >>> a >>> >>> new method trailer to a compiled method with it's new source >>> pointer. In >>> >>> order to do that, it does a #becomeForward: to the method. >>> >>> >>> >>> CompiledMethod>>setSourcePointer: srcPointer >>> >>> "We can't change the trailer of existing method, since >>> >>> it could have completely different format. Therefore we need to >>> >>> generate a copy with new trailer, containing an scrPointer, and then >>> >>> #become it" >>> >>> | trailer copy | >>> >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer. >>> >>> copy := self copyWithTrailerBytes: trailer. >>> >>> >>> self becomeForward: copy. >>> >>> ^ copy >>> >>> >>> >>> So far, with simple methods, so good. >>> >>> >>> >>> However, there are cases, in which becoming the compiled method, >>> breaks >>> >>> processes, sometimes getting a crash in the VM. For example: >>> >>> >>> >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 >>> >>> >>> >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 >>> inFile: 1 >>> >>> >>> >>> My assumption is that the #becomeForward: of compiled methods do not >>> get >>> >>> well with the stack mapping in the vm... But just guessing. >>> >>> >>> >>> >>> >>> I wonder why we don't just update the pointer. >>> >>> That is: we keep the method the same, rewrite the pointer, and >>> nothing >>> >>> else. >>> >>> >>> >>> Marcus >>> >>> >>> >> >>> >> >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >> >

Feb. 20, 2013

Re: [Pharo-project] About condensing sources, becoming CompiledMethods and VM crashes

by Marcus Denker

Hi, Why do we create new methods at all? *every* existing, installed method has enough space at the end for any kind of trailer. So can't we just write the source in the file, get the offset, then put that offset in the *existing* method? Marcus On Wed, Feb 20, 2013 at 12:26 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, so I did that, and have this. So the condense looks finished, but when > returning to the UI thread, canvas is nil? > > Hmm, I think we should stop the UI thread also and spawn a new one after > condensing... > > Error: MessageNotUnderstood: receiver of "finish" is nil > UndefinedObject(Object)>>error: > WorldState>>displayWorldSafely: in Block: [:t2 :t3 | ... > BlockClosure>>cull:cull: > BlockClosure>>ifError: in Block: [:t2 | t1 cull: t2 description cull: t2 > receiver] > BlockClosure>>cull: > MethodContext(ContextPart)>>handleSignal: in Block: [self > exceptionHandlerBlock cull: exception] > BlockClosure>>ensure: > MethodContext(ContextPart)>>handleSignal: > MessageNotUnderstood(Exception)>>signal > UndefinedObject(Object)>>doesNotUnderstand: #finish > WorldState>>displayWorld:submorphs: > > On Wed, Feb 20, 2013 at 12:15 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> >> On Feb 20, 2013, at 12:13 PM, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Ok, I tried the following: >> >> - changed the become in #setSourcePointer: by an #at:put: in the method >> dict >> - before exporting the sources, I run the shutdown and after, I run the >> startup lists. >> - I ran the condense sources like >> >> [ Smalltalk condenseSources ] forkAt: Processor highestPriority. >> >> >> Then, the export runs ok, but there is a crash in the CompiledMethod >> class>>cleanUp >> >> >> I think the cleanup is not necessary when condensingâ¦ it touches only >> methods >> that are *not* installed in classes. >> We should remove that call from the condense method. >> >> Segmentation fault >> >> >> Smalltalk stack dump: >> 0xbffbe2d0 M ByteString class(String class)>new: 528605460: a(n) >> ByteString class >> 0xbffbe2f8 M ByteString(SequenceableCollection)>copyReplaceFrom:to:with: >> 531139536: a(n) ByteString >> 0xbffbe31c M ByteString(SequenceableCollection)>, 531139536: a(n) >> ByteString >> 0xbffbe33c M CompiledMethodTrailer>encode 570089224: a(n) >> CompiledMethodTrailer >> 0xbffbe35c M CompiledMethodTrailer>createMethod:class:header: 570089224: >> a(n) CompiledMethodTrailer >> 0xbffbe39c M CompiledMethod>copyWithTrailerBytes: 530925156: a(n) >> CompiledMethod >> 0xbffbe3bc M CompiledMethod>zapSourcePointer 530925156: a(n) >> CompiledMethod >> 0xbffbe3d4 M [] in CompiledMethod class>cleanUp 528604864: a(n) >> CompiledMethod class >> >> On Wed, Feb 20, 2013 at 12:00 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >>> >>> i thinking that become is unnecessary, >>> it can be just at:put: into method dictionary, >>> so eventually all methods will be updated (after restarting permanent >>> processes) >>> >>> On 20 February 2013 11:13, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> > I summon Eliot :). >>> > >>> > >>> > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker >>> > <marcus.denker(a)inria.fr> >>> > wrote: >>> >> >>> >> >>> >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito >>> >> <guillermopolito(a)gmail.com> >>> >> wrote: >>> >> >>> >> 'cause you don't know if the method has trailer or not I think... >>> >> There >>> >> are empty trailers and trailers embedding source (directly in the >>> >> image)... >>> >> isn't it? >>> >> >>> >> Not for those methods installed in classesâ¦ we are updating an >>> >> existing >>> >> pointer here. >>> >> >>> >> Marcus >>> >> >>> >> >>> >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker >>> >> <marcus.denker(a)inria.fr> >>> >> wrote: >>> >>> >>> >>> >>> >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito >>> >>> <guillermopolito(a)gmail.com> wrote: >>> >>> >>> >>> Hi! >>> >>> >>> >>> There is this bug open I was taking a look yesterday: >>> >>> >>> >>> >>> >>> >>> >>> http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milest… >>> >>> >>> >>> The condense sources compacts the changes and source files, and adds >>> >>> a >>> >>> new method trailer to a compiled method with it's new source pointer. >>> >>> In >>> >>> order to do that, it does a #becomeForward: to the method. >>> >>> >>> >>> CompiledMethod>>setSourcePointer: srcPointer >>> >>> "We can't change the trailer of existing method, since >>> >>> it could have completely different format. Therefore we need to >>> >>> generate a copy with new trailer, containing an scrPointer, and then >>> >>> #become it" >>> >>> | trailer copy | >>> >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer. >>> >>> copy := self copyWithTrailerBytes: trailer. >>> >>> >>> self becomeForward: copy. >>> >>> ^ copy >>> >>> >>> >>> So far, with simple methods, so good. >>> >>> >>> >>> However, there are cases, in which becoming the compiled method, >>> >>> breaks >>> >>> processes, sometimes getting a crash in the VM. For example: >>> >>> >>> >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1 >>> >>> >>> >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 >>> >>> inFile: 1 >>> >>> >>> >>> My assumption is that the #becomeForward: of compiled methods do not >>> >>> get >>> >>> well with the stack mapping in the vm... But just guessing. >>> >>> >>> >>> >>> >>> I wonder why we don't just update the pointer. >>> >>> That is: we keep the method the same, rewrite the pointer, and >>> >>> nothing >>> >>> else. >>> >>> >>> >>> Marcus >>> >>> >>> >> >>> >> >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 20, 2013