Ticket #264 (closed experimental: fixed)

Opened 6 years ago

Last modified 4 years ago

Add experimental method stdhandle to the interpreter pmc

Reported by: NotFound Owned by: whiteknight
Priority: normal Milestone:
Component: core Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

Added the method stdhandle to the interpreter pmc, following mailing list discussion: "Changing Default STDOUT/STDERR Filehandles for PIR Code", in r36305

This addition is experimental, no tests yet.

Change History

  Changed 6 years ago by NotFound

  • owner set to NotFound

Disabled temporarily until redoing without usage of io_private header

  Changed 6 years ago by NotFound

Reimplemented in r36357 by adding the function Parrot_io_stdhandle to src/io/api.c

  Changed 5 years ago by jkeenan

  • component changed from none to core

  Changed 5 years ago by allison

The second implementation is reasonable, but the name 'stdhandle' is awfully vague. Given that there are always exactly 3 filehandle pmcs that can be set and retrieved this way, it makes more sense to add meaningful method names like 'setstderr' and 'getstdout' to ParrotInterpreter and eliminate the magical integer argument.

The methods can all call the same function in src/io/api.c, named something verbose like Parrot_io_access_standard_handle (our C coding standards dictate longer meaningful names).

Allison

  Changed 5 years ago by coke

  • type changed from feature to experimental

  Changed 4 years ago by jkeenan

NotFound,

Would you be able to provide an update on the status of this ticket?

Thank you very much.

kid51

  Changed 4 years ago by whiteknight

I'm going to take a stab at replacing this method with the three new methods that Allison recommends. I'll create a branch for it and we can evaluate it there.

  Changed 4 years ago by NotFound

I thoght there were more comments on this ticket, maybe they were only in the mailing list?

The decision was to drop the methods and supporing only the get/set std in/out/err opcodes. So there is no point in testing more variants.

In order to close the ticket deleting the methods and its tests should be enough... but I think they can be in use in some HLL, better ask and check first.

I have no time now, but the decision can be found in the parrotsketch irclogs.

  Changed 4 years ago by whiteknight

  • owner changed from NotFound to whiteknight
  • status changed from new to assigned

The work in the branch is mostly complete, and I've put together a patch for NQP-RX for it too. I can merge these things after the release.

  Changed 4 years ago by pmichaud

The #parrotsketch discussion at  http://irclog.perlgeek.de/parrotsketch/2010-06-08#i_2415916 seems to indicate that the getstd* ops are to permanently remain in the core opcode set. I suspect the ticket was never updated with this decision.

Pm

follow-up: ↓ 13   Changed 4 years ago by whiteknight

Thanks for the find, Patrick.

That IRC log excerpt is informative but doesn't really answer the the question about these methods. The existance of dynops for this purpose not withstanding, we do have this stdhandle method on the ParrotInterpreter PMC and the last comments I can find about that method are here in this ticket saying we break it up into three methods.

I'm mostly complete that work, and will merge it in to trunk after the release, pending approval from...anybody.

in reply to: ↑ 12   Changed 4 years ago by jkeenan

Replying to whiteknight:

I'm mostly complete that work, and will merge it in to trunk after the release, pending approval from...anybody.

A patch, por favor?

kid51

  Changed 4 years ago by whiteknight

All the work I've done here is in the stdhandle_meths branch. I'll send an email to the developers list soon asking for feedback and testing.

  Changed 4 years ago by whiteknight

  • status changed from assigned to closed
  • resolution set to fixed

I've merged this branch in 7c6c8291a026911f12b7eb62489f426b19a9f86e. Closing ticket.

Note: See TracTickets for help on using tickets.