[MOO-Cows] [encore] line number in callers()
Hi
I want to generalize a debugging routine.
Instead of writing a horrible hardcoded
43: player:tell(now come to verb `:go_crazy', line 43);
44: player:tell(value at this point: , value);
and the like all the time, I have written a verb
#1:debug(?msg)
--
{?msg = {}} = args;
typeof(msg) != LIST ? msg = {msg} | 0;
block = {, DEBUG:};
for c in (callers())
block = [EMAIL PROTECTED], tostr(c[1], :, c[2])};
endfor
block = [EMAIL PROTECTED], @msg, END DEBUG, };
for d in (this.debuggers)
d:tell_lines(block);
endfor
... which is called with, e.g.,
43: this:debug(tostr(value: , value));
Now I _really_ would like to get hold of the line, not only the object and
verb name. Callers() wouldn't reveal the line; I can't see other functions
than raise() that could. I tried to jumble raise() into that routine, by
producing a local, recoverable error like this:
43: `bogus ! ANY = this:debug(tostr(value: , value))';
(`bogus' is a non-defined variable here) and catch the error and the line
(lines) that way, but I couldn't get it to work. And it seems like overkill
to me.
Is there anything I have missed?
Has somebody done this already?
Thanks for any pointers
- Daniel
#
This message is sent to you because you are subscribed to
the mailing list [EMAIL PROTECTED].
To unsubscribe, E-mail to: [EMAIL PROTECTED]
To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED]
To switch to the INDEX mode, E-mail to [EMAIL PROTECTED]
Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] Re: [encore] line number in callers()
Andrew Wendt wrote: Using callers() won't reveal the line, but callers(1) will, right? *bonk* *bonk* *bonk* = my head against the wall *blush* humbleThanks/humble - Daniel # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] forked moo servers II
Dr Robert Sanderson wrote: Historically, as I'm sure you're all aware, the only reason for these forks is that moo-cows and similar contact with the 'main' 'developers' has been intermittent at best. And when people have tried to make contact in person, there's been no response. Me too I had trouble reaching them when I tried a while ago. If it's a good time to get all of these forks re-synced, then please please do so. Are there arguments against a re-sync? - Daniel # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] Missing quote oddity when compiling verbs
[Note to enCore list: This is maybe nerd stuff]
[Note to moo-cows: This is maybe just-below-basics]
Lambda MOO 1.8.0r5.
Compiling this:
{1, 2, 3, 4} = args;
{} = args;
1 = 2;
break;
continue;
$;
;
;
;
;
;
returns these errors (from the parser.y file):
Line 1: Scattering assignment targets must be simple variables.
Line 2: Empty list in scattering assignment.
Line 3: Illegal expression on left side of assignment.
Line 4: No enclosing loop for `break' statement
Line 5: No enclosing loop for `continue' statement
Line 6: Illegal context for `$' expression.
Line 7: Missing quote
Line 7: Missing quote
Line 7: parse error
What I find peculiar is missing quote loop. After line 7, line 8 is
read (apparently) and the missing quote in line 8 detected. The line
count stops at line 7, however, and the final parse error is assigned
to line 7 as well. The Missing quote case seems to be caught up in a
loop for itself instead of following the lineno++ iteration, thus
disregarding the latter.
Reducing the verb body to
;
returns
Line 1: Missing quote
Line 1: parse error
and expanding it to
;
;
$;
{} = args;
returns
Line 1: Missing quote
Line 1: Missing quote
Line 1: parse error
The Missing quote case seems thus to be the only error aborting the
parsing of the rest.
Why is this so? Would you consider this a bug (... to be reported to
Sourceforge), or am I just missing something? Cannot find it anything
usefull on google, nor on
http://sourceforge.net/tracker/?atid=103692group_id=3692func=browse etc.
(Another thing: It would be very nice to have fmt_error() return not
only the line number, but the charater position as well... with the
missing quote, that would per def. be EOL, and not very helpful, of
course, but the other compiling error cases would be nice to have an
index for. Would that mean having lex_getc() return something and then
passing it along for every case? ... I couldn't possibly do it.)
Thanks for input:
- Daniel
#
This message is sent to you because you are subscribed to
the mailing list [EMAIL PROTECTED].
To unsubscribe, E-mail to: [EMAIL PROTECTED]
To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED]
To switch to the INDEX mode, E-mail to [EMAIL PROTECTED]
Send administrative queries to [EMAIL PROTECTED]
