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.
>
> 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?
>> >
>>
>>
>>
>
