dynoplibs in core or no?
wknight8111 at gmail.com
Tue Jun 1 21:46:26 UTC 2010
The printerr opcode disappearing would be fine if the getstderr opcode
hadn't disappeared. What we need is a good, reliable way to get
FileHandle PMCs for STDIN, STDOUT, and STDERR. Once we have a handle,
the print_p_s opcode works just fine for almost all purposes. There is
an stdhandle method on the interpreter PMC, but that one is listed as
experimental and apparently it isn't well-liked.
What we need is any solution to this problem, I can't say I'm
particularly partial to any of the available options.
On Tue, Jun 1, 2010 at 4:38 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> 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
>> 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.
More information about the parrot-dev