On Thu Oct 23 01:38:59 2008, mgrimes wrote:
Christoph,
Thanks for your help. This has been a great, low intensity, way to
learn a bit of parrot.
I think I have addressed everything, and I have attached a new patch.
The patch no longer applies cleanly to objects.t, and I thought
it'd be
jerry gay wrote:
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes [EMAIL PROTECTED] wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:
1) I am not sure how to deal with pcc_sub's so I put them into
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label. If the exception is
raised, control will jump to
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes [EMAIL PROTECTED] wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:
1) I am not sure how to deal with pcc_sub's so I put them into
t/pmc/objects-pcc_sub.t
2) There
On Thu Oct 16 17:43:28 2008, mgrimes wrote:
Hi,
The attached patch converts two perl based tests into parrot tests:
t/pmc/string.t
t/pmc/objects.t
Each of these included pir_error_is type tests. I am not aware of
any way to test those within parrot right now, so I kept them in perl
I have to write some unit tests for the Parrot::IO::* and
Parrot::Docs::* modules and I'm wondering where to put them.
How about creating t/perl and adding Parrot_IO_*.t etc? Or should I go
for a t/perl/Parrot/IO/*.t approach? Someone help me make up my mind.
No need for them to be run with
