Quantcast

How to recover from Object := nil?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to recover from Object := nil?

Howard Oh
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?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to recover from Object := nil?

davidbuck
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to recover from Object := nil?

Schwab,Wilhelm K
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]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to recover from Object := nil?

Support at Object Arts
"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


Loading...