Removing things

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing things

keith1y
I am attempting to unload things from the image.

SystemNavigation allObjectDo:

gets upset, when one of its objects turns out to be an instance of
ProtoObject subclass: MessageCatcher.

does anyone have any idea how this might come about?

I am performing  " Installer unload: 'Universes'.  " in 3.10

Keith

Reply | Threaded
Open this post in threaded view
|

Re: Removing things

keith1y
Keith Hodges wrote:

> I am attempting to unload things from the image.
>
> SystemNavigation allObjectDo:
>
> gets upset, when one of its objects turns out to be an instance of
> ProtoObject subclass: MessageCatcher.
>
> does anyone have any idea how this might come about?
>
> I am performing  " Installer unload: 'Universes'.  " in 3.10
>
> Keith
I understand it now ProtoObject doesnt understand #isBehavior and this
will break if there are any subclasses of ProtoObject in the entire image

Keith



Reply | Threaded
Open this post in threaded view
|

Re: Removing things

Tom Phoenix
In reply to this post by keith1y
On Jan 21, 2008 1:59 PM, Keith Hodges <[hidden email]> wrote:

> SystemNavigation allObjectDo:
>
> gets upset, when one of its objects turns out to be an instance of
> ProtoObject subclass: MessageCatcher.

I do, too. MessageCatcher instances are evil. It's hard to do anything
with one without tripping over something it doesn't understand,
especially #hash.

For example, evaluating the following in a Workspace works for me, but
then it bollixes the Workspace so that I can't do it a second time,
because the workspace chokes on its former variable fred:

   fred := MessageCatcher new.
   count := 0.
   SystemNavigation default allObjectsDo: [:i |
       ( i class == MessageCatcher)
           ifTrue: [count := count + 1]].
   count inspect

>From looking at how it's used in the system, it seems to be used only
to catch the messages sent by
InstructionStream>>interpretNextInstructionFor:, which is to say that
the only messages it needs to catch are listed explicitly in that
method. It looks like a hack that could be avoided entirely by
refactoring that method into one part that decodes the instruction and
another that sends it to the client.

I can't help feeling that we would be better off without the black
magic of MessageCatcher.

Cheers!

--Tom Phoenix

Reply | Threaded
Open this post in threaded view
|

Re: Removing things

timrowledge

On 21-Jan-08, at 5:44 PM, Tom Phoenix wrote:
>
> I can't help feeling that we would be better off without the black
> magic of MessageCatcher.


Indeed - who the hell put such a nasty class into the system?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oyster (n.), a person who sprinkles his conversation with Yiddishisms.



Reply | Threaded
Open this post in threaded view
|

Re: Removing things

Randal L. Schwartz
>>>>> "tim" == tim Rowledge <[hidden email]> writes:

tim> Indeed - who the hell put such a nasty class into the system?

"ajh", say the initials.  Paging Anthony Hannan?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!