What does the class hierarchy for the provided class look like ... before (hierarchy of involved classes before load) and after (intended hierarchy after load) ... I'd also like to see more details about the error itself ... start with a stack trace so I can see what methods are involved and then after I've studied that a bit, I'll probably have more questions ....
I don't recall touching the Monticello loader for a long time, so there must be something else causing the loader to get confused ... The loader scans the definitions and builds a list of classes (class definitions) provided by the mcz file and it uses that plus the existing class definitions from the image to determine whether or not the package depends upon missing classes ... so for some reason GemStone is not seeing the class definition or it is not recognizing the name of the class ... you could look at the snapshot (orderedCollection of definitions) from the mcz file and write a little script to extract the classNames from the classDefinitions and see if the class is in the definition list also look for any funky looking classNames ... I don't recall whether or not the classNames are supposed to be symbols, but that would be a classic problem if somehow the classNames in the mcz are Strings or Symbols when they are expected to be Symbols or Strings ...
Is it possible that you've got some WideStrings being produced by the Pharo images? GemStone doesn't know what to do with WideStrings embedded in mcz files ... this is another "classic problem"
Are these mcz files written out by FileTree? If so try a classical mcz file if not try a FileTree package (FileTree write UTF8 to disk, so any non 8 bit ASCII characters can be handled correctly) ...
I guess you could also ship me the mcz file and I can put it under a microscope...
Dale
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Locked
