Jeff wrote: > > Tom Hughes wrote: > > > > In message <[EMAIL PROTECTED]> > > Mike Lambert <[EMAIL PROTECTED]> wrote: > > Oops. That only went in yesterday... Now fixed. > > > > > Overall, tho, the patch looks extemely complete. Tracing support, > > > disassemble.pl support, debug.c support, etc. You even reduced macro > > > usage. Rather impressive. :) > > Agreed. > > > The tracing, disassembly etc was mostly done when I found I needed > > it to try and find a problem in the other things I'd done ;-) > > > > One other outstanding problem that I remembered last night is that > > it is allocating memory for the key atom which is attached to the > > cache.struct_val member on the PMC but which is never freed. > > > > Allocating that small piece of memory as a buffer which can be GCed > > seems like complete overkill, but short of marking the PMC as having > > a private GC so it can cleanup I hadn't managed to come up with a > > solution. > > > > What I realised last night however is that there is enough space in > > the private flags on the PMC for the type information and I can then > > attach the data directly to the cache and do away with key atoms > > completely... I shall get on with that now and post a new patch later. > > It's not quite applying against the current build, however. > classes/default.pmc was easy to fix, assemble.pl not so simple, core.ops > and hash.c had other problems. Could I trouble you to fix these so I can > commit it tonight? I can send you the rejected hunks if you like...
Sorry about the QA comment, I just had someone point out to me that was mail server mangling. Many apologies. It -really- looks like a nice patch, if we can get these few problems ironed out. -- Jeff <[EMAIL PROTECTED]>
