I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
Specificially, in S32-setting-library_Containers.pod, we currently have:
=item !eigenstates
method !eigenstates (Junction $j: --> Parcel)
Return
Aaron Sherman wrote:
On Tue, Oct 12, 2010 at 10:22 AM, Damian Conway wrote:
Perhaps we need to think more Perlishly and reframe the entire question.
Not: "What threading model do we need?", but: "What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to b
On Tue, Oct 12, 2010 at 10:22 AM, Damian Conway wrote:
> Perhaps we need to think more Perlishly and reframe the entire question.
> Not: "What threading model do we need?", but: "What kinds of non-sequential
> programming tasks do we want to make easy...and how would we like to be
> able to spec
I've done quite a lot of concurrent programming over the past 23ish years,
from the implementation of a parallelized version of CLIPS back in the late
80s to many C, Perl, and Python projects involving everything from shared
memory to process pooling to every permutation of hard and soft thread
man
