MOO-cows Mailing List Archive


Re: [SERVER] ALPHA release of LambdaMOO server 1.7.9

Gustavo Glusman writes:
> It also seems to fix all the other errors that have been reported, but it
> seems to have a memory leak:
> ;#0:memory_usage()
> => 432064
> ;match("an","i")
> => {}
> ;#0:memory_usage()
> => 563136
> 128 K for just one match seems like a lot.

Agreed.  I'll look into it for alpha2.

> Another oddity with the new match(): it still returns (when successful) a
> list of - {<start>, <end>, <replacements>, <subject>}
> The problem is that the <replacements> list is now always *twenty-nine*
> items long, as opposed to the 9 in the previous version.

Oops!  Heh.  I'll definitely fix this in alpha2.

> >-- Officially deprecated the USE_GNU_MALLOC option in options.h, since it's
> >   not aging very well.
> As in the above example, the option of having a tool for getting an idea of
> memory usage seems to be of some convenience.
> What does 'officially deprecated' mean? If we use it, bug reports will be
> preceded by a recommendation to suspend USE_GNU_MALLOC ?

Yup.  It's a messy piece of code and I don't want to try to support it any

> ;value_bytes(1)
> => 0
> ;value_bytes(e_perm)
> => 0
> Are numbers and errors that cheap to store? :)

Yes, actually.  In particular, given a list of numbers, the list itself gets
charged for all of the storage.  Similarly, a property value always takes up a
certain fixed amount of storage; if the value is a number/object/error, then
that's all there is.

> >-- At long last, there is a DB-settable limit on the number of queued tasks
> >   any single user can have at once.

> How about making it different for every programmer?
> How about checking whether the task perms are valid, if so, whether the
> object defines a .user_task_limit, and if this is a non-negative number,
> use that as task limit? Otherwise, use $server_options.user_task_limit.

I'll consider putting this into alpha2.



Home | Subject Index | Thread Index