Worrying issue re compilation in Pharo 1.4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Worrying issue re compilation in Pharo 1.4

Graham McLeod
Hi Guys

I am trying to use  Pharo1.4  Latest update: #14438 as downloaded in the
Moose 4.7 image.
I am loving most of the changes and system tools - well done all!

But

I am coming up with a worrying bug where there is a difference between
Source code and decompiled source code.
Specifically, this occurs with two set methods which point to the wrong
instance variable slot.
So, when the code runs, the wrong variables are updated.

Here is an example:

Class definition:
     Thing subclass: #Relationship
     instanceVariableNames: 'context fromNode properties relType toNode'
     classVariableNames: ''
     poolDictionaries: ''
     category: 'Sapiento'

Source Code:
     relType: anObject
     relType := anObject
Byte Codes:
     13 <10> pushTemp: 0
     14 <62> popIntoRcvr: 2
     15 <78> returnSelf
Decompiled Code:
     relType: anObject
     properties := anObject

NOTE: properties is updated instead of relType.

I may have added a new instance variable since the original class
definition.
Are there known issues / available fixes around this?

Please advise
Thanks in advance.

Graham


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

mcleod.vcf (559 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Marcus Denker-4

On Jun 25, 2012, at 1:22 AM, Graham McLeod wrote:

>
> Here is an example:
>
> Class definition:
>    Thing subclass: #Relationship
>    instanceVariableNames: 'context fromNode properties relType toNode'
>    classVariableNames: ''
>    poolDictionaries: ''
>    category: 'Sapiento'
>
> Source Code:
>    relType: anObject
>    relType := anObject
> Byte Codes:
>    13 <10> pushTemp: 0
>    14 <62> popIntoRcvr: 2
>    15 <78> returnSelf
> Decompiled Code:
>    relType: anObject
>    properties := anObject
>
> NOTE: properties is updated instead of relType.
>

It seems that the method has not been recompiled correctly when you added instance variables.

The decompiled code and the bytecode are in sync:   14 <62> popIntoRcvr: 2 is storing into
the properties instance variable, and the decompiled code shows it correctly.
But the bytecode should have been regenerated and do  14 <62> popIntoRcvr: 3

So the bug is definitly related to not recompiling the methods after the shape of the class was changed.

        Marcus


--
Marcus Denker -- http://marcusdenker.de


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Graham McLeod
Hi Marcus,

Your answer is as I suspected.
The suggestion to add an instance variable, forcing a recompile, from Andrew P Black, seems to resolve the problem..
There still remains the question of how the system allowed the situation to arise in the first place tho..

Thanks for the help.
KR
Graham

Marcus Denker wrote:
On Jun 25, 2012, at 1:22 AM, Graham McLeod wrote:
Here is an example:

Class definition:
   Thing subclass: #Relationship
   instanceVariableNames: 'context fromNode properties relType toNode'
   classVariableNames: ''
   poolDictionaries: ''
   category: 'Sapiento'

Source Code:
   relType: anObject
   relType := anObject
Byte Codes:
   13 <10> pushTemp: 0
   14 <62> popIntoRcvr: 2
   15 <78> returnSelf
Decompiled Code:
   relType: anObject
   properties := anObject

NOTE: properties is updated instead of relType.


It seems that the method has not been recompiled correctly when you added instance variables.

The decompiled code and the bytecode are in sync:   14 <62> popIntoRcvr: 2 is storing into 
the properties instance variable, and the decompiled code shows it correctly. 
But the bytecode should have been regenerated and do  14 <62> popIntoRcvr: 3

So the bug is definitly related to not recompiling the methods after the shape of the class was changed.

	Marcus


--
Marcus Denker -- http://marcusdenker.de



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

mcleod.vcf (559 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Prof. Andrew P. Black

On 25 Jun 2012, at 08:50 , Graham McLeod wrote:

> There still remains the question of how the system allowed the situation to arise in the first place tho..

Indeed: this should never happen.  So, if you can reproduce the problem, you should report it as a bug in the 1.4 bug tracker.

http://code.google.com/p/pharo/issues/list

        Andrew


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Marcus Denker-4

On Jun 26, 2012, at 7:04 PM, Andrew P. Black wrote:

>
> On 25 Jun 2012, at 08:50 , Graham McLeod wrote:
>
>> There still remains the question of how the system allowed the situation to arise in the first place tho..
>
> Indeed: this should never happen.  So, if you can reproduce the problem, you should report it as a bug in the 1.4 bug tracker.
>
> http://code.google.com/p/pharo/issues/list
>
Yes! As far as I know, there is no bug reported regarding any problems with this... we are, though, completely rewriting this
part of the system for 2.0:
        -> the old system change notifycation mechanism will be replaced with a new system base on Announcements.
        -> the old class builder will be replaced by one based on the work in the context of first class Slots
                (see the OOPSLA Paper of Toon and Camillo: http://scg.unibe.ch/scgbib?query=Verw11b&display=abstract )
        -> instead of recompiling, we will just change the offsets of the iVars on the level of the bytecode intermediate representation
             of the new pharo compiler.

This is not yet in 2.0... but we are woking on it.

        Marcus


--
Marcus Denker -- http://marcusdenker.de


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Philippe Marschall
On Tue, Jun 26, 2012 at 7:49 PM, Marcus Denker <[hidden email]> wrote:

>
> On Jun 26, 2012, at 7:04 PM, Andrew P. Black wrote:
>
>>
>> On 25 Jun 2012, at 08:50 , Graham McLeod wrote:
>>
>>> There still remains the question of how the system allowed the situation to arise in the first place tho..
>>
>> Indeed: this should never happen.  So, if you can reproduce the problem, you should report it as a bug in the 1.4 bug tracker.
>>
>> http://code.google.com/p/pharo/issues/list
>>
> Yes! As far as I know, there is no bug reported regarding any problems with this... we are, though, completely rewriting this
> part of the system for 2.0:
>        -> the old system change notifycation mechanism will be replaced with a new system base on Announcements.
>        -> the old class builder will be replaced by one based on the work in the context of first class Slots
>                (see the OOPSLA Paper of Toon and Camillo: http://scg.unibe.ch/scgbib?query=Verw11b&display=abstract )
>        -> instead of recompiling, we will just change the offsets of the iVars on the level of the bytecode intermediate representation
>             of the new pharo compiler.

Nice!

Cheers
Philippe

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Graham McLeod
Thanks all.
I have not been able to reproduce the problem.
It may have been a unique sequence of actions unlikely to recur.
The new strategy sounds good.

KR
Graham

Philippe Marschall wrote:
On Tue, Jun 26, 2012 at 7:49 PM, Marcus Denker [hidden email] wrote:
On Jun 26, 2012, at 7:04 PM, Andrew P. Black wrote:

On 25 Jun 2012, at 08:50 , Graham McLeod wrote:

There still remains the question of how the system allowed the situation to arise in the first place tho..
Indeed: this should never happen.  So, if you can reproduce the problem, you should report it as a bug in the 1.4 bug tracker.

http://code.google.com/p/pharo/issues/list

Yes! As far as I know, there is no bug reported regarding any problems with this... we are, though, completely rewriting this
part of the system for 2.0:
       -> the old system change notifycation mechanism will be replaced with a new system base on Announcements.
       -> the old class builder will be replaced by one based on the work in the context of first class Slots
               (see the OOPSLA Paper of Toon and Camillo: http://scg.unibe.ch/scgbib?query=Verw11b&display=abstract )
       -> instead of recompiling, we will just change the offsets of the iVars on the level of the bytecode intermediate representation
            of the new pharo compiler.

Nice!

Cheers
Philippe

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

mcleod.vcf (768 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Worrying issue re compilation in Pharo 1.4

Richard Sargent (again)
I can recall seeing a problem similar to this some years ago in VisualAge Smalltalk. VisualAge Smalltalk uses the ENVY version control system (I think very highly of it!). I was able to determine what the developer had done "wrong", so it is possible that something similar exists with Pharo.
 
Specifically, if one browses the differences between the currently loaded edition and another version, one could have an opportunity to load the alternate edition of the class definition itself through the Differences Browser. I found that this failed to recompile the methods, and resulted in methods referring to wrong the wrong instance variable offsets.
 
I know nothing about Pharo, what version control it has, and what change browsing capabilities it has. So, I cannot say that it is the same problem, just that it is a possibility.
 
 
Good luck,
Richard


From: Graham McLeod [mailto:[hidden email]]
Sent: June-27-12 1:34 AM
To: Philippe Marschall
Cc: ESUG Mailing list; Andrew P. Black
Subject: Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

Thanks all.
I have not been able to reproduce the problem.
It may have been a unique sequence of actions unlikely to recur.
The new strategy sounds good.

KR
Graham

Philippe Marschall wrote:
On Tue, Jun 26, 2012 at 7:49 PM, Marcus Denker [hidden email] wrote:
On Jun 26, 2012, at 7:04 PM, Andrew P. Black wrote:

On 25 Jun 2012, at 08:50 , Graham McLeod wrote:

There still remains the question of how the system allowed the situation to arise in the first place tho..
Indeed: this should never happen.  So, if you can reproduce the problem, you should report it as a bug in the 1.4 bug tracker.

http://code.google.com/p/pharo/issues/list

Yes! As far as I know, there is no bug reported regarding any problems with this... we are, though, completely rewriting this
part of the system for 2.0:
       -> the old system change notifycation mechanism will be replaced with a new system base on Announcements.
       -> the old class builder will be replaced by one based on the work in the context of first class Slots
               (see the OOPSLA Paper of Toon and Camillo: http://scg.unibe.ch/scgbib?query=Verw11b&display=abstract )
       -> instead of recompiling, we will just change the offsets of the iVars on the level of the bytecode intermediate representation
            of the new pharo compiler.

Nice!

Cheers
Philippe

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org