Can someone look at

RGMethodDefinition>>#asMCMethodDefinition

I think this method uses one cache
(MCMethodDefinition cachedDefinitions)

even for both, methods from the MCPackage and methods from the image package,

of course, they should not be equal. But they are index by the compiledMethod

and this is always the compiled method of the existing method in the image (RGMethodDefinition>>compiledMethod)

But if this is the cause of this bug, I would guess we see much more strange errors.....

2015-08-24 15:06 GMT+02:00 Martin Dias <tinchodias@gmail.com>:

On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
I have to concur, something very strange is wrong.

#50265

Load Zinc-Tests-SvenVanCaekenberghe.231 from http://mc.stfx.eu/ZincHTTPComponents

ZnEntityTests>>#testUnspecifiedEncoding should have today as latest version and it simply does not (the code is wrong too), I can't imagine how that is possible.

And this is with loading code ... seems quite dangerous.

Fun: copying��Zinc-Tests-SvenVanCaekenberghe.231 to a filetree repo, then loading from the filetree is correct, at least for��ZnEntityTests>>#testUnspecifiedEncoding

#50265

Strange. Once the MCDefinitions are loaded (repository type dependent, that), the code path is repository-independent, no?

Strange. Does this happen for all changed methods, or only some of them?