On 07 Dec 2011, at 12:34, Henrik Sperre Johansen wrote: > I can't claim to know exactly, but I seem to remember it does batches of new, > then changed, then removed methods. > Other than that, I think they happen "seemingly" at random. > There are many sorts of internal dependencies, so other than the old > workaround of making multiple .mcz's without internal dependencies, one kind > of needs an insight into what exactly was at fault here to see if anything > could be improved of the loading order in the general case, which does not > simultaneously break something else...
For me the question is: is the fileout/source.st order in which changes are applied more stable/less prone to such errors? And in my example, it is. But I haven't looked into the implementation of either. Anyway, it might not be 'stable', but I can remove a single override on Symbol>>#precedence and now it loads. Would there be any way other than splitting up packages? Because from a semantic perspective, it just does not make sense to split these things up. The typical separation of core system and overrides does also not help, since here, the dependency is between the overrides. Thanks Stefan > > Cheers, > Henry > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
