2015-08-24 16:53 GMT+02:00 Nicolai Hess <[email protected]>: > > > 2015-08-24 16:07 GMT+02:00 Thierry Goubier <[email protected]>: > >> Hi Nicolai, >> >> I think you're right. But why irregular errors? >> > > Good question, important question, because we need to know what may have > been wrongly imported. > > can you check this: > > MCMczReader>>loadDefinitions > definitions := OrderedCollection new. > (self zip memberNamed: 'snapshot.bin') ifNotNil: > [:m | [^ definitions := (MCDataStream on: m contentStream) next > definitions] > on: Error do: [:fallThrough]]. > "otherwise" > (self zip membersMatching: 'snapshot/*') > do: [:m | self extractDefinitionsFrom: m]. > > and replace > on: Error do: [:fallThrough]]. > with > on: Error do: [:fallThrough | self halt]]. > > some package can be loaded without error. But some throwing errors (for > example: Error: Improper store into indexable object) and > the falltrough in the original code follow the > second "otherwise" path, and this is the reason why some package loadings > modify the MCDefinition cache and some not. >
I don't know enough of the adding path to be sure, but I wonder if the use of Ring as an intermediary to and from MCMethodDefinition isn't new, and exercising those paths. You may be pointing something else. A short difference with Pharo4 shows that yes, Pharo5 goes through Ring and not Pharo4. (see MCPackage>>#snapshot, changed in late june) Thierry > > >> >> Ok, for that particular method, with Zinc smalltalkhub repo open and >> Zn-Tests.231 selected (this forces a read of the mcz definitions in the >> image), what I have is: >> >> ZnEntityTests>>#testUnspecifiedEncoding -> old version. >> ok >> MCMethodDefinition cachedDefinitions at: >> ZnEntityTests>>#testUnspecifiedEncoding -> new version >> ok >> ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition -> old version >> ok >> ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition >> asMCMethodDefinition -> new version >> not ok. >> >> Thierry >> >> 2015-08-24 15:37 GMT+02:00 Sven Van Caekenberghe <[email protected]>: >> >>> >>> > 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? >>> > >>> >>> >>> >> >
