indeed we extracted a chunkImporter or something like that out of crappy
code logic.
Le 24/8/15 17:08, Thierry Goubier a écrit :
2015-08-24 16:53 GMT+02:00 Nicolai Hess <[email protected]
<mailto:[email protected]>>:
2015-08-24 16:07 GMT+02:00 Thierry Goubier
<[email protected] <mailto:[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]
<mailto:[email protected]>>:
> On 24 Aug 2015, at 15:31, Nicolai Hess
<[email protected] <mailto:[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] <mailto:[email protected]>>:
>
> On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier
<[email protected]
<mailto:[email protected]>> wrote:
>
>
> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe
<[email protected] <mailto:[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?
>
