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 co
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:
> >
> > >
> > > Not that there needs to be any discussion on this but IMHO things that
> > > can reasonably live outside the core
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
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
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 thing
On Wed, Jan 31, 2001 at 10:18:19AM -0500, Andy Dougherty wrote:
> On Wed, 31 Jan 2001, Casey R. Tweten wrote:
>
> >
> > 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 t
> >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 goodby
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
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
> standp
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
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
On Wed, 31 Jan 2001 11:36:32 -0500, Ken Fox wrote:
> You want perl to block a thread and then busy wait until
>it's time for the thread to wake up?
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. sub
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
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 th
On Wed, Jan 31, 2001 at 04:25:46PM +0100, Bart Lateur wrote:
> 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
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 i
On Wed, 31 Jan 2001, Casey R. Tweten wrote:
>
> 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 rea
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 th
Today around 3:45pm, Andreas J. Koenig hammered out this masterpiece:
: > 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 extende
On Wed, Jan 31, 2001 at 09:47:59AM -0500, James Mastros wrote:
> 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 reproduc
On Wed, Jan 31, 2001 at 09:49:59AM -0500, Andy Dougherty wrote:
> 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
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 o
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-liner
> 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
James Mastros wrote:
> (And please, don't get into epoch discussions here. The units, accuracy,
> resolution, and zeropoint of a measurement are all different questions. I
> personaly would prefer to see units of seconds, a basepoint of 1/1/1970, and
> resolution and accuracy best-reasonably-ava
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
> > hopeful
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
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 exa
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 goodby
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
[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 th
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 {
>
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, 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 granu
35 matches
Mail list logo
