Re: Why shouldn't sleep(0.5) DWIM?
[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
Re: Why shouldn't sleep(0.5) DWIM?
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 stuff is really the only core functionality that makes any sense to pull out, and that only from an architectural standpoint. 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? Not that much. More than anything else the ability to deal with them externally for non-unix platforms. Dunno if it's worth it as anything other than a first-cut proof of concept thing. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Why shouldn't sleep(0.5) DWIM?
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 any sense to pull out, and that only from an architectural standpoint. Perhaps some of the more grossly UNIX specific things like getpwnam's extended family and the SysV IPC stuff? I still say that this is wasted effort. Yes, those are grossly UNIX specfic. But removing them doesn't buy you much. Rather design, say, how to gracefully switch between native integers and bigints. Or a fast and stackable tie() subsystem. Or explore various garbage collection alternatives. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Why shouldn't sleep(0.5) DWIM?
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 read encrypted mail first, so encrypt if your message is important ** PGP signature
Re: Why shouldn't sleep(0.5) DWIM?
"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 Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Why shouldn't sleep(0.5) DWIM?
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 reason for having them there. So, since we're starting from scratch, we're not getting rid of them. We're merely not putting them in. -- God gave man two ears and one tongue so that we listen twice as much as we speak. -- Arab proverb
Re: Why shouldn't sleep(0.5) DWIM?
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 to the argument that, when perl6 has hit the streets, a perl programmer should not have to remember whether she's programming in perl6 or perl5. Since that is an impossibility, using it as an argument to support not changing feature Y doesn't work. "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 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. Please knock it off with the "Keep Perl Perl" non-argument. -- John Porter So take a pointed stick and touch Piggy's eyes He's gonna turn and leave you a big surprise
Re: Why shouldn't sleep(0.5) DWIM?
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, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: Why shouldn't sleep(0.5) DWIM?
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] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
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 "Keep Perl Perl" non-argument. No. -- [It is] best to confuse only one issue at a time. -- KR
Re: Why shouldn't sleep(0.5) DWIM?
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 language. . . . Perl 5 and Perl 6 will be different because we can't, not because we don't wanna. Otherwise, we no longer have perl, but lrep. 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. I'm just really sick of people trying to put down changes they oppose by claiming that the resulting language wouldn't be Perl. 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, thinks would cause Perl to no longer be Perl. Stuff generally believed to be useful and desirable, like improved support for the Functional and OO programming paradigms. Change proposals should be raised up and shot down based on their merits alone, with the goal held clearly in mind, of making Perl a better language. It is the philosophy of Perl which must perpetuated; preserving compatibility where possible is an adjunct benefit. Of course, we've been around this before; too bad we have to revisit it from time to time. -- John Porter A pessimist says the CPU is 50% utilized. An optimist says the CPU is 50% unutilized. A realist says the network is the bottleneck.
Re: Why shouldn't sleep(0.5) DWIM?
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 changed. Not as x approaches infinity. I'm responding to the argument that, when perl6 has hit the streets, a perl programmer should not have to remember whether she's programming in perl6 or perl5. Since that is an impossibility, using it as an argument to support not changing feature Y doesn't work. "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 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 language. Keeping the time() function the time() function _if_possible_ while perhaps adding a millitime() function from a library or perl kernel whatsis or however it's added. Our hope is to minimize the incompatibilities, not create them because we decide that a function should suddenly do something totally other than it currently does just because. Please knock it off with the "Keep Perl Perl" non-argument. Non sequitur. Perl 5 and Perl 6 will be different because we can't, not because we don't wanna. Otherwise, we no longer have perl, but lrep. Making changes that slaughter existing code just because we can is a decidedly Microsoftish thing to do, and that makes me feel all ooogie. (Anybody know what database engine we're supposed to use right now?) p
Re: Why shouldn't sleep(0.5) DWIM?
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 bogus, despite its repetition. Perl6 will be Perl, even though it won't be Perl5. Correct. However, the lack of that argument doesn't mean that we should arbitrarily slaughter the language. Keeping the time() function the time() function _if_possible_ while perhaps adding a millitime() function from a library or perl kernel whatsis or however it's added. I think you're both missing the point of "keep perl perl" argument: the idea is not that all perl code should transition with no changes, or even that some common idioms won't stop working. The idea is that we should not kill the fundemental soul of the language. For example, modern BASICs (like VB) have a different soul then old-school ROM BASIC. Now, in the case of basic, I think (for the most part), it's a better soul, but I like perl's soul the way it is. That doesn't mean I wouldn't like it better with a new haircut. Hell, I wish I could change my skin and hair and keep my soul. Languages are a lot more maliable then people. Changing time such that it gives its result slightly differently is not "not keeping perl perl", nor is it not keeping time time; changing time() such that it did somthing radicly different (like returning time-of-day instead) would be changing it's soul. And I don't think we should be keeping code-level compatablity just for the sake of same any more then we should be destroying it just because we can. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Why shouldn't sleep(0.5) DWIM?
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 changing an infinite number of things. Please knock it off with the "Keep Perl Perl" non-argument. No. perl -we '($b, $n) = @ARGV; printf "Proportion of stuff still working %d%%\n%d module%s\nchance of it all working %2g%%\n", $b, $n, ($n == 1 ? "" : "s"), ($b/100) ** $n * 100' 95 4 Proportion of stuff still working 95% 4 modules chance of it all working 81.4506% perl -we '($b, $n) = @ARGV; printf "Proportion of stuff still working %d%%\n%d module%s\nchance of it all working %2g%%\n", $b, $n, ($n == 1 ? "" : "s"), ($b/100) ** $n * 100' 90 4 Proportion of stuff still working 90% 4 modules chance of it all working 65.61% [OK, not strictly fair, as 4 modules are not independent variables - they may all happen to fall over on the same thing] Changes have compound effects. Nicholas Clark
Re: Why shouldn't sleep(0.5) DWIM?
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, thinks would cause Perl to no longer be Perl. I take great exception to the implication that my opinions are humble! John, if you're going to out and out insult someone, do it decently. Or elsewhere. Preferably elsewhere. -- The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. -Kernighan, 1978
Re: Why shouldn't sleep(0.5) DWIM?
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 One Way To Do It is an official Perl slogan, and
| now you are claiming this a *bad* thing? Oh my.
There's a quote "contest" going on over in -internals, so I just can't help
myself:
Although the Perl Slogan is There's More Than One Way to Do It, I hesitate
to make 10 ways to do something. :-)
-- Larry Wall in [EMAIL PROTECTED]
Not that I think time() should be moved out of the core. There are much
bigger "dead" fish to fry.
-spp
Re: Why shouldn't sleep(0.5) DWIM?
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 ability to deal with them externally for non-unix platforms. So on Unix-like platforms getpwnam is pre-loaded and on all the others it's auto-loaded (a Unix compatiblity module or something). If it's faster pre-loading a module than telling the auto-loader about it, we should pre-load. Speed always wins over size in perl. I might be off base, but there seems to be a movement to take Unix out of Perl. Sometimes I'm not sure if we're arguing about "time() returns an int" or "time() looks like Unix so it has to change." IMHO I'd like to see more Unix in Perl, not less. (We can do better than the C API though.) - Ken
Re: Why shouldn't sleep(0.5) DWIM?
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. How does removing time() add something desirable? Abigail
Re: Why shouldn't sleep(0.5) DWIM?
[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 time(315532800) #perl-defined to mean secs since 1970 GMT reset the internal offset to whatever you wanted? -- David Nicol 816.235.1187 [EMAIL PROTECTED] "gorkulator borked. Please investigate."
Re: Why shouldn't sleep(0.5) DWIM?
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 granularity would be A Bad Thing for backward compatibility.
Sorry, I forgot to mention the translations. Yes, it becomes:
sleep(EXPR) - sleep(int(EXPR))
alarm(EXPR) - alarm(int(EXPR))
time- int(time)
and that should handle it. The nice part is it doesn't really require
any code translations, you can get away with overriding the core
functions instead:
sub sleep { CORE::sleep(int($_[0])); }
sub alarm { CORE::alarm(int($_[0])); }
sub time { int CORE::time }
something like that. hand-wave
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
That which stirs me, stirs everything.
-- Squonk Opera, "Spoon"
Re: Why shouldn't sleep(0.5) DWIM?
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 those? Or doesn't it? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Any sufficiently encapsulated hack is no longer a hack.
Re: Why shouldn't sleep(0.5) DWIM?
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 {
select(undef, undef, undef, $time);
}
}
Why can't Perl?
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 example only 2.5
seconds.
Well, that's how it *used* to be. Maybe perl's behaviour has been
changed since then.
If you expect sleep(2.5) to work properly, then sleep(3) should be
fixed, too.
--
Bart.
Re: Why shouldn't sleep(0.5) DWIM?
[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.
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. It could be in
a module so that anyone that still wants to use it can find it there. This
was suggested in RFC 48, that proposes deprecation of localtime and gmtime,
in favor of the new date and utcdate, and put the old ones in Time::Local.
change:
: if (my $fh = open("/tmp/$$".time())) {
for:
: if (my $fh = open("/tmp/$$".int(now( {
change:
: print LOG time() . ": gorkulator borked. Please investigate.";
for:
: print LOG int(now()) . ": gorkulator borked. Please
investigate.";
Write them as:
printf LOG "%d: %s\n" = time (), "gorkulator borked. Please
investigate.";
or:
printf LOG "%s: %s\n" = scalar (localtime ()),
"gorkulator borked. Please
investigate.";
or:
use POSIX;
printf LOG "%s: %s\n" = strftime ("%Y-%m-%d %H:%M:%S", localtime ()),
"gorkulator borked. Please
investigate.";
and gain two things:
1) You get "much better!" without waiting for perl6 to roll along,
2) It doesn't matter whether time() returns an integer or a float.
The point was, if you're writing new code, you only have to remember that
when you
used to have time() in perl5, you should have int(now()) in perl6. That's
simple
and doesn't hurt, IMO. If you like time() and think you can't live without
it, and
think `use Time::Local "time"' is too long to type, then you should better
stick
with perl5!
Moving time() out of the core doesn't break compatibility? Changing the
return value of sleep() doesn't change compatibility? What *does* change
it then?
Hello... I guess the whole perl6 thing was about breaking compatibility,
wasn't it? At least, I take for sure we'll have a p52p6 translator to
translate old code. And for one such translator, importing things from
Time::Local or even replacing every occurrence of `time()' for `int(now())'
or whatever is chosen to replace it, isn't complex at all.
Let's not forget that Perl is a glue language. It heavily interacts
with its environment, other programs and is eager to network with
the outside world. Seconds since 1970 might be as arbitrary as any
other measurement, but that's irrelevant. What's relevant is 30 years
of code that produces and expects timestamps in seconds since 1970.
Deprecating time() in favour of some other arbitrary measurement is
absurd. It might makes sense to have some other functions giving units
since some point in the past next to time() though.
More than one function to do the same thing is A Bad Thing, IMO. It only
causes confusion.
If a change of mind when writing new software is too much a burden, then,
I say it again, we should stick with perl5! As Jarkko always quotes:
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
If old code and old-code thinking are the only thing that prevents us to
change time() or move it out of CORE, then I believe we should do it yes!
- Branden
Re: Why shouldn't sleep(0.5) DWIM?
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 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, make it load faster. -- Bart.
Re: Why shouldn't sleep(0.5) DWIM?
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 quick one-liners then. 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, make it load faster. I agree dbmopen() already loads AnyDBM_File to do the real work without the user (or script) knowing, so this idea could be extended. Nicholas Clark
Re: Why shouldn't sleep(0.5) DWIM?
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 example only 2.5 seconds. Well, that's how it *used* to be. Maybe perl's behaviour has been changed since then. If you expect sleep(2.5) to work properly, then sleep(3) should be fixed, too. 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). Perl will probably block that instance of the interpreter internally and do some other stuff. It will probably use its internal clock to measure the time to unblock it, and that clock will probably have sub-second precision. - Branden
Re: Why shouldn't sleep(0.5) DWIM?
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, and hopefully, make it load faster. I agree dbmopen() already loads AnyDBM_File to do the real work without the user (or script) knowing, so this idea could be extended. Nicholas Clark I think a generic method of doing this, like AUTOLOAD is for modules, would be a good thing. Whenever an inexistent sub is called and it cannot be found in existing packages and by package's AUTOLOAD's, this special sub is called and it can auto-load packages that provide such functionality. Then there would be a generic way to do such things. - Branden
Re: Why shouldn't sleep(0.5) DWIM?
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, make it load faster. I agree dbmopen() already loads AnyDBM_File to do the real work without the user (or script) knowing, so this idea could be extended. What an excellent idea. http://dev.perl.org/rfc/315.html -- Testing can show the presense of bugs, but not their absence. -- Dijkstra
Re: Why shouldn't sleep(0.5) DWIM?
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? -- andreas
Re: Why shouldn't sleep(0.5) DWIM?
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.
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, make it load faster.
This is a persistent myth. Moving such functions out of the core may
indeed make the perl kernel cleaner, but I seriously doubt it will make
it "a lot smaller" or have any significant impact on load time. You
can try it and see with perl5, or search the perl5-porters archives for
my previous reports on the subject.
For example, removing time() from the perl5 core means excising the
following from pp_sys.c:
PP(pp_time)
{
djSP; dTARGET;
XPUSHi( time(Null(Time_t*)) );
RETURN;
}
and replacing it by the appropriate auto-loading glue. This is not a big
space savings.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
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 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. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Why shouldn't sleep(0.5) DWIM?
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 thought. But I proposed a new name for people that think that ``this would confuse UNIX users, that relate Perl's time with UNIX C's time''. Having the same name and modifying the semantics is more appropriate, IMO. - Branden
Re: Why shouldn't sleep(0.5) DWIM?
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 really much to discuss. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
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 an optional parameter, whicch, if true, makes time() return a float. $a = time();#same as now $b = time(undef) # idem $c = time(1)# hires -- Bart.
Re: Why shouldn't sleep(0.5) DWIM?
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. I think we can easily use up larry's 75%/90% 'allowance' just breaking stuff where we really have to, without breaking things for the sake of it too. Give time() an optional arg, or rename it, or anything really, but please make plain time() behave the same as before. IMHO. # s/H//; Dave.
Re: Why shouldn't sleep(0.5) DWIM?
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,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.
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. It could be in
a module so that anyone that still wants to use it can find it there. This
was suggested in RFC 48, that proposes deprecation of localtime and gmtime,
in favor of the new date and utcdate, and put the old ones in Time::Local.
time() is a very simple call, only a few lines of code in the Perl
source, without much overhead. It's also used quite a lot. There's
hardly anything to gain by removing it, it will break a fair number
of programs, and the alternative requires you to pull in a module.
That doesn't seem a fair trade-off to me.
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
standpoint.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Why shouldn't sleep(0.5) DWIM?
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 standpoint. Perhaps some of the more grossly UNIX specific things like getpwnam's extended family and the SysV IPC stuff? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ MERV GRIFFIN!
Re: Why shouldn't sleep(0.5) DWIM?
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 any sense to pull out, and that only from an architectural standpoint. 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? Abigail
Re: Why shouldn't sleep(0.5) DWIM?
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
Re: Why shouldn't sleep(0.5) DWIM?
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 quick one-liners then. 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, make it load faster. I wouldn't say it's moving it out of the core on a language list. That's just source code housekeeping. Abigail
Re: Why shouldn't sleep(0.5) DWIM?
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 too. This is why there hasn't been much discussion on it -- there's not really much to discuss. Odd. I'd expect a lot of (pointless) discussion about it. "It's reasonable for `foo' to live outside of the core!" "No, it isn't!" "Yes, it is; I never use it!" "It should be in the core, I often use it!" Abigail
Re: Why shouldn't sleep(0.5) DWIM?
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 changed is an "added burden" over remembering that $x things have changed. "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. -- I see ADA as a larger threat than communism at this point in time -- Ted Holden
Re: Why shouldn't sleep(0.5) DWIM?
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 anyway, so remembering it for time() is no added burden. If I would think typing 'use Time::Local "time"' isn't too much to ask to get basic functionality, I'd be using Python. I don't believe that's the only thing standing between you and python. It's certainly not the only thing standing between me and python. Things just being there is a feature of Perl. Yes, but things getting sucked in automatically and transparently is also a feature of perl, or could be. Perl6 doesn't have to be 100% compatible with perl5, but that's not an invitation to break everything that can be broken. Not changing things (for the better) in the name of not "breaking" things is a non-starting argument. "Perl should remain Perl" (once known as RFC 0) is bogus, because it's entirely too subjective. Should we have said, "Perl should remain Awk"? Or do we make a better thing? -- John Porter So take a pointed stick and touch Piggy's eyes He's gonna turn and leave you a big surprise
Re: Why shouldn't sleep(0.5) DWIM?
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 do anything
useful? Say goodbye to quick one-liners then.
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. It could be in
a module so that anyone that still wants to use it can find it there. This
was suggested in RFC 48, that proposes deprecation of localtime and gmtime,
in favor of the new date and utcdate, and put the old ones in Time::Local.
time() is a very simple call, only a few lines of code in the Perl
source, without much overhead. It's also used quite a lot. There's
hardly anything to gain by removing it, it will break a fair number
of programs, and the alternative requires you to pull in a module.
That doesn't seem a fair trade-off to me.
The point was, if you're writing new code, you only have to remember that
when you
used to have time() in perl5, you should have int(now()) in perl6. That's
simple
and doesn't hurt, IMO. If you like time() and think you can't live without
it, and
think `use Time::Local "time"' is too long to type, then you should better
stick
with perl5!
The point of me was that with the given code, you *don't* need to remember
you are programming in perl5 or perl6, and get the same functionality.
If I would think typing 'use Time::Local "time"' isn't too much to ask to
get basic functionality, I'd be using Python. Things just being there is
a feature of Perl. The "lean-and-clean" market is well covered by other
languages.
Moving time() out of the core doesn't break compatibility? Changing the
return value of sleep() doesn't change compatibility? What *does* change
it then?
Hello... I guess the whole perl6 thing was about breaking compatibility,
wasn't it? At least, I take for sure we'll have a p52p6 translator to
translate old code. And for one such translator, importing things from
Time::Local or even replacing every occurrence of `time()' for `int(now())'
or whatever is chosen to replace it, isn't complex at all.
It's not complex, but it probably has a lot more overhead than it gains
from not being there. Perl6 doesn't have to be 100% compatible with perl5,
but that's not an invitation to break everything that can be broken.
Let's not forget that Perl is a glue language. It heavily interacts
with its environment, other programs and is eager to network with
the outside world. Seconds since 1970 might be as arbitrary as any
other measurement, but that's irrelevant. What's relevant is 30 years
of code that produces and expects timestamps in seconds since 1970.
Deprecating time() in favour of some other arbitrary measurement is
absurd. It might makes sense to have some other functions giving units
since some point in the past next to time() though.
More than one function to do the same thing is A Bad Thing, IMO. It only
causes confusion.
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 One Way To Do It is an official Perl slogan, and
now you are claiming this a *bad* thing? Oh my.
If a change of mind when writing new software is too much a burden, then,
I say it again, we should stick with perl5! As Jarkko always quotes:
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
If old code and old-code thinking are the only thing that prevents us to
change time() or move it out of CORE, then I believe we should do it yes!
*blink*
Are you claiming the use of time() is dead? Or that stability is a bad
thing?
Abigail
Re: Why shouldn't sleep(0.5) DWIM?
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 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 really much to discuss. Odd. I'd expect a lot of (pointless) discussion about it. "It's reasonable for `foo' to live outside of the core!" "No, it isn't!" "Yes, it is; I never use it!" "It should be in the core, I often use it!" We've already done that one... :) The core's going to look big, but be small, and I think if you want you can find a lot of the pointless discussion on the internals list archive somewhere. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Why shouldn't sleep(0.5) DWIM?
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 away with more easily, but changing time() to do | subsecond granularity would be A Bad Thing for backward compatibility. 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) snooze() is a better name ;-) -- Nick Ing-Simmons
Why shouldn't sleep(0.5) DWIM?
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't Perl? Smells like a C holdover to me.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
If you have to shoot, shoot! Don't talk.
-- Tuco, "The Good, The Bad And The Ugly"
Re: Why shouldn't sleep(0.5) DWIM?
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);
}
else {
select(undef, undef, undef, $time);
}
}
Why can't Perl? Smells like a C holdover to me.
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 compatibility.
Think of generated filenames, or various logs with timestamps. We can
(hopefully) do a magical p52p6 translator, but fixing the existing
data is a tad harder.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Why shouldn't sleep(0.5) DWIM?
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( /^[+-]?\d+$/ ) {
sleep($time);
}
else {
select(undef, undef, undef, $time);
}
}
Why can't Perl? Smells like a C holdover to me.
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 compatibility.
Think of generated filenames, or various logs with timestamps. We can
(hopefully) do a magical p52p6 translator, but fixing the existing
data is a tad harder.
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.
I'm up for raising the bar for base OS/C compiler features that this sort
of thing is available.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Why shouldn't sleep(0.5) DWIM?
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 compatibility. Think of generated filenames, or various logs with timestamps. We can (hopefully) do a magical p52p6 translator, but fixing the existing data is a tad harder. I see no trouble in time returning a float value. p52p6 could translate time() to int(time()) and everything should work ok. Anyway, time is probably gonna change in perl6, since it's UNIX-based now and i think we no longer have to know how many seconds have passed since mid-night january 1st 1970, do we? Also, we could translate the stringified result of the float value of time to be the string of only the integers, what would probably solve the log timestamps problem, but as it would also be solved with int(time()), I won't consider it here, since it can lead to not DWIM, IMO. For reference, see RFC 99 on standardizing time to (oops!) UNIX-time (even so, my point continues, int(time()) solves p52p6 problem!), RFC 73, on making all built-ins return objects, which would do the stringifying thing or even allow with and without fractions in one object, and RFC 48, on changing localtime() and gmtime(), 'cause maybe time() will go with them too! - Branden
Re: Why shouldn't sleep(0.5) DWIM?
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:
sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
sleep($time);
}
else {
select(undef, undef, undef, $time);
}
}
[return value not perfect for sleep when you call select]
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.
You don't need to do it, do you?
man 3 sleep
RETURN VALUE
Zero if the requested time has elapsed, or the number of
seconds left to sleep.
man perlfunc
sleep EXPR
sleep Causes the script to sleep for EXPR seconds, or
forever if no EXPR. May be interrupted if the
process receives a signal such as "SIGALRM".
Returns the number of seconds actually slept. You
probably cannot mix "alarm" and "sleep" calls,
because "sleep" is often implemented using
"alarm".
So on a system that can't do a subsecond sleep, you do the integer sleep
and return (aargh, C and perl differ) how long you slept for.
How does the program discover if sleep can do subseconds?
use Config; ?
Nicholas Clark
UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)
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 filename of the form /^\d+\d+$/, or someone printing into log files
like this
print LOG time() . ": gorkulator borked. Please investigate."
and someone splitting on /\./, etc.
Good point, this is a problem with changing time() from UNIX epoch (or
anything else which provides sub-second granularity or otherwise
introduces a ".").
probably gonna change in perl6, since it's UNIX-based now and i think
we no longer have to know how many seconds have passed since mid-night
january 1st 1970, do we?
Some sort of less C/UNIX-centric way would be nice, yes.
We had a whole ton of discussions on this regarding "what epoch is the
right one", and the general consensus was that we should keep time()
as-is. The basic argument went like this:
1. All epochs are arbitrary
2. The UNIX epoch is well-known and understood
3. Therefore let's not mess with it
In fact RFC 99 proposed the reverse - that all platforms should use the
UNIX epoch. There was about a 50/50 split, some said "Why mess with
MacOS?" and others said "This would help Perl cross-platform." See RFC
99 at http://dev.perl.org/rfc/99.pod
The full discussions, which included ponderings of Modified Julian, the
ISO format, etc, can be found starting at the following places:
Original proposal to use MJD and introduce mjdate(), which
resulted in much heated slashing and burning:
http://www.mail-archive.com/perl6-language@perl.org/msg02171.html
Reintroduction as standardizing on UNIX epoch:
http://www.mail-archive.com/perl6-language@perl.org/msg02308.html
General slashing and burning of the UNIX epoch idea:
http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00029.html
Since there were many replies your best bet is to read the "Follow-ups"
at the bottom rather than hitting the "Next Thread" button.
-Nate
Re: Why shouldn't sleep(0.5) DWIM?
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 filename of the form /^\d+\d+$/, or someone printing into log
files
like this
print LOG time() . ": gorkulator borked. Please investigate."
and someone splitting on /\./, etc.
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 needn't be on CORE, and can be put together with localtime() and
gmtime() on Time::Local or anything like it. It could be implemented as:
sub Time::Local::time {
return int(CORE::now());
}
Since there will probably a change of mind from programming perl5 to
programming perl6 (as it will be probably more object-oriented, less
unix-centric, etc.), I see no problem in telling perl programmers to
change their implementations:
change:
: if (my $fh = open("/tmp/$$".time())) {
for:
: if (my $fh = open("/tmp/$$".int(now( {
or:
: my $fh = open(" /tmp/.$progname-$$-" . date(now(), '%Y%m%d%H%M%S'));
: # creates the file /tmp/.myperlscript-56473-20010130173742
: # just by looking at it, I can tell it was generated by "myperlscript"
: # running by process whose pid is 56473, and was generated
: # at 17:37:42, on january 30th, 2001.
: # much easier to figure it out than than seconds from 1970...
change:
: print LOG time() . ": gorkulator borked. Please investigate.";
for:
: print LOG int(now()) . ": gorkulator borked. Please investigate.";
or:
: print LOG date(now(), '%Y-%m-%d %H:%M:%S')# much better!
: . ": gorkulator borked. Please investigate.";
: # in a logfile, the clarity argument is even more valuable...
Well, at least that's what I think about time. This change wouldn't break
compatibility, and changing the way we think about this function is a
healthy thing for our programmer minds. Just because UNIX decided that
its sleep function would return an int value, doesn't mean we have
to follow it on our design!
- Branden
P.S.: Nathan, on re-reading RFC 48 I spotted out that comparison of dates
isn't mentioned. Of course there's a section on ``Date arithmetic'', that
talks about -, I think mentioning and is worth it.
Re: UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)
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 crashing and burning because some other place expects
to find a filename of the form /^\d+\d+$/, or someone printing into log files
like this
Well, FWIW, here are two suggestions on how to handle this, the
grouchy way and the helpful way:
1) (grouchy) If you're writing Perl6, you should be writing Perl6,
and you should know how time() behaves and handle it properly.
2) (helpful) time() returns an int-based time value (as now), but
time(something) returns a subsecond-value...if we wanted to get really
fancy, then the value of something as an int could be the number of
places of accuracy that would be returned.
Dave
Re: Why shouldn't sleep(0.5) DWIM?
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 do | subsecond granularity would be A Bad Thing for backward compatibility. 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) ualarm()? -spp
Re: Why shouldn't sleep(0.5) DWIM?
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 needn't be on CORE, and can be put together with localtime() and
gmtime() on Time::Local or anything like it. It could be implemented as:
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.
Since there will probably a change of mind from programming perl5 to
programming perl6 (as it will be probably more object-oriented, less
unix-centric, etc.), I see no problem in telling perl programmers to
change their implementations:
change:
: if (my $fh = open("/tmp/$$".time())) {
for:
: if (my $fh = open("/tmp/$$".int(now( {
or:
: my $fh = open(" /tmp/.$progname-$$-" . date(now(), '%Y%m%d%H%M%S'));
: # creates the file /tmp/.myperlscript-56473-20010130173742
: # just by looking at it, I can tell it was generated by "myperlscript"
: # running by process whose pid is 56473, and was generated
: # at 17:37:42, on january 30th, 2001.
: # much easier to figure it out than than seconds from 1970...
If time() is there to stay, why bother changing the code? If you insist
on getting file names with year/month/date in them, you can do so now
using localtime(), and if you don't mind to have files with seconds-
since-epoch in the name, why would you mind when perl6 rolls along?
change:
: print LOG time() . ": gorkulator borked. Please investigate.";
for:
: print LOG int(now()) . ": gorkulator borked. Please investigate.";
or:
: print LOG date(now(), '%Y-%m-%d %H:%M:%S')# much better!
: . ": gorkulator borked. Please investigate.";
: # in a logfile, the clarity argument is even more valuable...
Write them as:
printf LOG "%d: %s\n" = time (), "gorkulator borked. Please investigate.";
or:
printf LOG "%s: %s\n" = scalar (localtime ()),
"gorkulator borked. Please investigate.";
or:
use POSIX;
printf LOG "%s: %s\n" = strftime ("%Y-%m-%d %H:%M:%S", localtime ()),
"gorkulator borked. Please investigate.";
and gain two things:
1) You get "much better!" without waiting for perl6 to roll along,
2) It doesn't matter whether time() returns an integer or a float.
Well, at least that's what I think about time. This change wouldn't break
compatibility, and changing the way we think about this function is a
healthy thing for our programmer minds. Just because UNIX decided that
its sleep function would return an int value, doesn't mean we have
to follow it on our design!
Moving time() out of the core doesn't break compatibility? Changing the
return value of sleep() doesn't change compatibility? What *does* change
it then?
Let's not forget that Perl is a glue language. It heavily interacts
with its environment, other programs and is eager to network with
the outside world. Seconds since 1970 might be as arbitrary as any
other measurement, but that's irrelevant. What's relevant is 30 years
of code that produces and expects timestamps in seconds since 1970.
Deprecating time() in favour of some other arbitrary measurement is
absurd. It might makes sense to have some other functions giving units
since some point in the past next to time() though.
Abigail
Re: Why shouldn't sleep(0.5) DWIM?
"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) ualarm()? One thing that was discussed on the archives that I sent out was introducing a parallel mjdate() (or isodate() or whatever) which gave access to the internal means of maintaining time in Perl. Then Perl's internal clock could be sub-second ticks since 4152 BC, Modified Julian, etc, etc. So time() could remain unchanged (from a language/user perspective, at least), but sleep() and alarm() could use the internal sub-second methods of timekeeping to DWIM. The user gets sleep(0.5) and time() is still epoch seconds. 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. 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 can certainly chime in if they see an easy way around this, but as I recall there was little disagreement on this point. -Nate
Re: Why shouldn't sleep(0.5) DWIM?
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 don't see this problem, unless you plan to write a filesystem in Perl. Surely Perl asks the OS for l?stat() instead of keeping track of it itself? Abigail
Re: Why shouldn't sleep(0.5) DWIM?
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 can certainly chime in if they see an easy way around
this, but as I recall there was little disagreement on this point.
I really and truly don't see why we can't have things dealing with a number
of seconds do the Right Thing with fractional seconds, including returning
them.
It isn't an issue that we don't have the resolution available; the functions
were, and will continue to be, best-effort. There isn't a real problem with
formatting; if you're programming in p6, you should be saying int(time) if
you don't want a period. Remember, 75% of p5 code works straight, 90% can
be translated. time - int(time) is easy to translate. And having it in
the 25% that needs to change isn't that bad. You shouldn't be using time()
to generate unique filenames becuase the time isn't unique. Splitting on a
period is probably valid in many cirucumstances, but you can deal.
You can't make an omlet without breaking a few eggs, and this is a little
one to break.
(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-available.)
If you really want time() to do what it did before, you can always say:
sub time {int (CORE::time()) + epoch difference};
Indeed, a perl5::time module that does exactly that might be a Good Thing.
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Why shouldn't sleep(0.5) DWIM?
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, really | sticky. Most of those don't deal with subsecond time anyway, from the perspective that (l?stat) uses what is recorded in the filesystem inode. | 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 can certainly chime in if they see an easy way around | this, but as I recall there was little disagreement on this point. Changing sleep/alarm doesn't have to involve changing perl's internal timekeeping. sleep/alarm are just wrappers around the C library sleep/alarm. It should be trivial to make the wrapper recognize when a float is passed as the argument and switch to usleep (or setitimer or whatever) when that is found. -spp
