Bug in refactoring browser or did I mess up?

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hey Seth,

I haven't used the refactoring browser much so basically I fuddle around until I find something that seems to do what I want.  I loaded the refactoring browser from the "Load/Unload Features..." menu Option of the Organizer window.  I then open it from the Transcript>Tools>Refactoring Browser menu item.  In the refactoring browser window (left pane) I select the sub-application that contains the part.  Then in the next pane I select the part.  Then (from here on out I'm less sure of what I did but..) I right click on the part, on the pop up menu I move to "Instance Variables>Rename As..." and select "Also rename accessors" I think.  Then from the pop up I select the instance variable and change its name.  I think that is it, I don't want to do it again for fear of messing things up.  As I said I think I changed both variables one after the other.  Good hunting.

Lou

On Friday, June 5, 2015 at 1:07:49 PM UTC-4, Seth Berman wrote:

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hi Lou,

I created case 54756: InstVar Rename in Refactoring Browser can produce bytecodes out of sync with source.

Unfortunately, I'm still unable to reproduce this so far.  Looking at the refactoring source...it looks like there is an opportunity for this to happen
if either the compilation of the new source from the referenced methods fails, or a failure to install the updated referenced methods in the manager.

If I can't reproduce this by the time the next release code cut-off is getting near, I'm going to see if I can put gaurds in for the situations I just

described.  Naturally...I would like to see this happen first.

I'm pretty clear now on the class definition aspects...and don't think it has anything to do with this "directly".  I think it has something to do with some "yet to be determined"

property of the methods that reference the inst vars.

If you think there is anything suspect in those methods that reference the inst vars, or if you can think of anything else, please let me know.  Thanks for putting together the information you provided.

-- Seth

On Friday, June 5, 2015 at 1:36:22 PM UTC-4, Louis LaBrunda wrote:

Hey Seth,

I haven't used the refactoring browser much so basically I fuddle around until I find something that seems to do what I want.  I loaded the refactoring browser from the "Load/Unload Features..." menu Option of the Organizer window.  I then open it from the Transcript>Tools>Refactoring Browser menu item.  In the refactoring browser window (left pane) I select the sub-application that contains the part.  Then in the next pane I select the part.  Then (from here on out I'm less sure of what I did but..) I right click on the part, on the pop up menu I move to "Instance Variables>Rename As..." and select "Also rename accessors" I think.  Then from the pop up I select the instance variable and change its name.  I think that is it, I don't want to do it again for fear of messing things up.  As I said I think I changed both variables one after the other.  Good hunting.

Lou

On Friday, June 5, 2015 at 1:07:49 PM UTC-4, Seth Berman wrote:

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hi Seth,

I have looked at the methods that reference the instance variables.  There doesn't look to be anything special or out of the ordinary there.  Both variables get set to new instances of LookupTable.  They are then filled with keys that are symbols and values that are drop down box widgets or text fields obtained with calls like: "self subpartNamed: 'Registration Drop-down List'".  Other methods run the lookup tables and set items in the drop downs and selected items of values in the text fields.  And other read the selections or text values.  Nothing crazy.  I can give you the code if you want it but I doubt it will help.

You mention a compile failure, I don't remember seeing anything like that.

If you want, I will try to reproduce this but I will need to remember to make current backups and such.

Lou

On Monday, June 15, 2015 at 11:21:42 AM UTC-4, Seth Berman wrote:

Hi Lou,

I created case 54756: InstVar Rename in Refactoring Browser can produce bytecodes out of sync with source.

Unfortunately, I'm still unable to reproduce this so far.  Looking at the refactoring source...it looks like there is an opportunity for this to happen
if either the compilation of the new source from the referenced methods fails, or a failure to install the updated referenced methods in the manager.

If I can't reproduce this by the time the next release code cut-off is getting near, I'm going to see if I can put gaurds in for the situations I just

described.  Naturally...I would like to see this happen first.

