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 <[email protected]>: > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < > [email protected]> wrote: > >> >> >> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[email protected]>: >> >>> 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? >
