[EMAIL PROTECTED] wrote:
John Porter wrote:
we would only implement changes that add something desirable.
How does removing time() add something desirable?
I'm not motivated to give an answer to that, because
I'm not arguing in favor of removing time().
--
John Porter
At 11:57 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote:
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
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
On Wed, Jan 31, 2001 at 04:43:38PM -0500, Dan Sugalski wrote:
The core's going to look big, but be small
What, like am inside-out TARDIS?
--
David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david/
Any technology distinguishable from magic is insufficiently advanced
** I
"N" == [EMAIL PROTECTED] writes:
N snooze() is a better name ;-)
TK::button-new( -name = 'snooze', -action = 'press' ) ;
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX
On Wed, Jan 31, 2001 at 11:57:43PM +0100, [EMAIL PROTECTED] wrote:
Perhaps some of the more grossly UNIX specific things like getpwnam's
extended family and the SysV IPC stuff?
But why? What is it going to buy you?
The fact is, they don't need to be there.
And there isn't really a good
Simon Cozens wrote:
John Porter wrote:
But you need to remember it anyway, so remembering it for time() is
no added burden.
Uhm. NO! Remembering that $x+1 things have changed is an "added burden"
over remembering that $x things have changed.
Not as x approaches infinity.
I'm responding
On Wed, Jan 31, 2001 at 04:44:00PM -0600, Jarkko Hietaniemi wrote:
Or explore various garbage collection alternatives.
No good, the mob wouldn't be happy.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
purl Hey Schwern! honk, honk, honk, honk, honk, honk, honk,
On Wed, 31 Jan 2001, Simon Cozens wrote:
God gave man two ears and one tongue so that we listen twice as much as
we speak.
-- Arab proverb
...but alas on the net we have 10 fingers to type but only 2 eyes to read.
--
Andy Dougherty [EMAIL PROTECTED]
On Thu, Feb 01, 2001 at 09:00:47AM -0500, John Porter wrote:
Uhm. NO! Remembering that $x+1 things have changed is an "added burden"
over remembering that $x things have changed.
Not as x approaches infinity.
We are not changing an infinite number of things.
Please knock it off with the
David Grove wrote:
RFC 0 continues to be bogus, despite its repetition.
Perl6 will be Perl, even though it won't be Perl5.
It will be a different language, yet it will still be Perl.
Correct. However, the lack of that argument doesn't mean that we should
arbitrarily slaughter the
John Porter [EMAIL PROTECTED] wrote:
Simon Cozens wrote:
John Porter wrote:
But you need to remember it anyway, so remembering it for time() is
no added burden.
Uhm. NO! Remembering that $x+1 things have changed is an "added
burden"
over remembering that $x things have
On Thu, Feb 01, 2001 at 09:32:30AM +, David Grove wrote:
John Porter [EMAIL PROTECTED] wrote:
Simon Cozens wrote:
"Perl should remain Perl" (once known as RFC 0) is bogus
If you want things that *aren't* Perl, you know exactly where to find
them.
RFC 0 continues to be
On Thu, Feb 01, 2001 at 03:38:46PM +, Simon Cozens wrote:
On Thu, Feb 01, 2001 at 09:00:47AM -0500, John Porter wrote:
Uhm. NO! Remembering that $x+1 things have changed is an "added burden"
over remembering that $x things have changed.
Not as x approaches infinity.
We are not
On Thu, Feb 01, 2001 at 11:45:16AM -0500, John Porter wrote:
For example, take a look at RFC 28 (whose title
happens to be "Perl should stay Perl"): nothing but ill-
informed, petulant, absurd whinging about certain classes
of proposed features that the author, in his humble little
opinion,
Lightning flashed, thunder crashed and [EMAIL PROTECTED] whispered:
| To make a simple loop, Perl offers you: for, foreach, while, until,
| {redo}, map, grep, //g, goto and recursion. Which 9 of them do you
| propose to drop from the language so Perl causes less confusion?
|
| There Is More Than
Dan Sugalski wrote:
At 11:57 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote:
On Wed, Jan 31, 2001 at 05:35:03PM -0500, Michael G Schwern wrote:
grossly UNIX specific things like getpwnam's [can be pulled]
But why? What is it going to buy you?
Not that much. More than anything else the
On Thu, Feb 01, 2001 at 11:45:16AM -0500, John Porter wrote:
I don't think anyone is suggesting that we make changes just
because we can. OBVIOUSLY we would only implement changes
that add something desirable. And the weight of known
desirables is large, or we wouldn't be making perl6.
[EMAIL PROTECTED] wrote:
It might makes sense to have some other functions giving units
since some point in the past next to time() though.
How about time($)
it could take an offset. Not
time(3)
being the same as
(time() + 3)
That would be silly; but what if
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.
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
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 {
select(undef, undef, undef, $time);
}
}
Why
On Tue, Jan 30, 2001 at 04:13:39AM -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);
}
At 09:43 AM 1/30/2001 -0600, Jarkko Hietaniemi wrote:
On Tue, Jan 30, 2001 at 04:13:39AM -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(
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 granularity would be A Bad Thing for backward
On Tue, Jan 30, 2001 at 10:49:56AM -0500, Dan Sugalski wrote:
At 09:43 AM 1/30/2001 -0600, Jarkko Hietaniemi wrote:
On Tue, Jan 30, 2001 at 04:13:39AM -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:
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something crashing and burning because some other place expects
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something crashing and burning because some other place expects
to find a
On Tue, 30 Jan 2001, Nathan Wiger wrote:
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something
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 away with more easily, but changing time() to
On Tue, Jan 30, 2001 at 05:49:43PM -0200, Branden wrote:
Well, then I propose the same of RFC 48: deprecate time() and create another
name to refer to the number of seconds since (an epoch) with decimals for
fractions of seconds. Maybe it could be called now() or timestamp(). Then
time
"Stephen P. Potter" wrote:
Why do we have to worry about changing time()? There's a real parallel
between sleep() and alarm(), so we would want to do both if we did either,
but time() really has no relation to them.
Or, should we just implement usleep() and (for lack of a better name)
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
But the big problem is that there's a lot of stuff that's based off of
time() right now, like stat(), lstat(), etc, etc. When you think of the
cascading effects of changing Perl's timekeeping it gets really, really
sticky.
I
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
If the internal timekeeping were changed, one thing that's apparent from
the discussions is that there would *have* to be a core way of providing
exactly what time() does currently or lots of stuff would break really
badly. Someone
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper
ed:
| But the big problem is that there's a lot of stuff that's based off of
| time() right now, like stat(), lstat(), etc, etc. When you think of the
| cascading effects of changing Perl's timekeeping it gets really,
60 matches
Mail list logo