I'm pretty clear now on the class definition aspects...and don't think it has anything to do with this "directly".  I think it has something to do with some "yet to be determined"

property of the methods that reference the inst vars.

If you think there is anything suspect in those methods that reference the inst vars, or if you can think of anything else, please let me know.  Thanks for putting together the information you provided.

-- Seth

On Friday, June 5, 2015 at 1:36:22 PM UTC-4, Louis LaBrunda wrote:

Hey Seth,

I haven't used the refactoring browser much so basically I fuddle around until I find something that seems to do what I want.  I loaded the refactoring browser from the "Load/Unload Features..." menu Option of the Organizer window.  I then open it from the Transcript>Tools>Refactoring Browser menu item.  In the refactoring browser window (left pane) I select the sub-application that contains the part.  Then in the next pane I select the part.  Then (from here on out I'm less sure of what I did but..) I right click on the part, on the pop up menu I move to "Instance Variables>Rename As..." and select "Also rename accessors" I think.  Then from the pop up I select the instance variable and change its name.  I think that is it, I don't want to do it again for fear of messing things up.  As I said I think I changed both variables one after the other.  Good hunting.

Lou

On Friday, June 5, 2015 at 1:07:49 PM UTC-4, Seth Berman wrote:

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

As Seth mentions, I've seen this a few times. I also couldn't find any pattern that might lead to the problem. It happens rarely, and every time I saw it, once I understood it is that exact problem, just changing the getter and setter by entering a space and saving the method healed the problem immediately. I once event tried loading the broken class into another image, and even there the problem would show up until the methods get recompiled.

Not sure what that means, but it could mean almost anything from some pointer problem in the Library to a Compiler bug. All that's clear is that it is not happening often and that it can take you quite a while to find the reason for strange effects, because even debugging into that wrong setter seems to work, but the variable holds the wrong value afterwards...





Am Dienstag, 16. Juni 2015 18:57:41 UTC+2 schrieb Seth Berman:

Hi Lou,

Given that I've done 100+ trials of instvar refactoring in every different way I can think of...I'll take anything:)  And I'm not questioning the existence because I have seen it once, and I know another team member and Joachim have too.  If you wouldn't mind...could you send whatever you are willing to share to vast support and I will pick it up.  Thanks again for the info!

-- Seth

On Tuesday, June 16, 2015 at 11:57:09 AM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I have looked at the methods that reference the instance variables.  There doesn't look to be anything special or out of the ordinary there.  Both variables get set to new instances of LookupTable.  They are then filled with keys that are symbols and values that are drop down box widgets or text fields obtained with calls like: "self subpartNamed: 'Registration Drop-down List'".  Other methods run the lookup tables and set items in the drop downs and selected items of values in the text fields.  And other read the selections or text values.  Nothing crazy.  I can give you the code if you want it but I doubt it will help.

You mention a compile failure, I don't remember seeing anything like that.

If you want, I will try to reproduce this but I will need to remember to make current backups and such.

Lou

On Monday, June 15, 2015 at 11:21:42 AM UTC-4, Seth Berman wrote:

Hi Lou,

I created case 54756: InstVar Rename in Refactoring Browser can produce bytecodes out of sync with source.

Unfortunately, I'm still unable to reproduce this so far.  Looking at the refactoring source...it looks like there is an opportunity for this to happen
if either the compilation of the new source from the referenced methods fails, or a failure to install the updated referenced methods in the manager.

If I can't reproduce this by the time the next release code cut-off is getting near, I'm going to see if I can put gaurds in for the situations I just

described.  Naturally...I would like to see this happen first.

I'm pretty clear now on the class definition aspects...and don't think it has anything to do with this "directly".  I think it has something to do with some "yet to be determined"

property of the methods that reference the inst vars.

If you think there is anything suspect in those methods that reference the inst vars, or if you can think of anything else, please let me know.  Thanks for putting together the information you provided.

