Perl6-Pugs
view release on metacpan or search on metacpan
docs/Perl6/Spec/Concurrency.pod view on Meta::CPAN
}
my Foo $f .= new;
async { $f.a }
async { $f.b }
- Thread::Status
- IO objects and containers gets concurrency love!
- $obj.wake_on_readable
- $obj.wake_on_writable
- $obj.wake_on_either_readable_or_writable_or_passed_time(3); # fixme fixme
- $obj.wake_on:{.readable} # busy wait, probably
my @a is Array::Chan = 1..Inf;
async { @a.push(1) };
async { @a.blocking_shift({ ... }) };
async { @a.unshift({ ... }) };
Communication abstractions
- shared, transactional variables by default
# program will wait for _all_ threads
docs/notes/multi_method_dispatch/mmd.kwid view on Meta::CPAN
[16:54] nothingmuch: huraah!
[16:54] nothingmuch: and this delegation is a simple form, btw
[16:54] nothingmuch: anyway, i'm off,it's already 17:00
[16:54] autrijus: I'm a bit uncomfortable seeing it in modules/ :)
[16:54] nothingmuch: but I shall return energized and motivatred
[16:54] autrijus: please write some t/
[16:54] nothingmuch: i will do that soon
[16:54] autrijus: and I'll see about delegation
[16:54] nothingmuch: ti's not even valid perl yet
[16:54] autrijus: nod. cool, take care, see you in a bit
[16:55] nothingmuch: it's just been a very busy weekend, and I didn't want to keep that to myself alone
docs/summaries/2006/03-31.pod view on Meta::CPAN
=head3 L<Fix for tailcall after newcloser|http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/5e7c5eb717b6f077/0a995e036447de5b#0a995e036447de5b>
Bob Rogers sent PIR code illustrating a problem in tailcall which forces
the old context to be recycled and included a patch.
=head3 L<Rare failure of t/dynoplibs/myops alarm sequence|http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/0acddee305aad8fa/5aecfecca5f12417#5aecfecca5f12417>
Tim Bunce noted a failing alarm sequence test in F<t/dynoplibs/myops.t>
but has not been able to duplicate it. Leopold Toetsch reported that
this could happen if the machine was busy. Tim requested a warning, and
Leopold agreed it would be appropriate.
=head3 L<Valgrind reports|http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/9b2860442672762e/f287c5609dd73f58#f287c5609dd73f58>
chromatic got Valgrind working on his Linux PPC box and wanted to know
if the reports would be useful. Leopold Toetsch welcomed the information.
=head3 L<Todo: fill Parrot_register_move()|http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/700f4975f9286001/384ec3764fd0cdd0#384ec3764fd0cdd0>
Leopold Toetsch created a ticket
docs/summaries/2006/07-31.yaml view on Meta::CPAN
- date_from: 1152252379
date_to: 1154646016
hidden: ~
message_id: rt-3.5.HEAD-13959-1154646008-694.39753-15-0@perl.org
posters:
- email: parrotbug-followup@parrotcode.org
name: Chip Salzenberg via RT
rt_ticket: 'perl #39753'
subject: '[perl #39753] parrot@13183: tru64 core dump: t/pmc/io_1.pir '
summary: |-
Jarkko Hietaniemi was busy reporting another issue in ticket
<rt://perl/39753>. Chip Salzenberg noted that this ticket could
not be resolved without a review of the I/O PDD.
- date_from: 1152252409
date_to: 1154644532
hidden: ~
message_id: rt-3.6.HEAD-19067-1152252390-965.39754-72-0@perl.org
posters:
- email: parrotbug-followup@parrotcode.org
name: Jarkko Hietaniemi
rt_ticket: 'perl #39754'
docs/summaries/2006/08-19.yaml view on Meta::CPAN
messages:
- rt-3.6.HEAD-19063-1152252356-252.39753-72-0@perl.org
posters:
- email: parrotbug-followup@parrotcode.org
name: Chip Salzenberg via RT
rt_ticket: 'perl #39753'
subject: '[perl #39753] parrot@13183: tru64 core dump: t/pmc/io_1.pir'
summary: |-
This thread was previously completely summarized in July.
Jarkko Hietaniemi was busy reporting another issue in ticket
<rt://perl/39753>. Chip Salzenberg noted that this ticket could
not be resolved without a review of the I/O PDD.
- date_from: 1152252409
date_to: 1154644532
hidden: ~
message_id: rt-3.6.HEAD-19067-1152252390-965.39754-72-0@perl.org
messages:
- rt-3.5.HEAD-13963-1154644510-1067.39754-15-0@perl.org
posters:
- email: parrotbug-followup@parrotcode.org
examples/network/svnbot.pl view on Meta::CPAN
There's no separate installation step needed, simply run C<svnbot.pl> and
supply appropriate options.
=head1 FAQ
"I configured svnbot to check for new commits every I<n> seconds, but the
commits usually take much more time to show up. Why is this so?"
If you look at svnbot's source, you'll see that it really I<tries> to check the
SVN repository after I<n> seconds elapsed. The problem is, that svnbot doesn't
have a chance to check, because C<Net::IRC> is busy reading from the socket to
the IRC server. Unfortunately, the call to C<.readline> C<Net::IRC> issues is
I<blocking>, meaning that the operating system will suspend C<svnbot.pl> until
it receives some data from the IRC server.
In Perl 5, the problem would be easy to remedy, as perl5 allows you to set
timeouts. But, as Pugs doesn't have a mechanism to set timeouts yet, there's
nothing C<Net::IRC> can do about it.
examples/qotw/009r/words.spel view on Meta::CPAN
Bushnell
bushwhack
bushy
business
businessman
businessmen
buss
bust
bustard
bustle
busy
but
butadiene
butane
butch
butchery
butene
buteo
butler
butt
butte
ext/Algorithm-TokenBucket/lib/Algorithm/TokenBucket.pm view on Meta::CPAN
allow 2 mails per minute but no more than 20 mails per hour.
Go, go, go!
my $rl1 = new_bucket(rate => 2/60, burst_size => 1);
my $rl2 = new_bucket(rate => 20/3600, burst_size => 10);
# "bursts" of 10 to ease the lag but $rl1 enforces
# 2 per minute, so it won't flood
while(my $mail = get_next_mail()) {
until($rl1<conform>(1) and $rl2<conform>(1)) {
busy_wait();
}
$mail.take_off();
$rl1<count>(1); $rl2<count>(1);
}
=head1 BUGS
Documentation lacks the actual algorithm description. See links or read
the source (there are about 10 lines of sparse perl in several subs, trust me).
( run in 0.299 second using v1.01-cache-2.11-cpan-3cd7ad12f66 )