Ticket #1271 (closed RFC: fixed)

Opened 5 years ago

Last modified 4 years ago

Ability to spawn Parrot processes from PIR in tests

Reported by: whiteknight Owned by: dukeleto
Priority: normal Milestone:
Component: testing Version: 1.7.0
Severity: medium Keywords: test op spawnw
Cc: Language:
Patch status: Platform: all

Description

the tests in t/op/spawnw.t all rely pretty heavily on the existence of Perl5. Each tests spawns an instance of perl and tests various return values from it. I suggest we should try to replace these with tests to spawn new instances of Parrot (or something else, possibly system dependent).

Change History

in reply to: ↑ description   Changed 5 years ago by jkeenan

Replying to whiteknight:

the tests in t/op/spawnw.t all rely pretty heavily on the existence of Perl5.

Well, seeing that the test itself is written in Perl5, that's a quite reasonable assumption :-)

I suggest we should try to replace these with tests to spawn new instances of Parrot (or something else, possibly system dependent).

Is Parrot itself fast enough yet that it would be reasonable to use in these tests?

kid51

  Changed 5 years ago by dukeleto

  • owner set to dukeleto
  • summary changed from t/op/spawnw.t relies heavily on perl5 to Ability to spawn Parrot processes from PIR in tests

Yes, we *really* need an easy way to create a new parrot process from within PIR, so that we can write certain tests that require this. I am *on* it.

We should not go the "system dependent" route.

  Changed 5 years ago by dukeleto

  • platform set to all
  • component changed from none to testing

  Changed 5 years ago by cotto

r42521 will likely be helpful in this task. I went the route of modifying FileHandle to keep track of the exit status of any children run in a pipe. I don't know if this is preferable to having spawnw keep track of the exit code. I just picked the one that seemed easier at the time. Either way, the code is in place and any stupid API decisions on my part can be modified since there hasn't been a "supported" release containing the change.

  Changed 4 years ago by bacek

Hello.

What we need is actually exit opcode to test spanw. Then we can rewrite this tests in pir/nqp/whatever. Perl is used just as convinient wrapper for "exit".

-- Bacek

  Changed 4 years ago by cotto

The tests in t/profiling/profiling.t depend on running PIR and nqp-rx code in a child process, verifying the output and the exit code. Is there any reason to keep this ticket open?

  Changed 4 years ago by cotto

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

whiteknight seems to be happy, so I'm closing this ticket.

Note: See TracTickets for help on using tickets.