Many of the tasks created for Parrot's Google Code-Inn participants have
involved boosting the percentage of our source code touched by our test
suite. This had the secondary effect of focusing our attention on the
adequacy (or lack thereof) of our code coverage tools. What used to be
called
The work in this branch is something that we do want. As a little bit
of background IMCC creates Sub PMCs from the .sub/.end directives that
it parses, and attaches flags to the Sub PMC. so :main adds a MAIN
flag to the sub, :init adds an INIT flag to the sub, etc. These
flagged Sub PMCs are stored
The encapsulate-main branch moves tracking of :main-tagged subs from
the subs themselves to packfiles (which should really be taking care
of this kind of thing). At the same time, it tackles TT #1704, which
requires a :main sub (no more automagic
first-encountered-sub-is-main).
At this point, it p
On Fri, Dec 31, 2010 at 12:05 PM, chromatic wrote:
> I agree with the rationale for replacing the existing threading system, but is
> it really so unrecoverable that we can't use our traditional mechanism of
> replacement?
>
> 1) design a better API
> 2) hide the current malfeasances behind said A
On Friday 31 December 2010 at 07:48, Andrew Whitworth wrote:
> I would like to deprecate and remove Parrot's threading system. This
> system does not really work for anything beyond the most trivial
> tasks.
I agree with the rationale for replacing the existing threading system, but is
it really
I would like to deprecate and remove Parrot's threading system. This
system does not really work for anything beyond the most trivial
tasks. Some issues:
1) Threading does not work with HLLs, (TT #757)
2) t/pmc/thread.t is very finicky and seems to provide spurious
failures every so often due to t
