[perl #41604] [BUG] pbc_output_is doesn't work?

[Klaas-Jan Stol]

# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41604]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41604 >

hi,

I was trying to add a test that runs some PIR code as PBC.

(so, the specified PIR code should be compiled to PBC, *THEN* it should
be run to compare output).

It seems the .pbc file is *not* created.
I'm no Perl god, so reading the Parrot::Test script is kinda hard for me.
I couldn't find any other tests that run pbc_output_is() (but
admittedly, I didnt' look for too long), so it might be this function is
never used. Parrot::Test does mention it, though.

Attached a patch that adds the tests, but SKIPPING it currently. As soon
as the bug is resolved, it can be run.

regards,
klaas-jan

[Klaas-Jan Stol]

James Keenan via RT wrote:

> On Fri Feb 23 13:44:22 2007, parro...@gmail.com wrote:
>
>> I couldn't find any other tests that run pbc_output_is() (but
>> admittedly, I didnt' look for too long), so it might be this function is
>> never used.
>>
>

> [parrot] 577 $ find t -name '*.t' | xargs grep -n pbc_output_is
> t/native_pbc/integer.t:58:pbc_output_is( undef, '270544960', "i386 32 bit opcode_t, 32 bit
> intval" );
> t/native_pbc/number.t:88:pbc_output_is( undef, $output, "i386 double float 32 bit opcode_t"
> );
> t/native_pbc/number.t:91:# pbc_output_is(undef, <<OUTPUT, "i386 long double float 32 bit
> opcode_t");
> t/native_pbc/number.t:92:# pbc_output_is(undef, <<OUTPUT, "PPC double float 32 bit BE
> opcode_t");
> t/native_pbc/number.t:93:# pbc_output_is(undef, <<OUTPUT, "little-endian 64-bit tru64");
> t/native_pbc/number.t:94:# pbc_output_is(undef, <<OUTPUT, "big-endian 64-bit irix");
> t/native_pbc/string.t:54: pbc_output_is( undef, $output, "i386 32 bit opcode_t, 32 bit
> intval" );
> t/perl/Parrot_Test.t:53: pbc_output_is pbc_output_like pbc_output_isnt
>
> How would these instances affect the problem?
>
it seems the .pbc files are stored in the repository.... is that
desirable? IMO, it would be enough to store the PIR only, and have that
compiled to PBC, and only *then* do the test. But if that is not
possible, then so be it. (of course, it might be a good thing to have
ALL test cases run twice: as PIR and as PBC)
> kid51
>
kjs

[Leopold Toetsch]

Am Samstag, 24. Februar 2007 17:05 schrieb Klaas-Jan Stol:
> it seems the .pbc files are stored in the repository.... is that
> desirable?

Yes for these files.

> IMO, it would be enough to store the PIR only, and have that
> compiled to PBC

If you have a closer look at these .pbcs, you'll see that they are generated
on machines of very different flavours (LE, BE, 32, 64bit). The tests are
checking that one parrot can read all these .pbcs.

leo

[Klaas-Jan Stol]

ok, I didn't look that close.

Can you tell whether pbc_output_is() can take PIR code and compile it
during running the test? Or does is always expect the pbc file to be
present?

kjs

[Leopold Toetsch]

Am Sonntag, 25. Februar 2007 12:28 schrieb Klaas-Jan Stol:
> Can you tell whether pbc_output_is() can take PIR code and compile it
> during running the test? Or does is always expect the pbc file to be
> present?

As said, it doesn't make sense to feed .pir code into these tests. So no /
yes.

leo

[Jerry Gay]

testing functions which accept pir as input, compile to pbc, and run
the pbc, do not exist. *however* the flags to parrot do exist
(--output-pbc in combination with --run-pbc should do it.)

therefore, the possibility exists to create these testing functions.
it can probably be bolted on fairly quickly, but Parrot::Test is such
a mess, it may be better to de a little refactoring first to make this
easier. i don't know which i'll get to first.

so, this is an opportunity for somebody to beat me to either of those
things--patches welcome.
~jerry

[Klaas-Jan Stol]

jerry gay wrote:
> On 2/26/07, Leopold Toetsch <l...@toetsch.at> wrote:
>> Am Sonntag, 25. Februar 2007 12:28 schrieb Klaas-Jan Stol:
>> > Can you tell whether pbc_output_is() can take PIR code and compile it
>> > during running the test? Or does is always expect the pbc file to be
>> > present?
>>
>> As said, it doesn't make sense to feed .pir code into these tests. So
>> no /
>> yes.
>>
> testing functions which accept pir as input, compile to pbc, and run
> the pbc, do not exist. *however* the flags to parrot do exist
> (--output-pbc in combination with --run-pbc should do it.)
>

ok, that's what I wanted to know, thanks! (I didn't know pbc_output_is()
was specifically for testing pbc files of different platforms)

> therefore, the possibility exists to create these testing functions.
> it can probably be bolted on fairly quickly, but Parrot::Test is such
> a mess, it may be better to de a little refactoring first to make this
> easier. i don't know which i'll get to first.

I can't help here, my knowledge of Perl is too minimal, sorry.

>
> so, this is an opportunity for somebody to beat me to either of those
> things--patches welcome.
> ~jerry

kjs