On Tue, Jan 30, 2001 at 09:43:37AM -0600, Jarkko Hietaniemi wrote:
I guess it's part of the can of sub-second worms: if we do sleep(),
people will ask why don't we do time() and alarm(), too. sleep() and
alarm() we could get away with more easily, but changing time() to do
subsecond
On Tue, Jan 30, 2001 at 10:49:56AM -0500, Dan Sugalski wrote:
Also there isn't a portable way to do subsecond sleeps. Not that it's
stopped perl before, but on some of the platforms that perl 5 runs on there
isn't *any* way to do it.
Then how does select(undef, undef, undef, 0.25) work on
On Tue, 30 Jan 2001 04:13:39 -0500, Michael G Schwern wrote:
Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
sleep($time);
}
else {
[EMAIL PROTECTED] wrote:
sub Time::Local::time {
return int(CORE::now());
}
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.
On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote:
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.
It doesn't have to be like that. Functions
On Wed, Jan 31, 2001 at 12:58:01PM +0100, Bart Lateur wrote:
On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote:
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to
Bart Lateur wrote:
One of your problems is that sleep(3) is NOT garanteed to sleep exactly
3 full seconds. It's only garanteed that the difference between time()
before, and after, will be (at least) 3. So sleep 3 actually just has to
wait for 3 time second rollovers. That may take for
Nicholas Clark wrote:
On Wed, Jan 31, 2001 at 12:58:01PM +0100, Bart Lateur wrote:
It doesn't have to be like that. Functions that are not in the core can
still be automatically loaded, but only if your code actually uses them.
That could make the perl kernel a lot smaller than it is now,
On Wed, Jan 31, 2001 at 12:04:46PM +, Nicholas Clark wrote:
It doesn't have to be like that. Functions that are not in the core can
still be automatically loaded, but only if your code actually uses them.
That could make the perl kernel a lot smaller than it is now, and
hopefully,
On Wed, 31 Jan 2001 12:04:46 +, Nicholas Clark [EMAIL PROTECTED] said:
dbmopen() already loads AnyDBM_File to do the real work without the
user (or script) knowing, so this idea could be extended.
And nobody in this thread has ever mentioned Time::HiRes. Is there a reason?
--
On Wed, 31 Jan 2001, Bart Lateur wrote:
On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote:
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.
On Wed, Jan 31, 2001 at 09:53:23AM -0200, Branden wrote:
Because with a better built-in that handles fractions of second (if that's
ever desired, and I guess it is), time() would be deprecated and could
be easily reproduced as int(now()) or anything like it.
Why can't we change the meaning of
James Mastros wrote:
Why can't we change the meaning of time() slightly without changing to a
different function name? Yes, it will silently break some existing code,
but that's OK -- remember, 90% with traslation, 75% without. being in
that
middle 15% isn't a bad thing.
I share your
On Wed, 31 Jan 2001, Casey R. Tweten wrote:
opinion
Not that there needs to be any discussion on this but IMHO things that
can reasonably live outside the core should. I heard somewhere that
most people think this way too.
This is why there hasn't been much discussion on it -- there's not
On Wed, 31 Jan 2001 08:53:13 -0600, Jarkko Hietaniemi wrote:
So nice of you to volunteer for being our help desk person man for
explaining to people why their time() just got broken :-)
I'd use the same function name for both the integer version of time(),
and the hires version. All you need is
James Mastros [EMAIL PROTECTED] writes:
Why can't we change the meaning of time() slightly without changing to a
different function name? Yes, it will silently break some existing code,
but that's OK -- remember, 90% with traslation, 75% without. being in that
middle 15% isn't a bad thing.
Branden wrote:
Actually, with event loops and threading issues, probably things like
the perl built-ins sleep and alarm won't ever be passed to the syscalls
sleep(3) and alarm(3).
Sleep isn't usually a syscall -- it's often a library routine that sets
an alarm and blocks or uses some other
Bart Lateur wrote:
What if we take the ordinary sleep() for the largest part of the
sleeping time (no busy wait), and the 4 argument select for the
remainder, i.e. subsecond?
You're trying to solve a problem that doesn't exist.
Sleep doesn't have the signal delivery problems that alarm has,
At 10:58 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote:
On Wed, Jan 31, 2001 at 09:53:23AM -0200, Branden wrote:
[EMAIL PROTECTED] wrote:
sub Time::Local::time {
return int(CORE::now());
}
Why the urge to move it out of the core? Should perl6 be like Python,
On Wed, Jan 31, 2001 at 05:23:43PM -0500, Dan Sugalski wrote:
Pulling out or mangling time strikes me as intensely pointless, and I don't
see it happening. The socket stuff is really the only core functionality
that makes any sense to pull out, and that only from an architectural
On Wed, Jan 31, 2001 at 05:35:03PM -0500, Michael G Schwern wrote:
On Wed, Jan 31, 2001 at 05:23:43PM -0500, Dan Sugalski wrote:
Pulling out or mangling time strikes me as intensely pointless, and I don't
see it happening. The socket stuff is really the only core functionality
that makes
Or, should we just implement usleep() and (for lack of a better name)
snooze() is a better name ;-)
nap() is even better (shorter that sleep() :-)
Damian
On Wed, Jan 31, 2001 at 12:58:01PM +0100, Bart Lateur wrote:
On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote:
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to
On Wed, Jan 31, 2001 at 10:18:19AM -0500, Andy Dougherty wrote:
On Wed, 31 Jan 2001, Casey R. Tweten wrote:
opinion
Not that there needs to be any discussion on this but IMHO things that
can reasonably live outside the core should. I heard somewhere that
most people think this way
On Wed, Jan 31, 2001 at 05:51:27PM -0500, John Porter wrote:
you *don't* need to remember
you are programming in perl5 or perl6, and get the same functionality.
But you need to remember it anyway, so remembering it for time() is
no added burden.
Uhm. NO! Remembering that $x+1 things have
someone wrote:
hardly anything to gain by removing it,
it will break a fair number of programs,
Programs will be broken anyway, even without changing time().
you *don't* need to remember
you are programming in perl5 or perl6, and get the same functionality.
But you need to remember it
On Wed, Jan 31, 2001 at 09:53:23AM -0200, Branden wrote:
[EMAIL PROTECTED] wrote:
sub Time::Local::time {
return int(CORE::now());
}
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can
At 10:37 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote:
On Wed, Jan 31, 2001 at 10:18:19AM -0500, Andy Dougherty wrote:
On Wed, 31 Jan 2001, Casey R. Tweten wrote:
opinion
Not that there needs to be any discussion on this but IMHO things that
can reasonably live outside the core
Stephen P . Potter [EMAIL PROTECTED] writes:
Lightning flashed, thunder crashed and Jarkko Hietaniemi [EMAIL PROTECTED] whispered
:
| I guess it's part of the can of sub-second worms: if we do sleep(),
| people will ask why don't we do time() and alarm(), too. sleep() and
| alarm() we could get
29 matches
Mail list logo
