2015-08-24 16:53 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
2015-08-24 16:07 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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 <sven@stfx.eu>:
On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess@web.de> 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 <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?