Larry Wall [EMAIL PROTECTED] wrote:
Assuming we
rehuffmanize kill to sendsignal or some such, we have:
signal is a verb as well as a noun.
sub alarm ($secs) {
{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
}
It even reads pretty nicely: signal 4242.
--
Brent 'Dax'
On Thu, Apr 21, 2005 at 01:51:36PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall [EMAIL PROTECTED] wrote:
: Assuming we
: rehuffmanize kill to sendsignal or some such, we have:
:
: signal is a verb as well as a noun.
:
: sub alarm ($secs) {
:{ signal $*PID, Signal::ALARM
Gaal Yahas [EMAIL PROTECTED] wrote:
Two things popped up while implementing a demo version of alarm() today.
1. In perl5 and in most underlying libraries, alarm() has 1 second
granularity
2. ..., in which you can
pass an optional closure to alarm()
I can't say anything about the actual
On Wed, Apr 20, 2005 at 08:20:04AM +0200, Leopold Toetsch wrote:
: I can't say anything about the actual Perl6 syntax, but Parrot provides
: sub-second resolution as well as alarm callbacks and of course multiple
: timers.
We will certainly be pushing all the time interfaces of Perl 6 toward
On Wed, Apr 20, 2005 at 10:11:35AM -0700, Larry Wall wrote:
We will certainly be pushing all the time interfaces of Perl 6 toward
using floating-point time values. The only question is whether alarm()
is the right name for one of the interfaces, and whether we even need an
interface whose
On Wed, Apr 20, 2005 at 09:29:17PM +0300, Gaal Yahas wrote:
: (FWIW, this is called signalProcess in Haskell.)
Also in the FWIW department, I mislike mixed-case identifiers for
anything in the core. That sort of things screams user-defined
to me.
To a lesser extent, I also tend to avoid
GY == Gaal Yahas [EMAIL PROTECTED] writes:
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
}
Though I suppose people really mostly just want something like
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.delay($secs);
}
The
Two things popped up while implementing a demo version of alarm() today.
1. In perl5 and in most underlying libraries, alarm() has 1 second
granularity (and a possible 1 second error on top of that). Can we have
the alarm builtin not assume the worst, and take a Num instead of an
Int, so that on
