On Tue, Jun 01, 2010 at 09:41:19PM +0200, NotFound wrote: > > it would even be worthwhile to step back and re-think whether all the ops > > that were moved out of core really should have been moved. If every > > non-trivial program now needs to load several dynop libraries, is there > > really any benefit? (I do not mean to prejudge the answer, only to remark > > that it might be worthwhile to address the question, now with the benefit > > of a little hindsight.) > > That's not entirely true. Winxed now avoids the usage of the ops moved > to dynops and can compile himself, which is not a trivial task. > However, it does by using the experimental method stdhandle not > approved for permanent presence, otherwise it can't print error > messages. > > I certainly don't think one must load any dynamic part to be able to > write a diagnostic message. How can you report a diagnose about > failing to load dynops? > > Please don't answer "Write diagnostics to standard output".
I agree with NotFound++. The removal of the printerr opcode is one place where I think the ops removal went just a bit too far. There may be others, but that's definitely the one that sticks out to me. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
