Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

4 views
Skip to first unread message

Klaas-Jan Stol

unread,
Feb 23, 2007, 4:44:22 PM2/23/07
to bugs-bi...@rt.perl.org
# 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

vtable_pbc_test_skip_right_now.patch

Klaas-Jan Stol

unread,
Feb 24, 2007, 11:05:45 AM2/24/07
to parrotbug...@parrotcode.org
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

unread,
Feb 24, 2007, 12:12:58 PM2/24/07
to perl6-i...@perl.org, Klaas-Jan Stol, parrotbug...@parrotcode.org
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

unread,
Feb 25, 2007, 6:28:05 AM2/25/07
to Leopold Toetsch, perl6-i...@perl.org, parrotbug...@parrotcode.org
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

unread,
Feb 26, 2007, 2:14:32 PM2/26/07
to perl6-i...@perl.org, Klaas-Jan Stol, parrotbug...@parrotcode.org
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

unread,
Feb 26, 2007, 2:42:50 PM2/26/07
to Leopold Toetsch, perl6-i...@perl.org, Klaas-Jan Stol, parrotbug...@parrotcode.org
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

unread,
Feb 26, 2007, 6:02:40 PM2/26/07
to jerry gay, Leopold Toetsch, perl6-i...@perl.org, parrotbug...@parrotcode.org
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

0 new messages