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
>
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
t/pmc/objects-pcc
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)
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
se within parrot right now, so I kept them in perl
> tests and move them to t/pmc/string-errors.t and
> t/pmc/objects-errors.t.
>
> Converting these test to pir dropped their run time from 19 secs to 3
> secs, and more than 2 of those seconds are spent in the *-errors.t
> tests.
&g
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 mak
