[DGD]Tracking auto_object usage

[Kevin N. Carpenter]

Unclear writing on my part...  Let me back up and try again:

I want to keep track of all programs that inherit an object.
It seems the best place to do that is during execution of the
driver's inherit_program()function.  The program doing the
inheritance doesn't exist yet, since its being compiled, so
it isn't eligible to store anything.  That implies that the
inherited object itself needs to keep track of who inherits it.

A mapping within each inherited object containing a reference to
the object name doing the inheritance is one method of keeping this
data.  Unfortunately, this approach suffers from mapping size restrictions
associated with the config file parameter array_size.  That, in
itself, is probably not a killer problem unless one wants to track
the auto object using the same code.  At that point, array_size
better be a significant fraction of maximum number of objects.
For a very large mud, this could be a problem.

Now, regarding the part after the first comma in the post below:

Since inherit_program() isn't called for the auto object, some other
technique of tracking all non-cloned objects (everything that
automatically inherits the auto object) is needed if one desires
to track auto object usage.  The approach that was apparent to me
was to have the object manager simple keep track of all compiled
program, thereby keeping track of all auto object inheritors.

I do mask the compile_object kfun, redirecting it to my object
manager code.  Unfortunately, I don't see how that will help me
know I need to recompile an object, or what objects need to be
recompiled, when the auto object is destructed.

I suppose I could do it dynamically with a check in call_other()by
keeping a version number of the auto object.

Another alternative would be to have special code for updating
the auto object that simply runs through the list of all objects
and recompiles any non-clones.

Comments?

Kevin C.

ps.  If this has an attachment, my apologies and appreciation to
anyone who can tell me how to get Outlook 2000 to stop attaching
things to plain-text post.


-----Original Message-----
From: dgd-admin at list.imaginary.com
[mailto:dgd-admin at list.imaginary.com]On Behalf Of Felix A. Croes
Sent: Thursday, March 23, 2000 6:36 AM
To: dgd at list.imaginary.com
Subject: Re: [DGD]Tracking auto_object usage


"Kevin N. Carpenter" <kevinc at monrou.com> wrote:

> Since the driver function inherit_program() isn't called for the
inheritance
> of the auto object, is there an alternative to having the object manager
> simply keep track of all compiled programs?  Obviously it could be made
> smart enough to not track other inheritable, since they would only get the
> auto object as part of the program that was inheriting them.

Sorry, but I don't understand how the part after the first comma
follows from the part before.

There is a very simple way to make sure the mudlib is properly notified
about the compilation of the auto object, without a need to have
inherit_program() called: mask the compile_object() kfun, and whenever
a non-auto object is compiled with the auto object destructed, perform
the same task as in inherit_program().


> Any opinions on the risk associated with keeping tabs on this via a
mapping
> instead of a linked list?  The number of objects created via compiling
> rather than cloning is hopefully a small subset of the objects in the mud.
> Then again, I suppose its unwise to code in any limits around the config
> file parameter array_size if it can be avoided.

If you register objects in a single mapping, you cannot register more
objects than the maximum array/mapping size.  The decision is up to you.
DGD has a (configurable through recompiling) 64K limit on the number
of objects, and a (hard) limit of 32767 elements in an array or mapping.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd


List config page:  http://list.imaginary.com/mailman/listinfo/dgd