[1635] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: Genesis 1.1.9 - STABLE

daemon@ATHENA.MIT.EDU (Tue Jan 9 03:13:21 2001 )

Message-ID: <3A5AC32F.733A82D@geocities.com>
Date: Tue, 09 Jan 2001 01:52:15 -0600
From: Allen Noe <psyclone42@geocities.com>
MIME-Version: 1.0
To: coldstuff@cold.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: coldstuff@cold.org

Bruce wrote:
> This is a very delayed response, but I need to see a dev release
> made fairly soon to get some large changes into wider testing.

Uh, am I holding you up? Feel free to take what you can use and drop the rest if
you need to make a release RSN. None of this is so amazingly important that the
rest of the world needs to wait.

> > In the dev one:
> > * Some method-cache stuff, if you're impatient. (Bruce)
> I think this isn't the full version.  At any rate, I have a far
> larger patch with many more optimizations and enhancements that
> Brad and I have been working on that includes this.

That's correct -- it's the old version you posted to this list. If you have a
better version, then this one is pointless. Like I said, it was for the people
who couldn't wait for the full version.

> > * Have stack(1) not bother returning line number or pc. (me)
> This conflicts with an extension that I've made to stack() that
> allows you to specify which task you'd like to get a stack for.
> While this info is available from task_info(), it isn't in the
> same format as stack() and traceback().  I didn't know about the
> stack trace being in task_info() until I'd already done my work,
> so I'm not clear what I'd like to do here.  To me, it makes sense
> for stack() to present that information, but the duplication
> seems wasteful. (I already had to change the underlying stuff in
> execute.c to let task_stack() work for any given task for some of
> the other work that has been going on.)

Hmm. Sounds interesting, but I don't see how I would use it. I won't push too
hard for my stack patch, other than that if you call stack() a lot, and don't
need line numbers or the pc -- just objects and methods -- it saves having to
parse the bytecode.

I agree that stack(TID) should return that TID's stack, and also that returning
the frames in task_info is then made redundant.

It looks like task_info is less complex than stack(TID) should be (never having
seen the latter's code), since task_info does not have to calculate line
numbers; however if line numbers are needed, your stack(TID) is the only way I
see to get them for another process's stack.

I can always create a separate function to do what I have stack(1) do if it ends
up conflicting -- that convention is just to save a function and be slightly
portable: (| stack(1) |) || stack() should always compile and work.

> > * Have method_bytecode() return jumps so if (1) { return 1; }
> >   return 0; has different bytecode than if (1) { return 1;
> >   return 0; } (me)
> > * Add SYMBOL calling_method(), the same as stack()[2][3] (me)
> These 2 look fine for the stable release to me, if they aren't
> buggy.  How long and to what extent have you been using these
> bits of code?

I'm not sure about how often method_bytecode is used, but calling_method is used
for just about every permission check, and more.

Both have been in place for months.. at least 7, perhaps 10 if I read these
timestamps right. I did find and fix a bug in calling_method where it would
dereference a NULL pointer (cur_frame->caller_frame) if called from a method
called by the driver, but that's it. The method_bytecode patch is four lines
long -- it adds a case to the big switch there.

> > * Add LIST explode_quoted(STRING), which is a native version
> >   of ColdCore's $string.explode_quoted() (Jeremy Weatherford)
> Hmmm. Would be nicer to see this as a native method on $string.
> I may do that work for you since it is pretty easy if you prefer.

It's not my code; I just took what Jeremy posted and patched it in. I also think
it would be much better as a native, but don't have enough round tuits. If you
want to hack it, by all means, go ahead.

Do you want to see a patch of the 4 things you haven't raised issues about, or
can you just edit the patch file?