Re: can't do addBug via probes in heatbugs anymore?

[Roger M. Burkhart]

> Am I right that one can't do the nice little demo
> of adding a new heatbug to the heatbugs demo by
> a) probe a bug,
> b) use mb3 to bring up a probe of that bug with up-class button
> c) click up-class to the top object (with copy method)
> d) click that copy method to make a copy.
> e) drag and drop that copy into the addBug method parameter slot
> f) click addBug

Yeah, I used to do that demo myself, and now I'm the one who broke it!

> Now if I click that copy in the top level object 
> I get a core dump after this message:
> 
> badger-rlr)*** event raised for error: BlockedObjectAlloc
> *** function: _i_Object_s__copy(), file: DefObject.m, line: 487
> > Requested operation is defined by the Object superclass of the GNU
> > Objective C runtime system, but is blocked from usage because its default
> > implementation is incompatible with the model of zone-based allocation
> > established by the defobj package.  To allocate, free, or copy objects
> > that use the defined model of zone-based allocation, one of the messages
> > create:, createBegin:/End, drop, or copy: must be used instead.
> *** execution terminating due to error
> 
> I guess to be able to do this, one would need
> to define a custom copyBug method (which does the createBegin/end) 
> method in HeatbugObserverSwarm, say, and put a probe to 
> that copy method in the observer probe.
> 
> Am I right about all this?

Yes, exactly right.  If an object wants to define a copy: operation, it
should do so in the standard form of [anObject copy: aZone], and provide
a method that implements this.  There's currently no superclass method to
provide a default for this.

The obvious default, if we were to provide one, would be a shallow copy
of the object's instance variables.  That imposes an extra burden on
user subclasses to override the default if it it's not correct for a
particular object, however.  You've got to be really careful not to pass
through a default copy: if it doesn't make sense.  For example, a copy on
a space; it shouldn't really go on referencing all the same heatbugs on the
original space.  Avoiding the danger of such inadvertent incorrectness is
why I've avoided any default up to now.  If there's anyone with strong
feelings we can discuss the tradeoffs.  Right now, if you want a
Swarm-style copy: message, all you have to do is the copy the following
method into your class:

- copy: aZone
{
  return [aZone copyIVars: self];
}

If you have a zone variable someplace, you can also use the same method to
create a shallow, surface copy of an object such as a heatbug.  Note that
the zone pointer that used to be in every object (in the second word right
after the class pointer) now appears as an unsigned variable called
zbits that you can't use directly.  It has all kinds of weirdness going on
inside it now which is why it's restricted from direct public use.  (It
does triple duty as the holder of the zone, a list of references to be
notified on deallocation of the object, and extra bits used by the new
allocation mapping system, none of which a subclass has to worry about.)

Any time you want the the zone for an object, you should use the getZone
message: [anObject getZone].  You could do this in the probe, running
getZone on the object, creating a probe the return value, then copy the
heatbug by dropping it into the copyIVars: argument on the zone, but that
kind of interrupts the flow of a demo.

> If so, you might want to fix the heatbugs demo
> and also put together an update of manor's little
> probe notes.

I agree this is the right solution for heatbugs: it should have a copy
message to make a simple copy of a heatbug.  The old copy message (from
Object) is blocked because it didn't allocate the copy in a zone, the way
all Swarm objects are supposed to be (real harm could result if an object
tried to drop itself from a zone it wasn't really part of).  The solution
is to make sure that a zone-based copy message is provided.  By providing
a copyBug method that allocated in the same zone as the receiver, the
application could spare you the need to provide an extra zone argument:

- copyBug
{
  return [[self getZone] copyIVars: self];
}

I agree that this makes sense for heatbugs and that the application and
probe document should be updated accordingly.

-Roger