Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
>>..., but I darn well better *know* that I can't sleep(.25), or
>>strange things are gonna happen.
> But you can fake sleep() with select() or whatever.
$ cat sl.pasm
sleep 0.1
end
$ time parrot sl.pasm
Larry Wall <[EMAIL PROTECTED]> writes:
>
>That would seem like good future proofing. Someday every computer will
>have decentish subsecond timing. I hope to see it in my lifetime...
It isn't having the sub-second time in the computer it is the API
to get at it...
>
>My guess is that eventuall
Dan Sugalski <[EMAIL PROTECTED]> writes:
>In an attempt to drain the swamp...
>
>So far as I can see, we need, in descending order of importance (and
>speed) (And if there's stuff missing, add them):
>
>1) A timestamp value
>2) A way to chop the timestamp to pieces
>3) A way to turn the timestamp
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote:
: That means we can't convert to TAI, since that needs leap second info
: we don't have, so base time can't be TAI.
That part is only half true. Or maybe less than half, if UTC decides
to cut loose from astronomical time and ends up t
In an attempt to drain the swamp...
So far as I can see, we need, in descending order of importance (and
speed) (And if there's stuff missing, add them):
1) A timestamp value
2) A way to chop the timestamp to pieces
3) A way to turn the timestamp into a string
4) A way to turn pieces to a timest
On Tue, 9 Mar 2004, Edward S. Peschko wrote:
> > >> This sort of creeping featuritis is why date formatting and especially
> > >> parsing do NOT belong as opcodes. It's too big a problem to solve in the
> >
> > I agree.
>
>
> And the more I think about it, the more I think this concern is misplace
On Tue, 9 Mar 2004, Edward S. Peschko wrote:
> On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> > "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib
> > directory.
>
> fair enough, but then where does the distinction lie? Why put gmtime, et al.
> in opcodes? As
On Sat, 6 Mar 2004, Jared Rhine wrote:
> It'd be nice if the first item, "gmclock" wasn't defined in terms of
> "UTC". Regardless of the future fate of UTC leap seconds, any
> UTC-based clock would need to account for leap seconds going back,
> right? So it seems that GMT should be preferred in
On Sat, 6 Mar 2004, Jared Rhine wrote:
> It'd be great, if possible, to get a statement here from the DateTime
> group sanctioning one or another particular Parrot clock interfaces as
> "efficient, complete, and preferred". I haven't poked over to see
> if they are chatting about this Parrot issu
> Sometimes, if the customer wants to do an audit, we have to process
> over a month's worth, so we are bound by the actual execution
> time of the Perl script and the access time of a Sleepycat (Berkeley DB)
> database. The Perl programs must be able to scale
> with call/message volume, and right
> On a platform with a halfway decent JIT, a pure-PASM implementation
> could be as fast as an op-based one, given liberal use of the non-PMC
> registers. Maybe faster--no need to transcode to ASCII, extract a C
> string, or hack around platform X's quirks. And I'd imagine that the
> Parrot s
Hi Brent,
Welcome back to p6i. ;)
At 08:12 PM 3/9/2004 -0800, Brent \"Dax\" Royal-Gordon wrote:
On a platform with a halfway decent JIT, a pure-PASM implementation
could be as fast as an op-based one, given liberal use of the non-PMC
Agree.
Besides, how fast does your date handling really need t
Edward S. Peschko wrote:
On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote:
Edward,
Want to call strptime? Use NCI. No need for anything new in the core.
That's WHY it's the CORE.
I think there is a misunderstanding here. I don't think that strftime by itself
in the core - which
On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote:
> Edward,
>
> Want to call strptime? Use NCI. No need for anything new in the core.
> That's WHY it's the CORE.
I think there is a misunderstanding here. I don't think that strftime by itself
in the core - which probably has sys
Edward,
Want to call strptime? Use NCI. No need for anything new in the core.
That's WHY it's the CORE.
—
Gordon Henriksen
[EMAIL PROTECTED]
to bytecode).
I tell you what - why don't base your decision on an empirical test.
I'll write a c program around strftime that does a given
set of formatting dates and times, as well as the reverse translation, and
we can benchmark that program versus the bytecode that parrot offers in
At 03:52 PM 3/9/2004 -0800, Edward S. Peschko wrote:
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib
> directory.
fair enough, but then where does the distinction lie? Why put gmtime, et al.
in opcodes? As well
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> Edward S. Peschko wrote:
>
> > Gordon Henriksen wrote:
> >
> > > Leave parsing and formatting entirely to libraries.
> > > Absolutely no need for that in the instruction set.
> >
> > well, I have a bit of a problem with that...
Edward S. Peschko wrote:
> Gordon Henriksen wrote:
>
> > Leave parsing and formatting entirely to libraries.
> > Absolutely no need for that in the instruction set.
>
> well, I have a bit of a problem with that... As it was pointed out
> before, people have gone hogwild with the parsing and for
dates to subtracting 2000
> or dealing with negative numbers; that'll change everything and really
> advance the state of the art.
What you're complaining about is the elements of Perl's gmtime/localtime
arrays. Actually, I suggested removing that quirk from splittime:
> &
> Leave parsing and formatting entirely to libraries. Absolutely no need
> for that in the instruction set.
well, I have a bit of a problem with that... As it was pointed out
before, people have gone hogwild with the parsing and formatting
routines, and its a bloodbath of modules on CPAN with diff
[Gordon == [EMAIL PROTECTED] on Wed, 3 Mar 2004 16:48:45 -0500]
Gordon> gmclock(out Nx)
Gordon> UTC clock in seconds since hrs Jan 1, 2000,
Gordon> ignoring leap seconds.
Gordon> tolocal out Nx, out Iy, in Nz
Gordon> x is set to z converted to the local time z
On 3/4/04 5:09 PM, Dan Sugalski wrote:
> If the local system returns localtime, I can see adjusting to GMT or UTC, or
> whatever, as that ought to be a trivial transform.
Er, I'm not so sure about that. That means you'd have to be 100% sure that
you can determine the local timezone without any am
At 12:55 PM -0800 3/4/04, Robert Spier wrote:
> I agree. That's why I'd like to see TAI be the default "seconds
since some epoch".
It seems like we want the "default" to be the simplest and fastest one
we can support.
Exactly. Which is the count that the system C RTL returns when you
ask it, no
> I agree. That's why I'd like to see TAI be the default "seconds
> since some epoch".
It seems like we want the "default" to be the simplest and fastest one
we can support.
If someone wants something different, they can do the moral equivalent
of:
use Time::TAI;
or
use Time::UTC;
or
On Thu, 4 Mar 2004, TOGoS wrote:
> > Actually, they did. UTC (which was the original
> > reference) is defined such that noon is within .9
> > seconds of the sun being as directly overhead as
> > it can be, and is thus directly tied to the
> > behaviour of the planet.
UTC may stop tracking UT1 an
On Thu, Mar 04, 2004 at 09:12:47AM -0500, Dan Sugalski wrote:
: At 7:30 PM -0800 3/3/04, TOGoS wrote:
: > > Interesting -- so the planet's finally gotten
: >> its act together and settled on a rotational
: >> speed, huh? Cool. :)
: >
: >Nobody said anything about a planet.
:
: Actually, they did.
> >> Interesting -- so the planet's finally gotten
> >> its act together and settled on a rotational
> >> speed, huh? Cool. :)
> >
> >Nobody said anything about a planet.
>
> Actually, they did. UTC (which was the original
> reference) is defined such that noon is within .9
> seconds of the sun
At 7:30 PM -0800 3/3/04, TOGoS wrote:
> Interesting -- so the planet's finally gotten
its act together and settled on a rotational
speed, huh? Cool. :)
Nobody said anything about a planet.
Actually, they did. UTC (which was the original reference) is defined
such that noon is within .9 seconds
> Interesting -- so the planet's finally gotten
> its act together and settled on a rotational
> speed, huh? Cool. :)
Nobody said anything about a planet. A clock should
tell you how much time has gone by. If I get a time,
sleep(1), and get another time, time 2 should be about
time1 + 1 second, re
On Wed, 3 Mar 2004, Zellyn Hunter wrote:
> For those of you not up to speed on how much date and time confusion there is,
> I remember this article by Dave Rolsky as being interesting:
>
> http://www.perl.com/pub/a/2003/03/13/datetime.html
You might also be interested in what Dave and others have
For those of you not up to speed on how much date and time confusion there is,
I remember this article by Dave Rolsky as being interesting:
http://www.perl.com/pub/a/2003/03/13/datetime.html
At 2:21 PM -1000 3/3/04, Joshua Hoblitt wrote:
On Wed, 3 Mar 2004, Dan Sugalski wrote:
Gah. OK, I'm about to declare that the time op *always* returns time
as GMT, though without specifying an epoch, unless someone's got a
good reason not to. That takes at least one variable out of the
problem
At 2:19 PM -1000 3/3/04, Joshua Hoblitt wrote:
On Wed, 3 Mar 2004, Dan Sugalski wrote:
At 12:59 PM -0800 3/3/04, Larry Wall wrote:
>On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
>: On Wed, 3 Mar 2004, Larry Wall wrote:
>: Anyways, I recall some discussion on p6l from years ag
On Wed, 3 Mar 2004, Dan Sugalski wrote:
> Gah. OK, I'm about to declare that the time op *always* returns time
> as GMT, though without specifying an epoch, unless someone's got a
> good reason not to. That takes at least one variable out of the
> problem.
The GMT system is dead... do you mean UT
On Wed, 3 Mar 2004, Dan Sugalski wrote:
> At 12:59 PM -0800 3/3/04, Larry Wall wrote:
> >On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
> >: On Wed, 3 Mar 2004, Larry Wall wrote:
> >: Anyways, I recall some discussion on p6l from years ago about using
> >: TAI (and I think specifi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:13 AM -1000 3/3/04, Joshua Hoblitt wrote:
>>TAI is 1958-01-01T00:00:00.
> And that's a good base time too, other than it being off of clock
> time for everyone by 32 seconds, give or take. Tempting, though.
Bahh, these few seconds. Dan, the year, t
"Dan Sugalski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Reasonable enough, though there's something to be said for a
> completely meaningless (to most people) epoch so folks stop treating
> the number as a number with meaning and instead treat it as a black
> box thing they can
On Wed, Mar 03, 2004 at 04:18:14PM -0500, Dan Sugalski wrote:
: >Don't get me wrong--I think the concept of TAI time is great.
: >It's just always going to be a fixed number of seconds different than
: >Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC.
:
: That, as they say, turn
Oracle actually has the most elegant Gregorian time manipulation
implementation I've seen. The only operations it really supports are
add_months and add_days. Year +/- can be implemented with add_months*12.
All of add_ can be synthesized from
add_days. This scarcity of operations yields the eleganc
At 12:59 PM -0800 3/3/04, Larry Wall wrote:
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
: Anyways, I recall some discussion on p6l from years ago about using
: TAI (and I think specifically libtai) as the internal time format
: for p6. Is
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
:
: > Well, you can do whatever you like with Parrot, but I want Perl 6's
: > standard interface to be floating point seconds since 2000. Floating
: > point will almost always have enough preci
At 10:13 AM -1000 3/3/04, Joshua Hoblitt wrote:
On Wed, 3 Mar 2004, Dan Sugalski wrote:
FWIW, if we start getting into the "What should our base time for the
epoch be" arguments, I'll warn you that the answer if I have to make
one is probably Nov 17, 1858 at midnight, give or take a bad memory,
On Wed, 3 Mar 2004, Larry Wall wrote:
> Well, you can do whatever you like with Parrot, but I want Perl 6's
> standard interface to be floating point seconds since 2000. Floating
> point will almost always have enough precision for the task at hand,
> and by the time it doesn't, it will. :-)
Ar
On Wed, 3 Mar 2004, Dan Sugalski wrote:
> FWIW, if we start getting into the "What should our base time for the
> epoch be" arguments, I'll warn you that the answer if I have to make
> one is probably Nov 17, 1858 at midnight, give or take a bad memory,
> and our time value'll be a 64-bit integer.
At 10:29 AM -0800 3/3/04, Larry Wall wrote:
But the overriding consideration is that normal users should
I have to remember the units of the fractional seconds.
Is it nanoseconds this week?
Right, the units will always be seconds. That, at least, will stay constant.
--
At 6:03 PM + 3/3/04, [EMAIL PROTECTED] wrote:
> What I'm thinking we may want to do is provide a minimal
interface--turn the time integer into a string rep or split out into
an array, something like:
localtime Sx, Iy
gmtime Sx, Iy
You almost have to provide at least these, as you
On Wed, Mar 03, 2004 at 11:37:09AM -0500, Dan Sugalski wrote:
: FWIW, if we start getting into the "What should our base time for the
: epoch be" arguments, I'll warn you that the answer if I have to make
: one is probably Nov 17, 1858 at midnight, give or take a bad memory,
: and our time value
> What I'm thinking we may want to do is provide a minimal
> interface--turn the time integer into a string rep or split out into
> an array, something like:
>
> localtime Sx, Iy
> gmtime Sx, Iy
>
You almost have to provide at least these, as you have to deal with
how various OS's ha
At 11:37 AM 3/3/2004 -0500, Dan Sugalski wrote:
I'm torn here as to what to do. On the one hand, it's supremely tempting
to punt and not have parrot do a darned thing with the time and leave it
to library code to handle it. On the other, CPAN is littered with the
carcasses of time and date modul
Yep, time to dive into yet *another* swamp. (Isn't this fun?)
Right now we've got the capability of getting the current time in
epoch seconds with the time op. This is good. However there's the
issue of actually *doing* something with it.
I'm torn here as to what to do. On the one hand, it'
51 matches
Mail list logo
