[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] Re: [encore] line number in callers()
Sean Davis wrote: Yes. In fact, it surprises me very much that I can load a core on a MSB LP64 machine (UltraSPARC in this case) and have it work just fine. Then again, UltraSPARC is not nearly as picky as Alpha when it comes to unaligned memory access. It's exactly as picky, but your SPARC OS (Solaris?) probably does unaligned trap handling in software, whereas your Alpha OS (Tru64?) doesn't. -hpa # 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: forked moo servers
There are still another few things I could wish we could incorporate into a possible new lamdaMOO release. I wonder if we could compute a list of changes that have been done in the various versions, and then possibly merge them into one? A 2.0 release goal would be mega cool. Please keep this list updated. How about this for a strawman: would anyone on this list object to calling LukeJr's GammaMOO LambdaMOO 2.0, So long as the MOO code is backwards compatible with non GammaMOO cores. Minor enhancement request: * Remove the auto-aliases for : ; into a simple configuration file. (Eg to allow for ' - say ; : - emote | - eval) Rob ,'/:. Dr Robert Sanderson ([EMAIL PROTECTED]) ,'-/.http://www.o-r-g.org/~azaroth/ ,'--/::(@)::. Dept. of Computer Science, Room 805 ,'---/::.University of Liverpool /:. L5R Shop: http://www.cardsnotwords.com/ I L L U M I N A T I # 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: forked moo servers
On Monday 06 December 2004 15:55, H. Peter Anvin wrote: Dr Robert Sanderson wrote: Minor enhancement request: * Remove the auto-aliases for : ; into a simple configuration file. (Eg to allow for ' - say ; : - emote | - eval) Probably should just be a server object control property. Or nothing? I bet this behaviour could be emulated completely with #0:do_command and force_input(). TTFN Andy # 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: forked moo servers
As far as all this goes, I have a few suggestions. First, no offence to Luke-Jr, but I've ran into a lot of compilation glitches with GammaMoo and its code-quality isn't all that great. I'd suggest either starting from the current Lambda CVS and merging third-party patches for a 2.0 release or taking Foo (which has always compiled on everything I tried it on, at least :). Whether this is accomplished by taking control of the current SF project, or creating a second one is the first decision that needs to be made. The current SF project would have worked quite well, if patches in the patch tracker were ever actually looked at. That said, since I see a lot of the initial work to be simply gathering patches and improvements into the one central codebase the first couple of developers really just need to be decent coders who have enough time to actually look at the patches. Initially I'd suggest: * Two project admins for sanity (I elect hpa and dive) * Two or three developers to vet and commit patches and diffs. * Someone coming up with a moo-code core to regression-test the server * People making diffs Most of the development should initially be recommendations/diffs of code to merge. As long as quality-of-code is maintained and nobody runs out of time to merge or make patches, CVS should get up to scratch pretty quickly. And if the regression-core is ready, then all is good. Furthermore, I'd suggest that 2.0 have a 'plugin' system, for registering builtins by loading shared objects listed in a config file (Eg, LoadModule FUP). I'm hoping that everyone has posix dlopen() support or a wrapper by now? :) Cheers, -- James 'Ender' Brown http://www.quakesrc.org/ http://www.scummvm.org/ # 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]
