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

[Dale Henrichs via Glass]

On 8/28/15 12:38 PM, Mariano Martinez Peck wrote:
>
>
> On Fri, Aug 28, 2015 at 4:29 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>
>
>     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)...
>
>
> Exactly!!!! This would easy quite a lot the debugging. The way it is 
> now it is very very complicated to debug. I have to halt into the add: 
> of the error definition to see which was the exception.. exceptions 
> MUST be recorded. In fact...why not to store a particular exception 
> which indeed has an instVar holding the definition? that way we can 
> easily keep both.
>
> That said, I will try to reproduce my problem with dummy classes in an 
> empty stone,,, but you know...it's like when you take the care to the 
> garage and you want the guy to listen the noise... and then you cannot 
> reproduce it. So...I am not optimistic I will be able to reproduce it 
> with a test. But I will try.
>
> Thanks for your explanations.
>
>
Don't put halts in the code, either log the definition/exception combo 
or put them into the object log so we can get all of the information 
later .... I want to know the specific error and the definition that 
leads to the error  ... and then I want to work backwards to understand 
exactly what it is that's causing the error - it will make creating a 
dummy case much easier  ... unless a dummy case is trivial:)

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