August 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Thierry Goubier

2015-08-24 16:13 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-08-24 16:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)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(a)stfx.eu>: >> >>> >>> > On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess(a)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(a)gmail.com>: >>> > >>> > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> > >>> > >>> > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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? >>> > >>> >>> >>> >> >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Thierry Goubier

2015-08-24 16:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)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(a)stfx.eu>: > >> >> > On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess(a)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(a)gmail.com>: >> > >> > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> > >> > >> > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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? >> > >> >> >> >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Thierry Goubier

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(a)stfx.eu>: > > > On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess(a)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(a)gmail.com>: > > > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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? > > > > >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Sven Van Caekenberghe

> On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess(a)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(a)gmail.com>: > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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? >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Sven Van Caekenberghe

> On 24 Aug 2015, at 15:24, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-08-24 15:11 GMT+02:00 Sven Van Caekenberghe <sven(a)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(a)gmail.com> wrote: > > > > > > > > > > > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)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(a)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 > > > > > > > > > > > >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Nicolai Hess

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(a)gmail.com>: > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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? >

Aug. 24, 2015

Re: [Pharo-dev] [Vm-dev] New Cog VMs available...

by J. Vuletich (mail lists)

Thanks Eliot! It works great, and indeed it fixes the issue with AndreasSystemProfiler I had reported. Cheers, Juan Vuletich Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Thierry Goubier

2015-08-24 15:11 GMT+02:00 Sven Van Caekenberghe <sven(a)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(a)gmail.com> > wrote: > > > > > > > > > > > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)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(a)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 > > > > > > > > > > > > > > >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Marcus Denker

> On 24 Aug 2015, at 15:06, Martin Dias <tinchodias(a)gmail.com> wrote: > > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Sven Van Caekenberghe

> On 24 Aug 2015, at 14:55, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)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(a)gmail.com> wrote: > > > > > > > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)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(a)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 > > > > > > >

Aug. 24, 2015