-- Seth

On Friday, June 5, 2015 at 1:36:22 PM UTC-4, Louis LaBrunda wrote:

Hey Seth,

I haven't used the refactoring browser much so basically I fuddle around until I find something that seems to do what I want.  I loaded the refactoring browser from the "Load/Unload Features..." menu Option of the Organizer window.  I then open it from the Transcript>Tools>Refactoring Browser menu item.  In the refactoring browser window (left pane) I select the sub-application that contains the part.  Then in the next pane I select the part.  Then (from here on out I'm less sure of what I did but..) I right click on the part, on the pop up menu I move to "Instance Variables>Rename As..." and select "Also rename accessors" I think.  Then from the pop up I select the instance variable and change its name.  I think that is it, I don't want to do it again for fear of messing things up.  As I said I think I changed both variables one after the other.  Good hunting.

Lou

On Friday, June 5, 2015 at 1:07:49 PM UTC-4, Seth Berman wrote:

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hi Lou,

Given that I've done 100+ trials of instvar refactoring in every different way I can think of...I'll take anything:)  And I'm not questioning the existence because I have seen it once, and I know another team member and Joachim have too.  If you wouldn't mind...could you send whatever you are willing to share to vast support and I will pick it up.  Thanks again for the info!

-- Seth

On Tuesday, June 16, 2015 at 11:57:09 AM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I have looked at the methods that reference the instance variables.  There doesn't look to be anything special or out of the ordinary there.  Both variables get set to new instances of LookupTable.  They are then filled with keys that are symbols and values that are drop down box widgets or text fields obtained with calls like: "self subpartNamed: 'Registration Drop-down List'".  Other methods run the lookup tables and set items in the drop downs and selected items of values in the text fields.  And other read the selections or text values.  Nothing crazy.  I can give you the code if you want it but I doubt it will help.

You mention a compile failure, I don't remember seeing anything like that.

If you want, I will try to reproduce this but I will need to remember to make current backups and such.

Lou

On Monday, June 15, 2015 at 11:21:42 AM UTC-4, Seth Berman wrote:

Hi Lou,

I created case 54756: InstVar Rename in Refactoring Browser can produce bytecodes out of sync with source.

Unfortunately, I'm still unable to reproduce this so far.  Looking at the refactoring source...it looks like there is an opportunity for this to happen
if either the compilation of the new source from the referenced methods fails, or a failure to install the updated referenced methods in the manager.

If I can't reproduce this by the time the next release code cut-off is getting near, I'm going to see if I can put gaurds in for the situations I just

described.  Naturally...I would like to see this happen first.

I'm pretty clear now on the class definition aspects...and don't think it has anything to do with this "directly".  I think it has something to do with some "yet to be determined"

property of the methods that reference the inst vars.

If you think there is anything suspect in those methods that reference the inst vars, or if you can think of anything else, please let me know.  Thanks for putting together the information you provided.

-- Seth

On Friday, June 5, 2015 at 1:36:22 PM UTC-4, Louis LaBrunda wrote:

Hey Seth,

I haven't used the refactoring browser much so basically I fuddle around until I find something that seems to do what I want.  I loaded the refactoring browser from the "Load/Unload Features..." menu Option of the Organizer window.  I then open it from the Transcript>Tools>Refactoring Browser menu item.  In the refactoring browser window (left pane) I select the sub-application that contains the part.  Then in the next pane I select the part.  Then (from here on out I'm less sure of what I did but..) I right click on the part, on the pop up menu I move to "Instance Variables>Rename As..." and select "Also rename accessors" I think.  Then from the pop up I select the instance variable and change its name.  I think that is it, I don't want to do it again for fear of messing things up.  As I said I think I changed both variables one after the other.  Good hunting.

Lou

On Friday, June 5, 2015 at 1:07:49 PM UTC-4, Seth Berman wrote:

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou

