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

[Mariano Martinez Peck via Glass]

On Fri, Aug 28, 2015 at 4:29 PM, Dale Henrichs via Glass <
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.




> Dale
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150828/999d2a53/attachment-0001.html>