Worrying issue re compilation in Pharo 1.4
Locked
Worrying issue re compilation in Pharo 1.4
 
|
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)
Re: Worrying issue re compilation in Pharo 1.4
|
|
Re: Worrying issue re compilation in Pharo 1.4
|
|
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 |
Re: Worrying issue re compilation in Pharo 1.4
|
|
Re: Worrying issue re compilation in Pharo 1.4
|
|
Re: Worrying issue re compilation in Pharo 1.4
|
|
Re: 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/listYes! 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 |
Re: Worrying issue re compilation in Pharo 1.4
|
|
| Free forum by Nabble | Edit this page |