Hey Seth,

Well, I'm sorry to say that I too have been unable to reproduce the problem.  I did what I had done before as close as I could remember but everything worked just fine.

Of course the library and image have changed since the problem and I'm not sure how I could get it back to that state so as to repeat the process exactly or even close.

I'm sure you want to fix this and I would love to help but I don't know what else to try and even if I'm able to reproduce it, I doubt you would be able to follow my steps and reproduce it even if I gave you my image and library (which I would do if it would help).

Joachim says forcing a recompile by changing a method slightly, fixes the problem.  I tried to fix it by forcing a recompile by changing the object definition slightly but that didn't fix it.  Anyway since I now know what is going on and hopefully how to fix it, I will pay close attention when using the refactoring browser to rename instance variables.

Thanks and good luck!

Lou

On Tuesday, June 16, 2015 at 12:57:41 PM UTC-4, Seth Berman wrote:

Hi Lou,

Given that I've done 100+ trials of instvar refactoring in every different way I can think of...I'll take anything:)  And I'm not questioning the existence because I have seen it once, and I know another team member and Joachim have too.  If you wouldn't mind...could you send whatever you are willing to share to vast support and I will pick it up.  Thanks again for the info!

-- Seth

On Tuesday, June 16, 2015 at 11:57:09 AM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I have looked at the methods that reference the instance variables.  There doesn't look to be anything special or out of the ordinary there.  Both variables get set to new instances of LookupTable.  They are then filled with keys that are symbols and values that are drop down box widgets or text fields obtained with calls like: "self subpartNamed: 'Registration Drop-down List'".  Other methods run the lookup tables and set items in the drop downs and selected items of values in the text fields.  And other read the selections or text values.  Nothing crazy.  I can give you the code if you want it but I doubt it will help.

You mention a compile failure, I don't remember seeing anything like that.

If you want, I will try to reproduce this but I will need to remember to make current backups and such.

Lou

On Monday, June 15, 2015 at 11:21:42 AM UTC-4, Seth Berman wrote:

Hi Lou,

I created case 54756: InstVar Rename in Refactoring Browser can produce bytecodes out of sync with source.

Unfortunately, I'm still unable to reproduce this so far.  Looking at the refactoring source...it looks like there is an opportunity for this to happen
if either the compilation of the new source from the referenced methods fails, or a failure to install the updated referenced methods in the manager.

If I can't reproduce this by the time the next release code cut-off is getting near, I'm going to see if I can put gaurds in for the situations I just

described.  Naturally...I would like to see this happen first.

I'm pretty clear now on the class definition aspects...and don't think it has anything to do with this "directly".  I think it has something to do with some "yet to be determined"

property of the methods that reference the inst vars.

If you think there is anything suspect in those methods that reference the inst vars, or if you can think of anything else, please let me know.  Thanks for putting together the information you provided.

-- Seth

On Friday, June 5, 2015 at 1:36:22 PM UTC-4, Louis LaBrunda wrote:

Hey Seth,

I haven't used the refactoring browser much so basically I fuddle around until I find something that seems to do what I want.  I loaded the refactoring browser from the "Load/Unload Features..." menu Option of the Organizer window.  I then open it from the Transcript>Tools>Refactoring Browser menu item.  In the refactoring browser window (left pane) I select the sub-application that contains the part.  Then in the next pane I select the part.  Then (from here on out I'm less sure of what I did but..) I right click on the part, on the pop up menu I move to "Instance Variables>Rename As..." and select "Also rename accessors" I think.  Then from the pop up I select the instance variable and change its name.  I think that is it, I don't want to do it again for fear of messing things up.  As I said I think I changed both variables one after the other.  Good hunting.

Lou

On Friday, June 5, 2015 at 1:07:49 PM UTC-4, Seth Berman wrote:

Hi Lou,

I'm still having difficulty duplicating.

Perhaps you could tell me how you request the rename of a variable.

So I right-click in the application manager and select "Refactor Class"

From here, I have tried both the following to initiate a rename

1. Double-click an inst var in the refactoring browser, bring up a context menu, and select Variables->Rename As...->Also Rename Accessors.
2. Also the Class Menu at the top->Instance Variables....->Rename As...->Also Rename Accessors.

Is one of these how you are doing it or do you do something else?

Thanks for your assistance on this...its come down to a very specific workflow which I'm trying to narrow it down to.
I believe your reshuffling of the inst vars forces a recompile of all the methods that access the inst vars which then rewrites the bytecodes correctly.

There is some type of workflow where the request to recompile the methods is not happening...which leaves behind the old bytecodes which reference inst vars in the slot they were at.

-- Seth

On Friday, June 5, 2015 at 12:39:39 PM UTC-4, Louis LaBrunda wrote:

I think I said with accessors but it didn't have any.

On Friday, June 5, 2015 at 12:20:59 PM UTC-4, Seth Berman wrote:

Thanks Lou....this is good detail.

One more question...did you rename with accessors....or just rename?

On Friday, June 5, 2015 at 12:14:46 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

I will do my best to help as much as I can.  I renamed delDropDownsByToken to delvDropDownsByToken and delTextFieldsByToken to delvTextFieldsByToken.  I don't remember if I did anything in between the two renames, not much if anything.   The instance variables with *By* in the name are LookupTables.  #trailerFields is an Array and its values ended up in one of the two renamed lookup tables.

I think many Smalltalks keep instance variables in the object and access them as if it is an array so I would guess that whatever code accesses then didn't get updated until I changed the order.  I would think that forcing a compile would fix things but it didn't until I moved them around.

Before rename:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delDropDownsByToken textFieldsByToken delTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

After rename but before fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken textFieldsByToken transaction trailerFields delvDropDownsByToken delvTextFieldsByToken '

    classVariableNames: ''

    poolDictionaries: ''

After fix:

AbtAppBldrView subclass: #Pivot2OrderDetailTokensBaseWindow

    classInstanceVariableNames: ''

    instanceVariableNames: 'changed row dropDownsByToken delvDropDownsByToken textFieldsByToken delvTextFieldsByToken transaction trailerFields '

    classVariableNames: ''

    poolDictionaries: ''

Lou

On Friday, June 5, 2015 at 11:57:38 AM UTC-4, Seth Berman wrote:

Hi Lou,

In this case all the details you can provide do matter:)  I've been trying to trace this down for quite some time.

I know these kinds of details are probably not things you would keep in your head for too long (I wouldn't), but can you provide me the specifics of the class layout and what you did.

I will subclass AbtAppBldrView with a test class, but could you provide me the class layout?  I don't need the exact names, but I'm looking for

1. Class definition details...Inst vars, class vars, class inst vars, pool vars, superclass (which you provided)

2. What instance variable did you rename...or more importantly...what was it's position in the instance variable list.

3.  Anything you can tell me about the workflow you used (i.e. so you used the actual refactoring browser...not the menu hooks injected into the standard browser?)

Thanks...I hope to squash this one soon

-- Seth

On Friday, June 5, 2015 at 11:43:22 AM UTC-4, Louis LaBrunda wrote:

Hi Gang,

Yesterday I used the refactoring browser to rename two instance variables in an object.  This was in VA Smalltalk V8.6.1.  The object is a sub-class of 

AbtAppBldrView.  I don't think that matters but there it is anyway.

The rename seem to work fine until I tested things.  The values that I was assigning some of the variables ended up in the wrong variable.  I tried making a slight change to the Class Definition to force a compile which also seemed to work just fine but didn't fix the problem.  I noticed the order of the instance variables was different after the rename, so I put them back the way they were.  I don't think that should matter but it fixed the problem.

So, did I mess up and leave out a step or something or did the refactoring browser mess up?

Lou