dynoplibs in core or no?

Will Coleda will at coleda.com
Tue Jun 1 23:22:09 UTC 2010


My vote is to resurrect the getstd* opcodes.

Since the general consensus seems to be "doesn't matter", let's move
these back.

On Tue, Jun 1, 2010 at 5:46 PM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> 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.
>
> --Andrew Whitworth
>
>
>
> 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
>>> 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
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Will "Coke" Coleda


More information about the parrot-dev mailing list