MOO-cows Mailing List Archive
Re: Two quickies:
At 08:02 AM 1/22/96 PST, firstname.lastname@example.org wrote:
>When a property is !c, its ownership is kept to be that of the original
>owner when somebody creates a child.
This is the correct (and documented, and desired) behavior.
>I also noticed that when you used I use a object size measurer it does
>not list the !c properties whos values have not changed. As soon as you
>change the value, even if to the same value it lists it and adds it to
>the total size.
That is because property values are inherieted. A property can have a value
of 'clear' (internal to the server), and any reference to that property on
the child object will return the value of that property as it is on it's
parent. Assigning something to a property makes it non-clear (even
assigning it the value of itself). When a property is clear, it is
effectively 'empty', which is why the measurement of it is not added to the
total size of the object (you would just be adding 0). This is explained
more in depth in the section on properties in the programmer's manual.
>I must mention that the verb used to measure the size is a hack from the
>byte_utils as the MOO uses object quota and not byte quota so this could
>be a quirk of the verb. But if it is not then it would be very useful to
>know.. I couldn't find any mention of this in the prog manual, but I
>would like to be certain.
The LambdaMOO Programmer's Manual is pretty much documentation for the
server, not for code in the database, which $byte_quota_utils is part of, so
I wouldn't expect it to be documented there.
This seems to be a common/recurring problem. Pavel, when you are done with
the "Programmer's Manual" for 1.8, could you rename it to reflect that it's
more along the lines of server documentation (as in what the server
supports), rather than documentation for programming in MOO in general
(which is what the current name suggests).
>How attribitable to lag are [forked tasks]?
There is much talk of this on the MOO-Cows mailing list archive, URL
>What I am getting at, is for something similar to the room message
>announcer. Lag wise, is it better to create forks for that room when
>people enter it and then kill them as they leave or to have one fork
>running the whole time sending messages to rooms in a list, say using a
I don't understand what you are trying to do with forking/killing a task
when a player enters and leaves a room.
>Basically, I guess I am asking if any of you can explain the pros and
>cons to forks, and/or point me to some lititure on them.
Information on forks includes the Programmer's Manual and the wind-up duck
tutorial on parcftp. The only other resource for information on forking are
the people on this mailing list (and it's archive site (blantant
advertisement) http://shrike.depaul.edu/~abakun/moomail/), and we are, for
the most part, not in an easily readable plain text form. A web search for
'MOO fork' returned some interesting results tho. Might want to look into that.
Subject Index |