[DGD] Kernel Library wiztool - out of ticks in cmd_code

[Shentino]

If the old _code is left lying around, then the next compile_object
won't create a new _code object, but will upgrade the old one, and LPC
bytecode is replaced AFTER the exec round ends IIRC.

So, if I'm not mistaken, the wizzes next use of "code" will repeat the
earlier one in effect because DGD would be executing stale bytecode.
Quite bewildering if the wizard fixed his error, or worse, typed in a
different statement.

A simple fix is:

if (find_object("~/_code"))
    destruct_object("~/_code");

Put before the compile_object() thingy, thus getting rid of the upgrade ghost.

Plus, to avoid clutter, it could be asynchronously destructed in a
zero second callout started before the call_other to _code, so if
there was a tick crash, at least it wouldn't be left lying around.

Am I making a valid point here or did I goof up?

On 3/12/07, Felix A. Croes <felix at dworkin.nl> wrote:
> Neil McBride <sarak at castinian.org> wrote:
>
> >[...]
> > Is there any reason this approach would not be appropriate in the
> > kernel's wiztool object to ensure the object gets destroyed following
> > an out of ticks error?  It's a System object, I would expect an
> > infinite loop when destructing the object to be unlikely and the limit
> > resetting and unaccounted destruction don't seem like an issue.
>
> Do you want any programmer to be able to hang the mud with a code
> command?  If there is no limit on ticks, there also is no out of ticks
> error.
>
> Generally speaking, it's hard to recover from an "out of ticks" error
> without offering some way to get around the ticks limit, which would
> amount to compromising the resource management system.  If you are
> truly worried about that lingering object, you could change the
> wiztool through inheritance and add a zero second callout to
> destroy it after execution of the code command.  For a minimal
> mudlib, I decided that this wasn't a priority.
>
> Regards,
> Dworkin
> __________________________________________
> http://mail.dworkin.nl/mailman/listinfo/dgd
>