Here's a patch for discussion. It adds a new test module that uses a Parrot
embedded in Perl 5 to run pir_output_*() tests. It's a bit fragile and
depends on Embed::Parrot (which I haven't checked in yet). I'm just posting
it here to document that it exists and works in some cases, and to get any
feedback.
I'll post my concrete, enumerated questions about checkin in Embed::Parrot in
a separate message.
-- c
Two things come to my mind:
1) why is it creating 2 interpreters? What is the $parent used for?
And related: is $interp ever cleaned up by calling Parrot_exit()?
2) This looks a bit bogus (there is no 'V' signature char):
my $out_pmc = Parrot::Embed::call_sub( $interp, $sub, 'PV', '' );
my $output = Parrot::Embed::get_string_from_pmc($interp, $out_pmc);
It could just be:
my $output = Parrot::Embed::call_sub( $interp, $sub, 'Sv');
by returning the STRING* directly.
leo
> Two things come to my mind:
> 1) why is it creating 2 interpreters?
Per my experiments, this worked out the best. That is, if there's an error in
the compiled code, reusing an interpreter gave weird answers. I haven't
tracked this down in more detail.
> What is the $parent used for?
It's the parent of the interpreter created in the pir_output_*() functions.
Creating new subsequent interpreters without providing $parent gave weird
encoding assertion errors.
> And related: is $interp ever cleaned up by calling Parrot_exit()?
Nope, but I'll put a destructor in Embed::Parrot::Interpreter when I get that
far.
> 2) This looks a bit bogus (there is no 'V' signature char):
>
> my $out_pmc = Parrot::Embed::call_sub( $interp, $sub, 'PV', '' );
> my $output = Parrot::Embed::get_string_from_pmc($interp, $out_pmc);
>
> It could just be:
>
> my $output = Parrot::Embed::call_sub( $interp, $sub, 'Sv');
>
> by returning the STRING* directly.
True, but I prefer to use the PMC methods rather than fiddling around
converting strings to and from the C format. If this API changes to send and
receive char * instead of STRING *, I'll happily use that.
-- c