3.11 - File List broken

> On Thu, Feb 11, 2010 at 05:25:17PM +0100, Nicolas Cellier wrote:
>> >
>> 2010/2/11 Chris Muller <[hidden email]>:
>> > Would whoever recently broke the File List please fix it? ?After
>> > having Load Code Updates I can no longer open a File List. ?Thanks..
>> >
>> You may try this:
>>
>> Compiler recompileAll
>
> I think that shifted-yellowButton in the code pane is broken, but
> I did not notice any other problems as of yesterday.
>
> Dave
>

> Nicolas Cellier wrote:
>>
>> Removing FileList/FileList2 then reloading them create obsolete
>> references.
>> Andreas did modify MC to take care not removing moved methods, we
>> should do the same kind of trick for moved classes.
>
> It's not applicable. My fix handled the situation where, after moving a
> method from package OLD to package NEW, you'd load NEW and then OLD and MC
> would remove the method from the image even though it was no longer part of
> package OLD after loading package NEW. This doesn't happen with classes (and
> never has).
>
> The problem we're seeing here is simply that when you move classes from OLD
> to NEW, loading OLD before NEW will the classes cause to be removed and
> leaves obsolete behaviors around since re-adding the classes doesn't resolve
> them. The only way to fix that is by either issuing a config map which loads
> things in the right order (which I have done) or alternatively recompiling
> everything via "Compiler compileAll".
>

> 2010/2/11 Andreas Raab <[hidden email]>:
>> Nicolas Cellier wrote:
>>> Removing FileList/FileList2 then reloading them create obsolete
>>> references.
>>> Andreas did modify MC to take care not removing moved methods, we
>>> should do the same kind of trick for moved classes.
>> It's not applicable. My fix handled the situation where, after moving a
>> method from package OLD to package NEW, you'd load NEW and then OLD and MC
>> would remove the method from the image even though it was no longer part of
>> package OLD after loading package NEW. This doesn't happen with classes (and
>> never has).
>>
>> The problem we're seeing here is simply that when you move classes from OLD
>> to NEW, loading OLD before NEW will the classes cause to be removed and
>> leaves obsolete behaviors around since re-adding the classes doesn't resolve
>> them. The only way to fix that is by either issuing a config map which loads
>> things in the right order (which I have done) or alternatively recompiling
>> everything via "Compiler compileAll".
>>
>
> So loading NEW first, then OLD, does not remove the class ?

> Nicolas Cellier wrote:
> >2010/2/11 Andreas Raab <[hidden email]>:
> >>Nicolas Cellier wrote:
> >>>Removing FileList/FileList2 then reloading them create obsolete
> >>>references.
> >>>Andreas did modify MC to take care not removing moved methods, we
> >>>should do the same kind of trick for moved classes.
> >>It's not applicable. My fix handled the situation where, after moving a
> >>method from package OLD to package NEW, you'd load NEW and then OLD and MC
> >>would remove the method from the image even though it was no longer part
> >>of
> >>package OLD after loading package NEW. This doesn't happen with classes
> >>(and
> >>never has).
> >>
> >>The problem we're seeing here is simply that when you move classes from
> >>OLD
> >>to NEW, loading OLD before NEW will the classes cause to be removed and
> >>leaves obsolete behaviors around since re-adding the classes doesn't
> >>resolve
> >>them. The only way to fix that is by either issuing a config map which
> >>loads
> >>things in the right order (which I have done) or alternatively recompiling
> >>everything via "Compiler compileAll".
> >>
> >
> >So loading NEW first, then OLD, does not remove the class ?
>
> Precisely.