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