> On 24 Aug 2015, at 15:31, Nicolai Hess <[email protected]> wrote: > > 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.....
Well, Stef reported a problem a couple of days ago, then Marcus another one, and now mine. All with versions, changes, code loading. > 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? >
