[Glass] recompiling a package

[Paul DeBruicker via Glass]

Hi Mariano,

Yeah sounds like the same/a similar problem.  I loaded a class that in Pharo 3 had a method with a reference to an inst var that I had removed from the class definition.  After proceeding through the warning the class was loaded and the class hierarchy was broken.  Removing the offensive method in Pharo 3 and reloading the package did not fix the broken hierarchy.  Recompiling the subclasses does fix it.  


Paul



On Feb 18, 2015, at 11:14 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:

> Hi Paul, 
> 
> Just to track down the problem...let me ask you..when you loaded the code via MC, did it warn about one of the classes of that hierarchy saying there could be a problem but that it might work in a second pass or something?
> Because it happened the same to me a couple of times..subclasses got kind broken and like if the superclass were duplicated.. and I had to do exactly the same as you...I forced the recompilation in the subclass. I am not sure if it was this..but I remember some syntax error somewhere (maybe an empty statement or something).
> 
> So what your scenario similar?
> 
> 
> 
> On Wed, Feb 18, 2015 at 3:15 PM, Paul DeBruicker via Glass <glass at lists.gemtalksystems.com> wrote:
> Hi -
> 
> 
> I've loaded a Monticello package into GemStone 3.1.0.6 using tODE and the class hierarchy is broken.  Some subclasses of some classes don't know that they're subclasses and so method lookup is broken for those subclasses.  If I put a space in the #instVarNames: portion of the class definition and save it the class hierarchy is restored.
> 
> 
> Is there a way to do that for all classes in the package from a script?
> 
> 
> thanks
> 
> Paul
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com