- Esug-list - lists.esug.org

Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

by 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<marcus.denker(a)inria.fr> 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 > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

June 26, 2012

Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

by Philippe Marschall

On Tue, Jun 26, 2012 at 7:49 PM, Marcus Denker <marcus.denker(a)inria.fr> 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

June 26, 2012

Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

by Marcus Denker

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

June 26, 2012

Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

by 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

June 26, 2012

IWST 2012 Best Papers special issue

by Loïc Lagadec

Dear smalltalkers, We are pround to announce that the authors of the best accepted papers of IWST 2012, will also be invited to submit extended versions of their papers for publication in a special issue of Elsevier "Science of Computer Programming : Methods of Software Design: Techniques and Applications" (Impact factor 1.82) IWST 2012 web page: http://www.esug.org/wiki/pier/Conferences/2012/International-Workshop---IWS… Best regards, Program Co-chairs Loïc Lagadec, Alain Plantec Lab-STICC, Université de Bretagne Occidentale

June 26, 2012

Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

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

June 25, 2012

Re: [Esug-list] Worrying issue re compilation in Pharo 1.4

by Marcus Denker

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

June 25, 2012

Worrying issue re compilation in Pharo 1.4

by 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

June 24, 2012

REMINDER: early registration deadline for ESUG is next Saturday (June 30th)

by Johan Brichau

Dear Smalltalkers, The early registration deadline for this year's ESUG conference in Gent, Belgium, is next Saturday (June 30th). Please register for the conference on http://registration.esug.org ! If you have not booked your accomodation yet, please do so before June 30th (all our options at the various hotels expire at that date). Do not hesitate to contact me for further inquiries. Hope to see you in Gent! Johan Brichau

June 23, 2012

Cincom Smalltalk Team is hiring!

by mkobetic＠cincom.com

We're looking for experienced developers with passion for Smalltalk. We're especially interested in candidates that have experience relevant to VM development, or GUI/Tools development. Following link provides information on how to find the descriptions of the openings and how to apply: http://www.cincomsmalltalk.com/main/2012/05/looking-for-a-few-good-smalltal…

June 22, 2012