Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom.

There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image.

But no complains , it looks like now the problem is gone.

On Fri, Nov 27, 2015 at 5:26 PM Marcus Denker <marcus.denker@inria.fr> wrote:

> On 27 Nov 2015, at 12:15, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
>
> I found how to easily reproduce it every time
>
> 1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph class, then press enter to open it in browser
> 2) Boom MNU
>
> looking at
> [..] inAstCache
> at: aCompiledMethod
> ^ self at: aCompiledMethod ifAbsentPut:
> [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ]
>
> The problem here is even though aCompiledMethod returns the correct method in this case
>
> Morph>>#addMiscExtrasTo:
>
> the aCompiledMethod parseTree returns nil and this is why it MNUs with doSemanticAnalysisIn: complaining about a nil receiver which is the case
>
>
> anyone have a clue why its nil ?
>
> if I try to browser parseTree it again gives me a MNU and redbox of doom makes it impossible to view the method.
>

I think it happens because the text it reads from the .changes or .sources is somehow corrupted.

We should not return #nil but fall back on the decompiler in #parseTree��

�� Marcus