I filed out a project with a SqueakMap package in it (in addition to my own code). Attempting to file it into a clean 3.8-6665 image fails. The package in question is XPMReadWriter, and after grinding a bit, I get a Debugger:
UndefinedObject(Object) >> doesNotUnderstand: #commentStamp:prior:
The Compiler is trying to evaluate:
'XPMReadWriter commentStamp: ''<historical>'' prior: 0'
XPMReadWriter isn't defined at this point.
Is this a problem with the order in which Project files are written? It's just possible that I first loaded XPMReadWriter before creating this project, then loaded it in again. Would this result in such a Project file?
The problem was cured by manually loading the XPMReadWriter SqueakMap package first, then filing in the Project. That worked fine. I'm just trying to understand what happened.
FWIW, though, when the project opened up, all of the previously existing windows had bold-face font in all panes. New windows were created using the correct font, however. Weird.
Mike O'Brien
Is this a problem with the order in which Project filesare written? It's just possible that I first loaded XPMReadWriter before creating this project, then loaded it in again. Would this result in such a Project file?
It's possible this is what happened. I just tried an experiment where I started with a clean image of 3.8-6665, updated SqueakMap, created a new Project, entered it, loaded XPMReadWriter, wrote out a Project file, then abandoned the image and loaded the new Project file into a clean image with an updated SqueakMap. That project file loaded without error. It looks like if you reload a class into an image that already has the class defined, what goes into the changeSet won't file in correctly to an image that's never seen the new class before. I suppose I shouldn't be surprised.
On my original image that gave rise to this problem, I also got a popup about blocks playing with instance variables, which I didn't understand even after browsing the debugger that resulted. Pointers as to what that's all about would be appreciated: I couldn't even make enough sense of what it was trying to tell me (the Debugger opened on methods deep inside the squeak parser) to determine whether this was related to the problem of filing in the Project file.
Mike O'Brien
It looks like if you reload a class into an image that already
^^^^^
has the class defined, what goes into the changeSet won't file in correctly to an image that's never seen the new class before. I suppose I shouldn't be surprised.
SHOULD READ:
It looks like if you reload a class into a Project that already
^^^^^^^
has the class defined, what goes into the changeSet won't file in correctly to an image that's never seen the new class before. I suppose I shouldn't be surprised.
Mike, thank you for sharing this experience. In another world at another time I'm investigating the dont's and do's of the (most likely rotten) interplay between the classic "changes" mechanism and SqMap and MC. You experience made it onto my toDo list, thank you.
/Klaus
On Sat, 29 Jul 2006 00:59:18 +0200, Mike O'Brien wrote:
Is this a problem with the order in which Project filesare written? It's just possible that I first loaded XPMReadWriter before creating this project, then loaded it in again. Would this result in such a Project file?
It's possible this is what happened. I just tried an experiment where I started with a clean image of 3.8-6665, updated SqueakMap, created a new Project, entered it, loaded XPMReadWriter, wrote out a Project file, then abandoned the image and loaded the new Project file into a clean image with an updated SqueakMap. That project file loaded without error. It looks like if you reload a class into an image that already has the class defined, what goes into the changeSet won't file in correctly to an image that's never seen the new class before. I suppose I shouldn't be surprised.
On my original image that gave rise to this problem, I also got a popup about blocks playing with instance variables, which I didn't understand even after browsing the debugger that resulted. Pointers as to what that's all about would be appreciated: I couldn't even make enough sense of what it was trying to tell me (the Debugger opened on methods deep inside the squeak parser) to determine whether this was related to the problem of filing in the Project file.
Mike O'Brien
beginners@lists.squeakfoundation.org
-
Klaus D. Witzel -
Mike O'Brien