Bryce Kampjes wrote: > The big question is whether to work on blocks next.
Yes please! I'm looking forward to throwing away the compiler hacks that inline ifTrue:ifFalse: and friends. > It will also make the Exupery shutdown code more > important because an unmodified VM will not understand these new > context objects and require image support code to deal with compiled > contexts (say for debugging). That's very interesting. Are you going to pursue a Self-style revert-to-simpler-representations-on-demand strategy? > The top four items are: > * blocks > * super sends > * new > * integration (making primitive inlining usable and the > the profiling compiler effective) What's different about super sends as compared to regular sends? Isn't the statically-available information better for super sends, and otherwise they're more-or-less the same? (What am I missing? I should perhaps have my morning coffee.) I'd vote for blocks, new, integration, super-sends to be the order. Cheers, Tony -- [][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211 [][] LShift Ltd | Tel: +44 (0)20 7729 7060 [] [] http://www.lshift.net/ | Email: [EMAIL PROTECTED] _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
