- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

On 9 May 2011 09:36, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Mon, May 9, 2011 at 6:14 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 9 May 2011 00:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> > Hi guys, Maybe it is too late and I am not seeing something obvious...so >> > another look is really appreciated. If I do: >> > >> > (CompiledMethod allInstances select:Â [:each | each trailer kind = >> > #VarLengthSourcePointer] ) first >> > ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") >> > >> > But then: >> > >> > (CodeLoader class >> #initialize) trailer kind >> > ----> #SourcePointer >> > >> > WHYYY??Â why it is answering #SourcePointer instead of >> > #VarLengthSourcePointerÂ ?? >> > >> > grrr how can that be possible???Â It happens the same to each of the >> > CompiledMethods I select as #VarLengthSourcePointer.Â When I then ask >> > the >> > #kindÂ they always answer #SourcePointerÂ instead of >> > #VarLengthSourcePointer >> > >> is it same compiled methods? >> Because it is absolutely normal if they using different source pointer. >> > > I didn't understand your question. Yes, it is exactly the same > CompiledMethod. > Look, if I do: > > (CompiledMethod allInstances select:Â [:each | each trailer kind = > #VarLengthSourcePointer] ) first > > I get > ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") > > So...it means that such CompiledMethod answers #VarLengthSourcePointer when > send "trailer kind". Ok? > > But immediatly after, if I ask the trailer kind to the SAME compiled method: > > (CodeLoader class >> #initialize) trailer kind > > I get > ----> #SourcePointer > > WHYYY??Â why it is answering #SourcePointer instead of > #VarLengthSourcePointerÂ ?? > Its not the same. Look: (CompiledMethod allInstances select: [:each | each trailer kind = #VarLengthSourcePointer] ) first == (CodeLoader class>>#initialize ) answers false. Which means that there are two instances of CompiledMethod. One is installed into a class, and another hangs somewhere.. -- Best regards, Igor Stasenko AKA sig.

May 9, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Henrik Sperre Johansen

On 09.05.2011 09:36, Mariano Martinez Peck wrote: > > > On Mon, May 9, 2011 at 6:14 AM, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > On 9 May 2011 00:52, Mariano Martinez Peck <marianopeck(a)gmail.com > <mailto:marianopeck@gmail.com>> wrote: > > Hi guys, Maybe it is too late and I am not seeing something > obvious...so > > another look is really appreciated. If I do: > > > > (CompiledMethod allInstances select: [:each | each trailer kind = > > #VarLengthSourcePointer] ) first > > ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") > > > > But then: > > > > (CodeLoader class >> #initialize) trailer kind > > ----> #SourcePointer > > > > WHYYY?? why it is answering #SourcePointer instead of > > #VarLengthSourcePointer ?? > > > > grrr how can that be possible??? It happens the same to each of the > > CompiledMethods I select as #VarLengthSourcePointer. When I > then ask the > > #kind they always answer #SourcePointer instead of > #VarLengthSourcePointer > > > is it same compiled methods? > Because it is absolutely normal if they using different source > pointer. > > > I didn't understand your question. Yes, it is exactly the same > CompiledMethod. He's asking if they ARE the same (CodeLoader class >> #initialize) == (CompiledMethod allInstances select: [:each | each trailer kind = #VarLengthSourcePointer] ) first) ? Just because the CompiledMethds class and selector matches so its printstring will be 'SomeClass>>#someSelector', does not necessarily mean it is the one currently installed in the method dictionary. Cheers, Henry

May 9, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Mariano Martinez Peck

On Mon, May 9, 2011 at 6:14 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 May 2011 00:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi guys, Maybe it is too late and I am not seeing something obvious...so > > another look is really appreciated. If I do: > > > > (CompiledMethod allInstances select: [:each | each trailer kind = > > #VarLengthSourcePointer] ) first > > ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") > > > > But then: > > > > (CodeLoader class >> #initialize) trailer kind > > ----> #SourcePointer > > > > WHYYY?? why it is answering #SourcePointer instead of > > #VarLengthSourcePointer ?? > > > > grrr how can that be possible??? It happens the same to each of the > > CompiledMethods I select as #VarLengthSourcePointer. When I then ask the > > #kind they always answer #SourcePointer instead of > #VarLengthSourcePointer > > > is it same compiled methods? > Because it is absolutely normal if they using different source pointer. > > I didn't understand your question. Yes, it is exactly the same CompiledMethod. Look, if I do: (CompiledMethod allInstances select: [:each | each trailer kind = #VarLengthSourcePointer] ) first I get ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") So...it means that such CompiledMethod answers #VarLengthSourcePointer when send "trailer kind". Ok? But immediatly after, if I ask the trailer kind to the SAME compiled method: (CodeLoader class >> #initialize) trailer kind I get ----> #SourcePointer WHYYY?? why it is answering #SourcePointer instead of #VarLengthSourcePointer ?? > > > thanks in advance, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

May 9, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

On 9 May 2011 00:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, Maybe it is too late and I am not seeing something obvious...so > another look is really appreciated. If I do: > > (CompiledMethod allInstances select:Â [:each | each trailer kind = > #VarLengthSourcePointer] ) first > ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") > > But then: > > (CodeLoader class >> #initialize) trailer kind > ----> #SourcePointer > > WHYYY??Â why it is answering #SourcePointer instead of > #VarLengthSourcePointerÂ ?? > > grrr how can that be possible???Â It happens the same to each of the > CompiledMethods I select as #VarLengthSourcePointer.Â When I then ask the > #kindÂ they always answer #SourcePointerÂ instead of #VarLengthSourcePointer > is it same compiled methods? Because it is absolutely normal if they using different source pointer. > thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

May 9, 2011

[Pharo-project] Problem with CompiledMethodTrailer

by Mariano Martinez Peck

Hi guys, Maybe it is too late and I am not seeing something obvious...so another look is really appreciated. If I do: (CompiledMethod allInstances select: [:each | each trailer kind = #VarLengthSourcePointer] ) first ---> (CodeLoader class>>#initialize "a CompiledMethod(311951360)") But then: (CodeLoader class >> #initialize) trailer kind ----> #SourcePointer WHYYY?? why it is answering #SourcePointer instead of #VarLengthSourcePointer ?? grrr how can that be possible??? It happens the same to each of the CompiledMethods I select as #VarLengthSourcePointer. When I then ask the #kind they always answer #SourcePointer instead of #VarLengthSourcePointer thanks in advance, -- Mariano http://marianopeck.wordpress.com

May 9, 2011

[Pharo-project] Cannot abandon sources with CogVM

by Mariano Martinez Peck

Hi. If I take any PharoCore 1.3 image and evaluate: Smalltalk abandonSources I have two errors and the image is frozen. I cannot interrupt it and I have to force a quite. Two erros pops up: the first one says "computation has been terminated" and the second one is a stacktrace which message: "UndefinedObject(Object)>>doesNotUnderstand: #findNextHandlerContextStarting" This seems similar to the problem we have with the DebuggerMethodMap trying to build a dev image: http://code.google.com/p/pharo/issues/detail?id=4087 At least this time it is easier to reproduce ;) I attach PharoDebug.log. With the Interpreter VM it works correctly. Thanks -- Mariano http://marianopeck.wordpress.com

May 8, 2011

Re: [Pharo-project] If sources file is not present, something bad happens

by StÃ©phane Ducasse

We will check that. I know that we should condense the changes to see if we can make it. I know that there was a problem the last time I tried. stef On May 8, 2011, at 9:50 PM, Mariano Martinez Peck wrote: > Hi guys. In pharo 1.1, 1.2 (in fact, always) one could decide not to use the .sources file and instead decompile. At startup the image raises a popup saying "ehhhh the .sources couludnt be found" and then after, when you browse a method you see the decompiled code. > > Now, in Pharo 1.3 I REMOVE all possible .sources and the image doesn't say anything at startup. No popup. If I print SourceFiles I get -> an ExpandedSourceFileArray(nil MultiByteFileStream: '/Users/mariano/Pharo/imagenes/PharoCore-1.2/PharoCore-1.2.changes') So...the sources is not there. Two problems: > > 1) the first one is that the popup doesn't raise. > > 2) I cannot browse methods because a popup raises saying there was a probelm with the sources file: "There may be a problem with your sources file!". > > I attach screenshot. > > So...what could be happening? I will try to debug it... If someone can confirm please I open an ticket. > > -- > Mariano > http://marianopeck.wordpress.com > > <Screen shot 2011-05-08 at 9.49.04 PM.png>

May 8, 2011

[Pharo-project] If sources file is not present, something bad happens

by Mariano Martinez Peck

Hi guys. In pharo 1.1, 1.2 (in fact, always) one could decide not to use the .sources file and instead decompile. At startup the image raises a popup saying "ehhhh the .sources couludnt be found" and then after, when you browse a method you see the decompiled code. Now, in Pharo 1.3 I REMOVE all possible .sources and the image doesn't say anything at startup. No popup. If I print SourceFiles I get -> an ExpandedSourceFileArray(nil MultiByteFileStream: '/Users/mariano/Pharo/imagenes/PharoCore-1.2/PharoCore-1.2.changes') So...the sources is not there. Two problems: 1) the first one is that the popup doesn't raise. 2) I cannot browse methods because a popup raises saying there was a probelm with the sources file: "There may be a problem with your sources file!". I attach screenshot. So...what could be happening? I will try to debug it... If someone can confirm please I open an ticket. -- Mariano http://marianopeck.wordpress.com

May 8, 2011

Re: [Pharo-project] Package validation?

by StÃ©phane Ducasse

On May 8, 2011, at 6:09 PM, Mariano Martinez Peck wrote: > Stef, off-topic question.... When I rename a package from the SystemBrowser, the extension methods' categories are not updated. This is a known problem. I don't know where the rename happens if it is UI or model....but in case it is the model (PackageInfo or RPackage) I would love to have that fixed in RPackage. Yes it will because this is a pain. Probably we should solve it also in MC. May be this is fixed in Squeak. Did you check? I should go over the MC change made by chris but I should find time to do it. Stef > > cheers > > Mariano > > On Sun, May 8, 2011 at 5:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > did one of you wrote a small Package checker that would check: > - that all the methods get a non nil category > - methods belong to a package loaded? > > I experienced a lot of problem with RPackage when loading broken code and > I would like to produce a little tool to validate packages so that we can identify > problems and understand how to solve that in RPackage. > > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 8, 2011

Re: [Pharo-project] Package validation?

by Mariano Martinez Peck

Stef, off-topic question.... When I rename a package from the SystemBrowser, the extension methods' categories are not updated. This is a known problem. I don't know where the rename happens if it is UI or model....but in case it is the model (PackageInfo or RPackage) I would love to have that fixed in RPackage. cheers Mariano On Sun, May 8, 2011 at 5:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > did one of you wrote a small Package checker that would check: > - that all the methods get a non nil category > - methods belong to a package loaded? > > I experienced a lot of problem with RPackage when loading broken code and > I would like to produce a little tool to validate packages so that we can > identify > problems and understand how to solve that in RPackage. > > Stef > -- Mariano http://marianopeck.wordpress.com

May 8, 2011