The internal message passing functions should be cleaned up. Currently, a lot
of stuff calls add_message() directly, while other stuff uses tell_object()
and friends. One consequence of this is that even with INTERACTIVE_CATCH_TELL
defined, not all of the output flows through catch_tell() [ed, for example,
doesn't, as well as some other efuns].
-----
In the MudOS v22a36 the livings efun gives back HIDDEN things too.
I don't know why objects used that strange construction.
I think, it's new form would be more usable.
As i see this HIDDEN stuff has many leaks, like:
you can always create an object that you put into all rooms, and look
for this_player() in the init apply.
So even if you correct all efuns like livings, heartbeats, named_livings
and so on, it will never be perfect.
solve for livings and objects:
------------------------------- cut here ----------------------------------
1831c1831
< int nob, apply_valid_hide, hide_is_valid = 0;
---
> int nob, display_hidden=-1;
1836d1835
< apply_valid_hide = 1;
1844,1848c1843,1845
< if (apply_valid_hide) {
< apply_valid_hide = 0;
< hide_is_valid = valid_hide(current_object);
< }
< if (hide_is_valid)
---
> if (display_hidden==-1)
> display_hidden = valid_hide(current_object);
> if (!display_hidden)
1876c1873
< int display_hidden = 0, t_sz, i,j, num_arg = st_num_arg;
---
> int display_hidden = -1, t_sz, i,j, num_arg = st_num_arg;
1890a1888,1889
> if (display_hidden==-1)
> display_hidden = valid_hide(current_object);
1892,1893d1890
< display_hidden = 1 + !!valid_hide(current_object);
< if (!(display_hidden & 2))
---------------------------------- cut here --------------------------------
Comment: possibly a better solution is to check O_HIDDEN where O_DESTRUCTED
is checked. valid_hide() would be checked when objects load, and would
set a O_CAN_SEE_HIDDEN bit. Then every time we run across a
FRAME_OB_CHANGE, do:
if (current_object & O_CAN_SEE_HIDDEN)
object_mask = O_DESTRUCTED;
else
object_mask = O_DESTRUCTED | O_HIDDEN;
Code elsewhere would then look something like:
if (sv->type == T_OBJECT && (sv->u.ob->flags & object_mask)) {
free_object(sv->u.ob, "...");
*sv = const0;
}
This would be much more effective at preventing objects from detecting the
existence of hidden objects. It would also fix this one:
Various efuns which call valid_hide() don't realize it can error, causing
them to leak if master::valid_hide() throws an error.
-----
If an include file doesn't end in a newline, something screws up in the
linked buffer code, causing odd compile errors.
Line numbers get messed up when files don't end in a newline?
-----
RUNTIME_LOADING needs -rdynamic passed in the link on some OS's?
(reported for a gcc-linux system; possibly a mixed a.out/elf?)
-----
This gives the wrong error message:
unlock the door with the key
Trying interpretation: unlock:the:door:with:the:key:
Trying rule: OBJ with OBJ
parse_rule
parse_obj:
Found noun: door
parse_rule
Matched literal: with
parse_obj:
Found noun: key
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Trying direct_unlock_obj_with_obj ...
Return value was: 1
Trying indirect_unlock_obj_with_obj ...
Return value was: 0
You can't unlock the thing with that.
exiting parse_rule ...
parse_rule
exiting parse_rule ...
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
exiting parse_rule ...
Done trying to match OBJ
parse_rule
last match to error ...
Changing last match.
parse_obj:
Found noun: key
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Trying indirect_unlock_obj_with_obj ...
Return value was: 0
You can't unlock the thing with that.
exiting parse_rule ...
parse_rule
exiting parse_rule ...
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Have better match; aborting ...
exiting parse_rule ...
Done trying to match OBJ
parse_rule
Matched literal: with
parse_obj:
Found noun: key
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Trying indirect_unlock_obj_with_obj ...
Return value was: 0
You can't unlock the thing with that.
exiting parse_rule ...
parse_rule
exiting parse_rule ...
parse_rule
we_are_finished
Trying can_unlock_obj_with_obj ...
Trying can_unlock_obj_word_obj ...
Trying can_verb_obj_word_obj ...
Trying can_verb_rule ...
Trying can_unlock_obj_with_obj ...
Return value was: 1
Have better match; aborting ...
exiting parse_rule ...
Done trying to match OBJ
parse_rule
last match to error ...
Literal not found in forward search
parse_rule
last match to error ...
Literal not found in forward search
parse_rule
Ran out of words to parse.
Done trying to match OBJ
There is no door here.
-----
It still seems possible for regexp(explode(read_file(...), "\n"), ...) to
crash, but I can't reproduce it.
-----
#pragma optimize bug:
;; Function room_of
049d: local LV0
049f: !
04a0: || 0006 (04a7)
04a3: transfer_local LV0
04a5: objectp
04a6: !
04a7: branch_when_zero 0003 (04ab)
04aa: return_zero
04ab: branch 0007 (04b3)
04ae: local LV1
04b0: (void)assign_local LV0
04b2: break_point
04b3: local LV0
04b5: environment
04b7: local_lvalue LV1
04b9: assign
04ba: bbranch_when_non_zero 000d (04ae)
04bd: transfer_local LV0
04bf: return
04c0: return_zero
object room_of(object obj) {
object ob;
if(!obj || !objectp(obj)) return 0;
while(ob=environment(obj)) obj=ob;
return obj;
}
-----
heart_beat() is not shadowable
-----
mixed a;
do {} while (a = ({ a, "" }));
Profezzorn@TMI-2
Comment:
It would be nice if things like this, where all the memory (VM too)
is sucked up by a runaway program, didn't cause the driver to
shutdown ("Out of memory").
### Nope, this evals out, need to do more work to make it run out of memory
-Sym (note: which is not the same as if the driver errors with "Out
of memory)
Yet another comment: Whether it evals out or runs out of mem obviously depends
on the ratio of MAX_EVAL_COST to available memory ...
-----
Range/switch search should be binary, not linear. (in LPC->C)
-----
Probably need a test to see if bison's output actually compiles in
./build.Mudos; on a lot of AIX systems bison's use of alloca() fails.
-Beek
-------
One can call private functions in inherited objects via call_out.
------
verbs that no longer have handlers should be deleted from the parser list
---
Line numbers can be screwed up by macro expansion. Consider the following:
#define IGNORE(x)
#define USE_ONCE(x) x
#define USE_TWICE(x) x
// The end of the next line never gets counted.
IGNORE("foo\
bar")
// The end of the next line is counted once.
USE_ONCE("foo\
bar")
// The end of the next line is counted twice.
USE_TWICE("foo\
bar")
So the IGNORE() and USE_TWICE() cases with screw up line numbering.
Fixing this is non-trivial, since macro expansions are reinserted into
the input stream. Outside of quotes, it was handled by replacing
'\n' with ' ' which is semantically equivalent. Inside quotes, one has
to do something like count the newlines as they are parsed, and then
have add_input() keep track of how many artificial newlines it has created,
so these can be ignored, which requires a check every time current_line++
is done ...
There must be a better fix :)
---
codefor int i,j; ({ i++, j})[1]; return i;
;; Function eval_function
0000: break_point
/* Missing:
* local_lvalue LV0
* inc(x)
*/
0001: local LV0
0003: return
