[1636] 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 11:18:28 2001 )

Message-ID: <3A5B36E2.C509CBEB@cubik.org>
Date: Tue, 09 Jan 2001 09:05:54 -0700
From: Bruce <bruce@puremagic.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

Allen Noe wrote:
> 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.

I'd rather try to make sure that I'm getting as much of the
existing stuff as possible, rather than ignore patches that are
3+ months old.

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

Okay.  My addition here was to start caching failed lookups, so
it isn't as a big a win for most people as the work that was
originally done.

> > > * 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.

There's no cost to getting the pc, just the line numbers.

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

Well, not quite redundant as task_info() returns some information
that stack() doesn't. (Like the value of user() per-frame.)  But
I needed the ability to print out the stack for any thread in
native code within the driver, so I already had to extend the
internal machinery to support getting the stack for any task.
(Now, when there is a server panic, it will try to print the
stacks of all the tasks, which is invaluable when you get
emalloc() failures occasionally and have no idea why.)

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

Well, I could make stack() take an optional second argument that
would control whether or not line numbers were calculated:

stack() -- current task, generate line numbers
stack(828)  -- task 828, generate line numbers
stack(828, 0) -- task 828, don't genererate line numbers
stack(task_id(), 0) -- current task, don't generate line

I could do that if it were seen as important enough.

> > > * 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.

Great. I'd just as soon put these in the stable release then.

> > > * 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.

We'll see how much time I can scrape up.  It should just take
about 10 minutes to make this a native, once I get it patched
into my tree as it exists now.

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

I'll just grab what I need from your patches ..

Are there other outstanding patches or have you created new ones
since this original post?  Also, I -know- that some of the work
that I'm aiming to get into this next release will break Win32 as
it brings in the use of Posix threads.

 - Bruce