[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
[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 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
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
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. T
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
> opin
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 contin
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
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.
>
>
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 slaugh
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
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 wi
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/
Hey Schwern! honk, honk, honk, honk, honk, honk, honk, ho
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]
D
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 res
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 go
> "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, UNI
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 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 r
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
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
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
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: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 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
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
> >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 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
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
> 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, 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
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
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 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: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, 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, 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
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
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
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
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,
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. Some
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
"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 nam
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
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() t
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
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 fin
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 exp
On Tue, Jan 30, 2001 at 02:09:32PM -0200, Branden wrote:
> 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()
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 th
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 c
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;
> >
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);
> }
>
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 can
66 matches
Mail list logo
