MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: [SERVER] ALPHA release of LambdaMOO server 1.7.9

>-- Fixed a longstanding bug in match() that could make it return garbage in
>   certain circumstances.  More bugs in match() almost certainly still exist.
>   (Thanks to Judy Anderson for finding this.)

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.

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.

;match("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz","%(.%)%(.%)%(.
%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%
)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)")
=> {1, 31, {{1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}, {6, 6}, {7, 7}, {8, 8},
{9, 9}, {10, 10}, {11, 11}, {12, 12}, {13, 13}, {14, 14}, {15, 15}, {16,
16}, {17, 17}, {18, 18}, {19, 19}, {20, 20}, {21, 21}, {22, 22}, {23, 23},
{24, 24}, {25, 25}, {26, 26}, {27, 27}, {28, 28}, {29, 29}},
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"}

So all 29 of them seem to work. But how does substitute() work, if so?

;substitute("%22",match("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy
z","%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(
.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.%)%(.
%)%(.%)"))
=> "b2"

>-- 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 ?

>-- By popular request, added the built-in function `value_bytes(VALUE)', which
>   returns the number of bytes of memory required to store the given value.  [I
>   was also asked to provide an `object_bytes(OBJ)' function, to give the total
>   memory required to store the given valid object, but I wanted to think
>   longer about possible interactions with 1.8.0's new modularity wall between
>   the DB implementation and the rest of the server.]

;value_bytes(1)
=> 0
;value_bytes(e_perm)
=> 0

Are numbers and errors that cheap to store? :)

>-- At long last, there is a DB-settable limit on the number of queued tasks any
>   single user can have at once.  If $server_utils.user_task_limit exists and
>   is a non-negative number, then that is the `task limit' for normal users;
>   otherwise, the task limit is infinite.  For wizards, the task limit is
>   controlled similarly by $server_utils.wizard_task_limit.  Whenever a `fork'
>   statement or `suspend()' call are executed, the server checks whether or not
>   the current verb's owner (really, the current task perms) is already at or
>   above their task limit; if so, E_QUOTA is raised instead of either forking
>   or suspending.  Reading tasks are not affected by the task limit.

How about making it different for every programmer?
I guess $server_utils.user_byte_quota wouldn't be a good idea, right? :)
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 can imagine where giving more tasks to $hacker (or somesuch) might be
handy, without needing to make it a wizard instead. ;)


-------------------------------------------------------------
Gustavo Glusman               Founder/administrator of BioMOO
-- Gustavo@bioinformatics.weizmann.ac.il
-- http://bioinformatics.weizmann.ac.il:70/0h/Gustavo/Glusman
-- BioMOO: telnet bioinformatics.weizmann.ac.il 8888
           WWW:   http://bioinfo.weizmann.ac.il:8888
Follow-Ups:
Home | Subject Index | Thread Index