[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)

[Dale Henrichs via Glass]

On 8/27/15 7:37 PM, Mariano Martinez Peck via Glass wrote:
> Hi guys,
>
> Sorry to continue with this topic but since I loose quite some time I 
> must understand what is going on so that it doesn't happen again. For 
> all my testing, the ONLY way I had make it work is with James/Martin 
> code to manually hack the symbol list and change class name. I will 
> try to summarize what is going on.
>
> The repository currently has this:
>
> Object
> *- FaSecurityClosingPriceRecord (no instances)*
> - SpecialSuperclass
> *- - FaSecurityClosingPriceRecord2*
> - - - FSCPR2a (instances)
> - - - FSCPR2b (instances)
>
> And I am trying to commit:
>
> Object
> - SpecialSuperclass
> *- - FaSecurityClosingPriceRecord*
> - - - FSCPR2a (instances)
> - - - FSCPR2b (instances)
...
> If I do NOT run James above code, then I get a warning saying: "there 
> is a problem with FaSecurityClosingPriceRecord .... it MAY work on a 
> second pass". So I click proceed, and I load everything it again. No 
> warning this time. But.... the resulting stuff is broken. I basically 
> end up having 2 classes and 2 metaclasses of 
> FaSecurityClosingPriceRecord and 2 classes. One associated with the 
> already existing instances and one which is the in Smalltalk globals 
> and it's the one used for new instances. Confirmation of this issue:
>
Okay, while the iron is hot,we need to capture the exact errors that are 
leading to the creation of the errorDefinitions  (second pass errors) 
and work our ways back to the set of definitions that can be used to 
construct a failing test case ... on the surface there is nothing that 
could lead to the errors, so identifying the specific errors would be 
useful ...

Specifically we need to instrument up MCPackageLoader>>tryToLoad: and 
record the exception along with problematic definition for each of the 
places where a definition is added to errorDefinitions .... including 
the places where we're removing definitions from errorDefinitions ... 
the best would be to just drop the exception and definition into the 
object log ... but dumping printStrings of the exception and definition 
to the gem log (or Transcript) would probably give us enough info (would 
want to see the details for problematic definitions as well)...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150828/fd45f528/attachment.html>