Chromatic <[EMAIL PROTECTED]> wrote: > On Wed, 2004-11-24 at 15:04 +0000, Nicholas Clark wrote:
>> Quite a lot of us would just like parrot COMPLETE and CORRECT before >> starting to put a lot of effort into how fast it is. > I'd settle for it compiling (#32514). Well, having just a short look at the error message seems to reveal that your "as" doesn't croak the comment for the unused macro. I'd just remove that and try again. I can't test it. > ... If not for the broken build, I'd > have poked at three or four small TODO items and bugs in the past couple > of weeks. > An appropriate hierarchy of c-words is: > compiles -> correct -> complete -> competitive But anyway, yes. > First, Parrot must build on important platforms. Then it must pass the > tests. First is true most of the time, except for such platform stuff. I test on two platforms, 3 computers. Tests are currently not passing due to obvious violations of the recent pdd03 changes. t/op/gc_13.imc would still fail because of continuation and register allocation, it's just using lexicals now. > ... Then it must have all of the important features for the current > release. Only then (and maybe not even then, maybe for a future > release) does it need optimization. My mail - the originator of this thread, where this optimization philosophy discussion seems now to take place - doesn't propose an optimization, nor does it propose that scheme for that reason. The context layout I've shown is just a way (IMHO) to solve the correctness problem that currently exists. Honestly I would prefer to discuss that interpreter layout (or other realistic proposals that solve the problem). > -- c leo
