Smalltalk › Pharo › Pharo Smalltalk Developers

Strange Monticello bug: methods are not saved

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

28 messages Options

Marcus Denker-4

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

Ben Coman

Re: Strange Monticello bug: methods are not saved

On Mon, Aug 24, 2015 at 6:05 PM, Marcus Denker <[hidden email]> 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

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

In reply to this post by Marcus Denker-4

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 <[hidden email]>:

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

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:

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 <[hidden email]>:
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

Sven Van Caekenberghe-2

Re: Strange Monticello bug: methods are not saved

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 <[hidden email]> wrote:
>
>
>
> 2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:
> 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 <[hidden email]>:
> 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
>
>

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

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 <[hidden email]> wrote:
>
>
>
> 2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:
> 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 <[hidden email]>:
> 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
>
>

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

In reply to this post by Sven Van Caekenberghe-2

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

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 <[hidden email]> wrote:
>
>
>
> 2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:
> 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 <[hidden email]>:
> 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
>
>

tinchodias

Re: Strange Monticello bug: methods are not saved

On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
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?

Sven Van Caekenberghe-2

Re: Strange Monticello bug: methods are not saved

In reply to this post by Thierry Goubier

> On 24 Aug 2015, at 14:55, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> 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 <[hidden email]> wrote:
> >
> >
> >
> > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:
> > 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 <[hidden email]>:
> > 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
> >
> >
>
>
>

Marcus Denker-4

Re: Strange Monticello bug: methods are not saved

In reply to this post by tinchodias

On 24 Aug 2015, at 15:06, Martin Dias <[hidden email]> wrote:

On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
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?

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

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

In reply to this post by Sven Van Caekenberghe-2

2015-08-24 15:11 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

....

>
> 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 <[hidden email]> wrote:
> >
> >
> >
> > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:
> > 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 <[hidden email]>:
> > 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
> >
> >
>
>
>

Nicolai Hess

Re: Strange Monticello bug: methods are not saved

In reply to this post by tinchodias

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 <[hidden email]>:

On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
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?

Sven Van Caekenberghe-2

Re: Strange Monticello bug: methods are not saved

In reply to this post by Thierry Goubier

> On 24 Aug 2015, at 15:24, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-08-24 15:11 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> ....
>
> >
> > 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 <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <[hidden email]>:
> > > 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 <[hidden email]>:
> > > 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
> > >
> > >
> >
> >
> >

Sven Van Caekenberghe-2

Re: Strange Monticello bug: methods are not saved

In reply to this post by Nicolai Hess

> On 24 Aug 2015, at 15:31, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
>
> On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:
>
>
> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> 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?
>

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

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.

MCMethodDefinition cachedDefinitions at: ZnEntityTests>>#testUnspecifiedEncoding -> new version

ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition -> old version

ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition asMCMethodDefinition -> new version

not ok.

Thierry

2015-08-24 15:37 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

> On 24 Aug 2015, at 15:31, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
>
> On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:
>
>
> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> 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?
>

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

2015-08-24 16:07 GMT+02:00 Thierry Goubier <[hidden email]>:

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 <[hidden email]>:

> On 24 Aug 2015, at 15:31, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
>
> On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:
>
>
> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> 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?
>

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

2015-08-24 16:13 GMT+02:00 Thierry Goubier <[hidden email]>:

2015-08-24 16:07 GMT+02:00 Thierry Goubier <[hidden email]>:
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 <[hidden email]>:

> On 24 Aug 2015, at 15:31, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
>
> On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:
>
>
> 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> 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?
>

Sven Van Caekenberghe-2

Re: Strange Monticello bug: methods are not saved

> On 24 Aug 2015, at 16:18, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-08-24 16:13 GMT+02:00 Thierry Goubier <[hidden email]>:
>
>
> 2015-08-24 16:07 GMT+02:00 Thierry Goubier <[hidden email]>:
> 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 <[hidden email]>:
>
> > On 24 Aug 2015, at 15:31, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
> >
> > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <[hidden email]> wrote:
> >
> >
> > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> > 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?
> >

Marcus Denker-4

Re: Strange Monticello bug: methods are not saved

In reply to this post by Thierry Goubier

>
> solves loading Sven test packages. Marcus, can you try on yours?
>

Yes! Very good!

Marcus

Thierry Goubier

Re: Strange Monticello bug: methods are not saved

2015-08-24 16:32 GMT+02:00 Marcus Denker <[hidden email]>:

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