On 10.04.2013, at 14:31, Bert Freudenberg <bert at freudenbergs.de> wrote:

> 
> On 10.04.2013, at 11:09, Frank Shearar <frank.shearar at gmail.com> wrote:
> 
>> There's an AttemptToWriteReadOnlyGlobal in TestResource >> #setUp,
>> which is a bit strange, given that #setUp is supposed to set up this
>> read only global in the first place.
>> 
>> It looks like TraitResource uses its createdClassesAndTraits instvar
>> to remember what to remove... only it never actually stores any of
>> t1..t6 or c1..c8 in that instvar. So I ripped out the instvar and
>> replaced the createdClassesAndTraits method with one that returns
>> those traits and classes that aren't nil.
>> 
>> That reveals that when the trait's created, computation eventually
>> ends up in Environments >> #at:put:. That calls a block with this:
>> 
>>   binding := aSymbol => anObject.
>>   contents add: binding.
>>   exports bind: binding
>> 
>> and it's in #bind: that the AttemptToWriteReadOnlyGlobal is signalled.
>> And indeed, if we call the Environment in which we're working env,
>> ((env exports instVarNamed: 'namespaces') at: #T1) = AnObsoleteT1.
>> 
>> And now I'm stuck. A BindingPolicy provides no means of removing a
>> binding (and I don't even know if that makes sense).

Well, there must be a way of removing a binding. I just added one in Environments-bf.23.

Not quite sure if it will work correctly if there are renaming imports/exports, but for now it seems to do the job. After removing a class it seems to be gone for good now.

Btw: I find the name "BindingPolicy" to be confusing when looking at the code and seeing an instance variable named "policy" which is a NamePolicy. Maybe something like "BindingStrategy" would be better?

- Bert -

>> frank
>> 
>> PS There is a lot of cruft in the TraitsTestCase, duplicating some of
>> TraitsResource. Cleaning that out doesn't make the problem worse, but
>> I haven't submitted a decrufting fix because I don't want to add
>> noise.)
> 
> I'm running into a very similar-sounding problem (AttemptToWriteReadOnlyGlobal). It appears to be caused by my multiple attempts to load projects, which create new classes. Then I try to remove them, but class removal leaves behind references in some of the environment dictionaries (particularly, in exports and bindings). On the next attempt to create the class, the binding is reused and tried to store into, boom.
> 
> Actually, some recent fix solved this problem for the bindings dictionary, but the exports dictionary still has the obsolete classes in it.
> 
> I attached a small changeset that can remove all these obsolete bindings, but I guess once we fix the class removal problem it is not needed anymore, so I wouldn't add it to trunk.
> 
> - Bert -
> 
> <removeObsoleteBindings-bf.1.cs>