Am Samstag, 5. Mai 2007 10:00 schrieb chromatic:
> On Thursday 03 May 2007 18:04:48 chromatic wrote:
> > I'll debug the segfault and see if that reveals anything interesting.
> >
> > The shootout tests are dodgy anyway sometimes.
>
> In this case, sorting the vtable functions put the init vtable me
On Thursday 03 May 2007 18:04:48 chromatic wrote:
> I'll debug the segfault and see if that reveals anything interesting.
>
> The shootout tests are dodgy anyway sometimes.
In this case, sorting the vtable functions put the init vtable method pointer
in the middle of the _vtable struct, not at t
The shootouts do not generally run under the default runcore, so these
are not ideal for a standard `make test`. For most of the tests, a
quick alternative for the slow runcore can be found(for some, the input
can be generated by fasta.pir). Both are ran under JIT, so it could be
a JIT proble
On Thursday 03 May 2007 17:54:42 Will Coleda wrote:
> In happier news, it makes partcl's 'make test' run in 75% of the time
> it did earlier in the week, so I'd rather find the one issue here
> rather than revert the patch.
I'll debug the segfault and see if that reveals anything interesting.
Th
On May 3, 2007, at 8:35 PM, chromatic wrote:
On Thursday 03 May 2007 16:22:13 [EMAIL PROTECTED] wrote:
Sort the vtable functions list alphabetically and use a binary
search when
looking functions up by name. This gets us part way to some of the
speedup
we should see from the pdd15 implemen
On Thursday 03 May 2007 16:22:13 [EMAIL PROTECTED] wrote:
> Sort the vtable functions list alphabetically and use a binary search when
> looking functions up by name. This gets us part way to some of the speedup
> we should see from the pdd15 implementation.
>
> Time to run ../../parrot tcl.pbc t/c
