On Wed, Aug 21, 2002 at 02:10:22PM +0200, Peter Gibbs wrote: > Mike Lambert wrote: > > If you don't mind, please feel free to continue your work on parrot-grey. > The problem arises with trying to do new experimental development, > which still keeping sufficiently in sync with cvs parrot that I can do a > 'cvs update' from time to time without getting dozens of conflicts. > A case in point is the new 'strstart' field - grey doesn't need it, but to > leave it out would create a large number of differences between the > two versions, with code having to be changed every time somebody > writes a new reference to it - therefore if I do continue with grey, I will > just probably just leave strstart in, and ignore the memory overhead. > The next item on the list for grey was paged memory allocation - this > may be usable to some extent without the buffer linked lists; so I will > probably give that a spin anyway.
I know very well what you mean, but this particular case could be bludgeoned to death with a #define strstart bufstart, no? I'm also inclined to think that Peter's parrot-grey experimentation is important enough right now to commit using #ifdef PARROT_GREY. Sure, it's a rotten long-term solution, but we could take it out before too long. (And Peter would have to be okay with other people periodically breaking his stuff by doing commits that don't update the PARROT_GREY path, since most people wouldn't be testing it. But it'd still be easier than maintaining something like that externally.) What do people think? After all, this strongly impacts one of the top stated goals for Parrot: more speed. Oh, and it might have to be only partial, to keep the more "illegal" bits out of CVS. Peter would have to decide whether it would be worth it then. Or we could just commit a test that does a couple of things like longjmp() that will break parrot-grey, and maybe Peter will figure out a way around it. :-)
