Strange Monticello bug: methods are not saved
Hi, I have a *very* strange bug. I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version): ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ] hash ^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0) Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different. The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot. This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot. I really have no idea what the problem could be. Marcus
On Mon, Aug 24, 2015 at 6:05 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ:
(I copy the new version):
I'm not clear on what you mean by copy. Do you mean you copied the class to MyTemporaryVariable inside the same package? cheers -ben
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
I'm trying on 50264, and, yes, there is something strange: Monticello diff only picks up two of the changes, instead of three. Thierry 2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :( Saved in the package cache and I have everything saved. Some suspicious/wrong data in your image? Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
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.
On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :(
Saved in the package cache and I have everything saved.
Some suspicious/wrong data in your image?
Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>: Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
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.
Ok. Copying in a filetree repo Zinc-Tests-SvenVanCaekenberghe.231 nets me this code testing testUnspecifiedEncoding | json bytes entity | json := '{"text":"Der Weg zur Hölle ist mit guten Vorsätzen gepflastert."}'. entity := ZnEntity with: json type: ZnMimeType applicationJson setCharSetUTF8. bytes := entity asByteArray. ZnDefaultCharacterEncoder value: ZnUTF8Encoder new during: [ entity := ZnEntity readFrom: bytes readStream usingType: ZnMimeType applicationJson andLength: nil. self assert: entity contents equals: json. entity := ZnEntity with: json type: ZnMimeType applicationJson. self assert: entity encoder equals: ZnUTF8Encoder new ] and that timestamp: "testUnspecifiedEncoding" : "SvenVanCaekenberghe 8/24/2015 14:30", But, yes, loading in the image nets me an older version: 5/4/2014, is that what you have? Looks like the MC side is correct (i.e. there is a correct MCMethodDefinition in the system). Has something changed related to code or methods comparisons recently? Thierry
On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :(
Saved in the package cache and I have everything saved.
Some suspicious/wrong data in your image?
Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>: Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
On 24 Aug 2015, at 14:55, 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.
Ok. Copying in a filetree repo Zinc-Tests-SvenVanCaekenberghe.231 nets me this code
testing testUnspecifiedEncoding | json bytes entity | json := '{"text":"Der Weg zur Hölle ist mit guten Vorsätzen gepflastert."}'. entity := ZnEntity with: json type: ZnMimeType applicationJson setCharSetUTF8. bytes := entity asByteArray. ZnDefaultCharacterEncoder value: ZnUTF8Encoder new during: [ entity := ZnEntity readFrom: bytes readStream usingType: ZnMimeType applicationJson andLength: nil. self assert: entity contents equals: json. entity := ZnEntity with: json type: ZnMimeType applicationJson. self assert: entity encoder equals: ZnUTF8Encoder new ]
and that timestamp: "testUnspecifiedEncoding" : "SvenVanCaekenberghe 8/24/2015 14:30",
Yes, that is the correct code with a version dated today.
But, yes, loading in the image nets me an older version: 5/4/2014, is that what you have?
The version dated 5/14/2014 is a wrong one. The version dated 5/2/2015 would be good too. Thanks for having a look, Thierry. It is a good thing if at least file tree does it correctly.
Looks like the MC side is correct (i.e. there is a correct MCMethodDefinition in the system). Has something changed related to code or methods comparisons recently?
Thierry
On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :(
Saved in the package cache and I have everything saved.
Some suspicious/wrong data in your image?
Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>: Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
2015-08-24 15:11 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>: ....
and that timestamp: "testUnspecifiedEncoding" :
"SvenVanCaekenberghe 8/24/2015 14:30",
Yes, that is the correct code with a version dated today.
But, yes, loading in the image nets me an older version: 5/4/2014, is that what you have?
The version dated 5/14/2014 is a wrong one. The version dated 5/2/2015 would be good too.
Thanks for having a look, Thierry. It is a good thing if at least file tree does it correctly.
It is even stranger: now that I get .231 correctly loaded, if I browse changes with 230 in Zn repository, I get 'no changes' ???
Same if I copy .230 and .231 to a gitfiletree repository. Now, copying .228, .229, .230 and .231 under gitfiletree and I loose track of the testUnspecifiedEncoding change; it is associated with .228 which is incorrect. I'll try again.
Looks like the MC side is correct (i.e. there is a correct MCMethodDefinition in the system). Has something changed related to code or methods comparisons recently?
Thierry
On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com : I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :(
Saved in the package cache and I have everything saved.
Some suspicious/wrong data in your image?
Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>: Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
On 24 Aug 2015, at 15:24, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 15:11 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>: ....
and that timestamp: "testUnspecifiedEncoding" : "SvenVanCaekenberghe 8/24/2015 14:30",
Yes, that is the correct code with a version dated today.
But, yes, loading in the image nets me an older version: 5/4/2014, is that what you have?
The version dated 5/14/2014 is a wrong one. The version dated 5/2/2015 would be good too.
Thanks for having a look, Thierry. It is a good thing if at least file tree does it correctly.
It is even stranger: now that I get .231 correctly loaded, if I browse changes with 230 in Zn repository, I get 'no changes' ???
Same if I copy .230 and .231 to a gitfiletree repository.
There is just one difference between those two versions, ZnEntityTests>>#testUnspecifiedEncoding BTW, I committed these from Pharo 3, not 5.
Now, copying .228, .229, .230 and .231 under gitfiletree and I loose track of the testUnspecifiedEncoding change; it is associated with .228 which is incorrect.
I'll try again.
Looks like the MC side is correct (i.e. there is a correct MCMethodDefinition in the system). Has something changed related to code or methods comparisons recently?
Thierry
On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :(
Saved in the package cache and I have everything saved.
Some suspicious/wrong data in your image?
Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>: Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
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? Thierry
On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: I'm trying on 50264, and, yes, there is something strange:
Monticello diff only picks up two of the changes, instead of three.
Ok, by reformatting, ended up with exactly the same code for one of them :(
Saved in the package cache and I have everything saved.
Some suspicious/wrong data in your image?
Thierry
Thierry
2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>: Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
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?
On 24 Aug 2015, at 15:06, Martin Dias <tinchodias@gmail.com> wrote:
On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>: I have to concur, something very strange is wrong.
#50265
Load Zinc-Tests-SvenVanCaekenberghe.231 from http://mc.stfx.eu/ZincHTTPComponents <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?
Only some. I had a slice where it added a method successfully to that class but did not take the three changed ones, while for other classes it was perfectly ok. Marcus
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..... 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?
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?
Hi Nicolai, I think you're right. But why irregular errors? 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?
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?
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.
Wrong result to sameAsMCDefinition: (ZnEntityTests>>#testUnspecifiedEncoding) asRingDefinition sameAsMCDefinition: (MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding) true (ZnEntityTests>>#testUnspecifiedEncoding) asRingDefinition sourceCode = (MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding) source false Ok, have a look at that: sameAsMCDefinition: anMCMethodDefinition ^ anMCMethodDefinition selector = self selector and: [ anMCMethodDefinition className = self className and: [ anMCMethodDefinition classIsMeta = self isMetaSide and: [ anMCMethodDefinition category = self protocol ]]] ... no comment. Thierry
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?
2015-08-24 16:13 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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?
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.
Wrong result to sameAsMCDefinition:
(ZnEntityTests>>#testUnspecifiedEncoding) asRingDefinition sameAsMCDefinition: (MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding) true (ZnEntityTests>>#testUnspecifiedEncoding) asRingDefinition sourceCode = (MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding) source false
Ok, have a look at that:
sameAsMCDefinition: anMCMethodDefinition
^ anMCMethodDefinition selector = self selector and: [ anMCMethodDefinition className = self className and: [ anMCMethodDefinition classIsMeta = self isMetaSide and: [ anMCMethodDefinition category = self protocol ]]]
... no comment.
Changing that to: sameAsMCDefinition: anMCMethodDefinition ^ anMCMethodDefinition selector = self selector and: [ anMCMethodDefinition className = self className and: [ anMCMethodDefinition classIsMeta = self isMetaSide and: [ anMCMethodDefinition category = self protocol and: [ anMCMethodDefinition source = self sourceCode ] ] ] ] (source code comparison added). solves loading Sven test packages. Marcus, can you try on yours? Thierry
Thierry
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?
On 24 Aug 2015, at 16:18, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-08-24 16:13 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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?
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.
Wrong result to sameAsMCDefinition:
(ZnEntityTests>>#testUnspecifiedEncoding) asRingDefinition sameAsMCDefinition: (MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding) true (ZnEntityTests>>#testUnspecifiedEncoding) asRingDefinition sourceCode = (MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding) source false
Ok, have a look at that:
sameAsMCDefinition: anMCMethodDefinition
^ anMCMethodDefinition selector = self selector and: [ anMCMethodDefinition className = self className and: [ anMCMethodDefinition classIsMeta = self isMetaSide and: [ anMCMethodDefinition category = self protocol ]]]
... no comment.
Changing that to: sameAsMCDefinition: anMCMethodDefinition ^ anMCMethodDefinition selector = self selector and: [ anMCMethodDefinition className = self className and: [ anMCMethodDefinition classIsMeta = self isMetaSide and: [ anMCMethodDefinition category = self protocol and: [ anMCMethodDefinition source = self sourceCode ] ] ] ]
(source code comparison added).
solves loading Sven test packages.
Yes, I can confirm that that patch makes the loading work again. Great work !
Marcus, can you try on yours?
Thierry
Thierry
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?
This is really nice to have people like you guys around. This is a really nice example where the sum is more than its elements Stef Le 24/8/15 16:44, Thierry Goubier a écrit :
2015-08-24 16:32 GMT+02:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
> > solves loading Sven test packages. Marcus, can you try on yours? >
Yes! Very good!
Slice pushed to 16358. We'll see what the tests say.
Why has it started to fail? All the involved code is old.
Thierry
Marcus
2015-08-24 18:21 GMT+02:00 stepharo <stepharo@free.fr>:
This is really nice to have people like you guys around. This is a really nice example where the sum is more than its elements
Stef
Le 24/8/15 16:44, Thierry Goubier a écrit :
2015-08-24 16:32 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
solves loading Sven test packages. Marcus, can you try on yours?
Yes! Very good!
Slice pushed to 16358. We'll see what the tests say.
Why has it started to fail? All the involved code is old.
Thierry
Marcus
Great, Thierrys solution works. But I think there is still a problem with RGMethodDefinition. We call self compiledMethod on a RGMethodDefintion, the implementation *always* returns the compiled method from the system, if it exists (regardless whether this ring method is active or not). I think we should either - don't call #compiledMethod on ring definitions - always return nil for not active definitions - for non active definitions: create a compiled method on demand what do you think?
Great, Thierrys solution works.
But I think there is still a problem with RGMethodDefinition. We call self compiledMethod on a RGMethodDefintion, the implementation *always* returns the compiled method from the system, if it exists (regardless whether this ring method is active or not).
I think we should either - don't call #compiledMethod on ring definitions - always return nil for not active definitions - for non active definitions: create a compiled method on demand
what do you think?
Returning nil might be good⦠because non-active ones model methods that are not installed and have no compiled method. But then, the problem is that we use non active Ring definitions as a replacement of what was MethodReference⦠so we need to check if that breaks anything. Another thing we need to check is all uses of Ring: e.g. SystemNavigation. Do we need Ring there? In general, we need to do another pass over Ring in the context of the remote development project. Marcus
2015-08-25 8:19 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
2015-08-24 18:21 GMT+02:00 stepharo <stepharo@free.fr>:
This is really nice to have people like you guys around. This is a really nice example where the sum is more than its elements
Stef
Le 24/8/15 16:44, Thierry Goubier a écrit :
2015-08-24 16:32 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
solves loading Sven test packages. Marcus, can you try on yours?
Yes! Very good!
Slice pushed to 16358. We'll see what the tests say.
Why has it started to fail? All the involved code is old.
Thierry
Marcus
Great, Thierrys solution works.
But I think there is still a problem with RGMethodDefinition. We call self compiledMethod on a RGMethodDefintion, the implementation *always* returns the compiled method from the system, if it exists (regardless whether this ring method is active or not).
I think we should either - don't call #compiledMethod on ring definitions - always return nil for not active definitions - for non active definitions: create a compiled method on demand
what do you think?
It depends what we want Ring to be. If it is a replacement to MCDefinition and all, then it must handle non-active methods. If it models the live system as well, then it must answers compiledMethod. I would choose return nil or return an exception. Third one could be interesting in some contexts... running packages without loading them. But would be hard to do correctly. Thierry
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.
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?
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?
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 <nicolaihess@web.de <mailto:nicolaihess@web.de>>:
2015-08-24 16:07 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto: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 <mailto:sven@stfx.eu>>:
> On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess@web.de <mailto: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 <mailto:tinchodias@gmail.com>>: > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu <mailto: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? >
I know that we got a similar behavior with franck. It looks like the metadata of the package was confused. Stef Le 24/8/15 12:05, Marcus Denker a écrit :
Hi,
I have a *very* strange bug.
I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version):
ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new
removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ]
hash
^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0)
Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different.
The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot.
This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot.
I really have no idea what the problem could be.
Marcus
participants (7)
-
Ben Coman -
Marcus Denker -
Martin Dias -
Nicolai Hess -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier