The Inbox: Environments-cmm.52.mcz

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

The Inbox: Environments-cmm.52.mcz

commits-2
A new version of Environments was added to project The Inbox:
http://source.squeak.org/inbox/Environments-cmm.52.mcz

==================== Summary ====================

Name: Environments-cmm.52
Author: cmm
Time: 16 January 2015, 2:40:52.666 pm
UUID: 3da327fd-f1d6-49e1-ac81-0207b9264153
Ancestors: Environments-cmm.51, Environments-nice.47

- Roll back cwp.50 because creating a new binding leaves the CM-literal bindings in their old state.
- Don't signal #binding:removedFrom: because it's becoming the literal in CM's to a newly created Undeclared literal with the old name.
- So since we no longer signal removed: don't signal #binding:addedTo: either.
        Renaming is a updating of a binding, not a removing or adding.

=============== Diff against Environments-cmm.51 ===============

Item was changed:
  ----- Method: Environment>>renameClass:from:to: (in category 'classes and traits') -----
  renameClass: aClass from: oldName to: newName
  "Rename the class, aClass, to have the title newName."
 
  | binding category |
  category := self organization categoryOfElement: oldName.
  self organization classify: newName under: category suppressIfDefault: true.
  self organization removeElement: oldName.
 
+ binding := self associationAt: oldName.
- binding := self declarationOf: oldName.
  declarations removeKey: oldName.
+ " self binding: binding removedFrom: self."
- self binding: binding removedFrom: self.
 
+ binding key: newName.
- binding := newName => aClass.
  declarations add: binding.
+ " self binding: binding addedTo: self."
- self binding: binding addedTo: self.
 
  Smalltalk renamedClass: aClass from: oldName to: newName.
  SystemChangeNotifier uniqueInstance
  classRenamed: aClass
  from: oldName
  to: newName
  inCategory: category!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Chris Muller-3
First fix for problem described in the other thread ("renaming a class
causes invalid super pointer").

This fixes the VM crash but not the issue with the super call
recursion..  Anyone have any ideas about that?  It appears to be a
problem somewhere in ClassBuilder..

On Fri, Jan 16, 2015 at 2:40 PM,  <[hidden email]> wrote:

> A new version of Environments was added to project The Inbox:
> http://source.squeak.org/inbox/Environments-cmm.52.mcz
>
> ==================== Summary ====================
>
> Name: Environments-cmm.52
> Author: cmm
> Time: 16 January 2015, 2:40:52.666 pm
> UUID: 3da327fd-f1d6-49e1-ac81-0207b9264153
> Ancestors: Environments-cmm.51, Environments-nice.47
>
> - Roll back cwp.50 because creating a new binding leaves the CM-literal bindings in their old state.
> - Don't signal #binding:removedFrom: because it's becoming the literal in CM's to a newly created Undeclared literal with the old name.
> - So since we no longer signal removed: don't signal #binding:addedTo: either.
>         Renaming is a updating of a binding, not a removing or adding.
>
> =============== Diff against Environments-cmm.51 ===============
>
> Item was changed:
>   ----- Method: Environment>>renameClass:from:to: (in category 'classes and traits') -----
>   renameClass: aClass from: oldName to: newName
>         "Rename the class, aClass, to have the title newName."
>
>         | binding category |
>         category := self organization categoryOfElement: oldName.
>         self organization classify: newName under: category suppressIfDefault: true.
>         self organization removeElement: oldName.
>
> +       binding := self associationAt: oldName.
> -       binding := self declarationOf: oldName.
>         declarations removeKey: oldName.
> + "     self binding: binding removedFrom: self."
> -       self binding: binding removedFrom: self.
>
> +       binding key: newName.
> -       binding := newName => aClass.
>         declarations add: binding.
> + "     self binding: binding addedTo: self."
> -       self binding: binding addedTo: self.
>
>         Smalltalk renamedClass: aClass from: oldName to: newName.
>         SystemChangeNotifier uniqueInstance
>                 classRenamed: aClass
>                 from: oldName
>                 to: newName
>                 inCategory: category!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Chris Muller-3
After the rename, everything still looks fine.  Bytecodes are exactly
the same, and CM literal binding looks good and subclasses /
superclass structure looks correct.

I can't know what to fix if I can't see what's wrong..



after-rename.png (80K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Tobias Pape
Hey,

On 16.01.2015, at 22:05, Chris Muller <[hidden email]> wrote:

> After the rename, everything still looks fine.  Bytecodes are exactly
> the same, and CM literal binding looks good and subclasses /
> superclass structure looks correct.
>
> I can't know what to fix if I can't see what's wrong..

If this is good, can we backport it to 4.5?

Best
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Chris Muller-3
Of course!  I think everyone who has trunk access probably can copy it to squeak45.  That will make it available via "Update Squeak".

But keep in mind we still have the bug where when we rename a class and then reuse the old name, the image will be hosed.  I need help from Eliot or someone else who knows why the super pointer is jacked.

On Sat, Jan 17, 2015 at 9:23 AM, Tobias Pape <[hidden email]> wrote:
Hey,

On 16.01.2015, at 22:05, Chris Muller <[hidden email]> wrote:

> After the rename, everything still looks fine.  Bytecodes are exactly
> the same, and CM literal binding looks good and subclasses /
> superclass structure looks correct.
>
> I can't know what to fix if I can't see what's wrong..

If this is good, can we backport it to 4.5?

Best
        -Tobias




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Tobias Pape
Hey,

On 18.01.2015, at 01:01, Chris Muller <[hidden email]> wrote:

> Of course!  I think everyone who has trunk access probably can copy it to squeak45.  That will make it available via "Update Squeak".
>

I think copying is not the right way here.
We should really only backport the changes…
Best
        -tobias


> But keep in mind we still have the bug where when we rename a class and then reuse the old name, the image will be hosed.  I need help from Eliot or someone else who knows why the super pointer is jacked.
>
> On Sat, Jan 17, 2015 at 9:23 AM, Tobias Pape <[hidden email]> wrote:
> Hey,
>
> On 16.01.2015, at 22:05, Chris Muller <[hidden email]> wrote:
>
>> After the rename, everything still looks fine.  Bytecodes are exactly
>> the same, and CM literal binding looks good and subclasses /
>> superclass structure looks correct.
>>
>> I can't know what to fix if I can't see what's wrong..
>
> If this is good, can we backport it to 4.5?
>
> Best
>        -Tobias



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Eliot Miranda-2
On Jan 18, 2015, at 6:44 AM, Tobias Pape <[hidden email]> wrote:

> Hey,
>
> On 18.01.2015, at 01:01, Chris Muller <[hidden email]> wrote:
>
>> Of course!  I think everyone who has trunk access probably can copy it to squeak45.  That will make it available via "Update Squeak".
>
> I think copying is not the right way here.
> We should really only backport the changes…

+1.  it makes sense to inly port back fixes to an older version, to keep it as stable as possible.

But we don't have a fix yet, do we?

> Best
>    -tobias
>
>
>> But keep in mind we still have the bug where when we rename a class and then reuse the old name, the image will be hosed.  I need help from Eliot or someone else who knows why the super pointer is jacked.
>>
>> On Sat, Jan 17, 2015 at 9:23 AM, Tobias Pape <[hidden email]> wrote:
>> Hey,
>>
>> On 16.01.2015, at 22:05, Chris Muller <[hidden email]> wrote:
>>
>>> After the rename, everything still looks fine.  Bytecodes are exactly
>>> the same, and CM literal binding looks good and subclasses /
>>> superclass structure looks correct.
>>>
>>> I can't know what to fix if I can't see what's wrong..
>>
>> If this is good, can we backport it to 4.5?
>>
>> Best
>>       -Tobias
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Tobias Pape

On 18.01.2015, at 17:16, Eliot Miranda <[hidden email]> wrote:

> On Jan 18, 2015, at 6:44 AM, Tobias Pape <[hidden email]> wrote:
>
>> Hey,
>>
>> On 18.01.2015, at 01:01, Chris Muller <[hidden email]> wrote:
>>
>>> Of course!  I think everyone who has trunk access probably can copy it to squeak45.  That will make it available via "Update Squeak".
>>
>> I think copying is not the right way here.
>> We should really only backport the changes…
>
> +1.  it makes sense to inly port back fixes to an older version, to keep it as stable as possible.
>
> But we don't have a fix yet, do we?

Partly, if I read Chris’ message right, no?

best
        -tobias

>
>> Best
>>   -tobias
>>
>>
>>> But keep in mind we still have the bug where when we rename a class and then reuse the old name, the image will be hosed.  I need help from Eliot or someone else who knows why the super pointer is jacked.
>>>
>>> On Sat, Jan 17, 2015 at 9:23 AM, Tobias Pape <[hidden email]> wrote:
>>> Hey,
>>>
>>> On 16.01.2015, at 22:05, Chris Muller <[hidden email]> wrote:
>>>
>>>> After the rename, everything still looks fine.  Bytecodes are exactly
>>>> the same, and CM literal binding looks good and subclasses /
>>>> superclass structure looks correct.
>>>>
>>>> I can't know what to fix if I can't see what's wrong..
>>>
>>> If this is good, can we backport it to 4.5?
>>>
>>> Best
>>>      -Tobias



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Chris Muller-4
In reply to this post by Chris Muller-3
On Sun, Jan 18, 2015 at 8:43 AM, Tobias Pape <[hidden email]> wrote:
> Hey,
>
> On 18.01.2015, at 01:01, Chris Muller <[hidden email]> wrote:
>
>> Of course!  I think everyone who has trunk access probably can copy it to squeak45.  That will make it available via "Update Squeak".
>>
>
> I think copying is not the right way here.
> We should really only backport the changes…

Yes absolutely!  Backport is the proper term, not "copy".

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Environments-cmm.52.mcz

Chris Muller-4
In reply to this post by Eliot Miranda-2
On Sun, Jan 18, 2015 at 10:16 AM, Eliot Miranda <[hidden email]> wrote:

> On Jan 18, 2015, at 6:44 AM, Tobias Pape <[hidden email]> wrote:
>
>> Hey,
>>
>> On 18.01.2015, at 01:01, Chris Muller <[hidden email]> wrote:
>>
>>> Of course!  I think everyone who has trunk access probably can copy it to squeak45.  That will make it available via "Update Squeak".
>>
>> I think copying is not the right way here.
>> We should really only backport the changes…
>
> +1.  it makes sense to inly port back fixes to an older version, to keep it as stable as possible.
>
> But we don't have a fix yet, do we?

That's correct, we do not.