One sleepy night work, I accidently
Object := nil. with object := nil in mind. I saved the image after that not noticing the mistake. How to recover from this mass? |
Howard Oh wrote:
> One sleepy night work, I accidently > > Object := nil. > > with object := nil in mind. > > I saved the image after that not noticing the mistake. > > How to recover from this mass? > I haven't tried it, but give this a try: Object := nil class superclass If you can execute any Smalltalk code, this should work. David Buck |
David, Howard,
>> One sleepy night work, I accidently >> >> Object := nil. >> >> with object := nil in mind. >> >> I saved the image after that not noticing the mistake. I know it's not a lot of help to tell you this now, but to avoid this kind of mistake, I try to sneak indefinite articles (a/an) in front of class names when a collision is likely. >> How to recover from this mass? >> > > I haven't tried it, but give this a try: > > Object := nil class superclass > > If you can execute any Smalltalk code, this should work. Object := Smalltalk at:#Object might work too. Howard, with anything like this, you should first set aside a copy of the damaged image, marked as such; also identify a recent clean backup, and flag it too. I forget the status of the wiki, but it contains some good info on backup and recovery. Backups should contain the source, image, and change files. In your situation, I would very likely roll back to a previous good backup and mine the tail of the suspect image's change log for interesting stuff - Ian's chunk browser works great. BTW, I would also at least try to fix the image for curiosity's sake, but I doubt I would trust it. In general, it is much easier to recover the good parts of a late night's effort than it is to do the work the first time, so the rollback is not as bad as it sounds, and it reduces the risk of unpleasant surprises in the future. If you fix the image and decide to move forward from it, spend some time checking out the development tools, making sure that that events propagate as they should. I mention that because of things that Blair said about the consequences of (wrongly) super-sending in a class-side #initialize method. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
"Bill Schwab" <[hidden email]> wrote in message
news:TUuTg.914$[hidden email]... > David, Howard, > >>> One sleepy night work, I accidently >>> >>> Object := nil. >>> >>> with object := nil in mind. >>> >>> I saved the image after that not noticing the mistake. > > I know it's not a lot of help to tell you this now, but to avoid this kind > of mistake, I try to sneak indefinite articles (a/an) in front of class > names when a collision is likely. Not necessary in Dolphin since 5.1 (according to our change tracking system anyway). Try it and you'll see what I mean. Actually this should be disallowed in all ANSI compliant Smalltalk systems: ANSI NCITS 391-1998, p9 para 1: "The binding of the <<class name>> to the class object is a constant binding. It is erroneous for an identifier that resolves to a such a binding to appear as the target of an assignment statement." Although of course the meaning of "it is erroneous" could, at a stretch, include rendering your system useless. In D6 it is even more difficult to inadvertently damage the system in this way because the class variable bindings are immutable, so even Smalltalk at: #Object put: nil will fail. So I'm not sure how Howard has managed to do this, unless he is using a very old version of Dolphin. [Good advice on image maintenance and restoration BTW] Regards OA |
Free forum by Nabble | Edit this page |