From: chromatic
Date: Thu, 19 Feb 2009 11:45:54 -0800
The real question is "Should setting the read-only property on a
ResizablePMCArray set the contained PMCs to read-only as well?"
I can fix the test (answer "no") or I can fix the code (answer
"yes"). I just can't tell you
Assuming the Gregorian calendar, "one month from today" is well
defined for 98.15% of all dates, and there are a few logical options
for the other 1.85%. It's true you can't define "one month" as a
constant amount of time, but providing a method to return one month
after a given date is a reasonab
Author: lwall
Date: 2009-02-21 01:04:02 +0100 (Sat, 21 Feb 2009)
New Revision: 25469
Modified:
docs/Perl6/Spec/S06-routines.pod
Log:
rm some fossils from quasi
Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S0
On Fri, 20 Feb 2009, mark.a.big...@comcast.net wrote:
"one month from today" is ill-defined regardless what time system you
are using. There are dates from which "one month from today" can be
reasonably argued to be any of 5 different days. This is why bank
contracts are always to be written t
On Fri, 2009-02-20 at 15:33 -0600, Dave Rolsky wrote:
> Of course, if you're dealing with TAI only, you're safe for constants up
> to ONE_WEEK.
So we just define ONE_MONTH as 4 * ONE_WEEK, right?
*duck*
-'f
- Original Message -
From: "Dave Rolsky"
>That will make it clear
>that there's no way to calculate "one month from today" >using the core API.
"one month from today" is ill-defined regardless what time system you are
using. There are dates from which "one month from today" can be r
Author: lwall
Date: 2009-02-20 23:02:13 +0100 (Fri, 20 Feb 2009)
New Revision: 25465
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
typo
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-02-20 2
Author: lwall
Date: 2009-02-20 22:59:01 +0100 (Fri, 20 Feb 2009)
New Revision: 25464
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
define Instant and Duration as core types representing atomic time
Modified: docs/Perl6/Spec/S02-bits.pod
==
On Fri, 20 Feb 2009, Larry Wall wrote:
Duration and Instant are both simple (but typed) Num semantics
on seconds. There are no integers unless you specifically ask for
an interpretation in minutes, hours, fortnights, what have you.
The basic flow of time is continuous and stable in Perl 6, or a
On Fri, Feb 20, 2009 at 02:07:05PM -0600, Dave Rolsky wrote:
> On Fri, 20 Feb 2009, Dave Whipp wrote:
>
>> I'm getting a bit lost following precisely what's being proposed. What
>> I'm sort of feeling is that there are two fundamental immutable types
>> needed: Instants and Durations:
>>
>> mult
Author: autarch
Date: 2009-02-20 21:33:45 +0100 (Fri, 20 Feb 2009)
New Revision: 25462
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
Some formatting tweaks - also remove returns from overloading methods like Str
& Num
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.p
Author: autarch
Date: 2009-02-20 21:30:29 +0100 (Fri, 20 Feb 2009)
New Revision: 25461
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
Make the Temporal::Time $.second attribute a Num, per TimToady, and do
away with attoseconds entirely.
Modified: docs/Perl6/Spec/S32-setting-l
On Fri, Feb 20, 2009 at 2:36 PM, Chris Dolan wrote:
> Yes, just as I said: a constant offset between each of the proposed
> epochs.
No, because the offset is not constant. The delta between TAI and UTC
is currently 34 seconds. Two months ago it was 33 seconds. The next
time there's a leap seco
On Fri, Feb 20, 2009 at 01:36:12PM -0600, Chris Dolan wrote:
: Yes, just as I said: a constant offset between each of the proposed
: epochs. But my point remains: from the user's point of view it doesn't
: matter which epoch you choose to use behind the scenes, so you might as
: well pick the one
On Fri, 20 Feb 2009, Dave Whipp wrote:
I'm getting a bit lost following precisely what's being proposed. What I'm
sort of feeling is that there are two fundamental immutable types needed:
Instants and Durations:
multi sub infix:<-> (Instant, Instant --> Duration)
multi sub infix:<+> (Instan
> Considering time scales, there are three that significantly
> interrelate, and no matter what Perl 6 uses internally, it needs to be
> able to convert to and from these:
>
> TAI: continuous count of time using SI seconds as measured by atomic
> clocks, 60 seconds in every minute, 60 minutes in ev
Em Sex, 2009-02-20 às 10:53 -0800, Larry Wall escreveu:
> Perhaps we could just go with Instant and Duration as top-level roles
> since they're rather fundamental to lots of computing. As builtins
> they would presumably come with appropriate operators predefined. And
> as roles they could be twe
On Fri, Feb 20, 2009 at 03:31:03PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
: > By the by, I'm also inclined to agree with those who prefer "Instant"
: > to "DateTime" on aesthetic grounds.
:
: I should note that I'm insisting on DateTime just as the ref
I'm getting a bit lost following precisely what's being proposed. What
I'm sort of feeling is that there are two fundamental immutable types
needed: Instants and Durations:
multi sub infix:<-> (Instant, Instant --> Duration)
multi sub infix:<+> (Instant, Duration --> Instant)
multi sub in
On Fri, Feb 20, 2009 at 05:11:31PM +0100, TSa wrote:
> I'm unsure if the method dispatcher still falls back to subs,
It doesn't do that anymore, as it happens. You mark methods with "is
export" if you want that, and they automatically show up as both multis
and methods in any lexical scope that u
Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
> By the by, I'm also inclined to agree with those who prefer "Instant"
> to "DateTime" on aesthetic grounds.
I should note that I'm insisting on DateTime just as the reference p5
module in CPAN, I don't oppose it being called Instant in Perl
On Fri, Feb 20, 2009 at 08:12:36AM -0600, Dave Rolsky wrote:
> That's certainly fine with me, but I think we'd still want some simple
> objects on top of them, rather than handing people a single epoch numbre
> to deal with.
Certainly, we'll be depending on the type system to keep these things
On Fri, Feb 20, 2009 at 10:40:04AM -0600, Dave Rolsky wrote:
> I don't care what epoch we standardize on, as long as it's consistent
> across platforms.
Indeed, as long as it's well-typed we can actually pick whatever epoch
we want and assume that proper platform-specific conversions can be
auto
On Fri, Feb 20, 2009 at 02:21:50PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:
: > On Fri, 20 Feb 2009, Daniel Ruoso wrote:
: > > If we're going to use an epoch, it should be the Operating System's
: > > epoch. Anything else will lead to confusion and disor
David Green wrote:
I don't like dates just starting at midnight because I've run into too
many awkward cases where $time < $date doesn't do what you mean because
it assumes 0:00:00 when you meant 23:59:59. I'd rather have dates
becomes time-ranges.
And not all midnights exist, because time
Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:
> On Fri, 20 Feb 2009, Daniel Ruoso wrote:
> > If we're going to use an epoch, it should be the Operating System's
> > epoch. Anything else will lead to confusion and disorder ;P
> And which OS epoch would that be?
The one where the program
Dates starting at midnight is fine, but I agree that a Date shouldn't
automatically coerce into midnight on that date. If it's going to
autocoerce at all, I'd recommend noon instead, but better to force the
programmer to pick what they mean.
On Fri, Feb 20, 2009 at 2:32 AM, David Green wrote:
>
Considering time scales, there are three that significantly
interrelate, and no matter what Perl 6 uses internally, it needs to be
able to convert to and from these:
TAI: continuous count of time using SI seconds as measured by atomic
clocks, 60 seconds in every minute, 60 minutes in every hour, 2
# New Ticket Created by Garrett Rooney
# Please include the string: [perl #63374]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=63374 >
I'm getting a crash on OS X when trying to build rakudo. This is with
parrot r36907 a
# New Ticket Created by Allison Randal
# Please include the string: [perl #63360]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=63360 >
The attached git patch updates Rakudo's Configure.pl and Makefile.in to
configure and
On Fri, Feb 20, 2009 at 2:39 AM, David Green wrote:
> Why can't we just have time() that takes a :tz adverb and dispense with
> gmtime() and localtime()?
It depends on what sort of value time() returns. In the caes of
Perl5, the return value is completely independent of time zone. You
have to t
On Fri, 20 Feb 2009, Daniel Ruoso wrote:
Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu:
That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds. I sure wish they'd done away with civic leap secon
On Fri, 20 Feb 2009, Leon Timmermans wrote:
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky wrote:
After some discussion I made a number of drastic revisions to
S32-setting-library/Temporal.pod
What I want to see in Perl 6 is a set of very minimal roles that can be used
to provide a simply objec
HaloO,
Daniel Ruoso wrote:
Em Sex, 2009-02-20 às 11:19 +1100, Timothy S. Nelson escreveu:
if(! defined($footree.root)) { warn "Unrooted tree"; }
There are some other very interesting possibilities:
unless ($footree.can(root)) { warn "Unrooted tree"; }
or even better
unless ($fo
Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu:
> That being said, I'm thinking that all actual times represented by
> floats in Perl are TAI time, not the Unix pseudo time with hidden
> leap seconds. I sure wish they'd done away with civic leap seconds
> in 2000 and said we'll put in a le
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky wrote:
> After some discussion I made a number of drastic revisions to
> S32-setting-library/Temporal.pod
>
> What I want to see in Perl 6 is a set of very minimal roles that can be used
> to provide a simply object from gmtime() and localtime(). These
Author: autarch
Date: 2009-02-20 15:22:41 +0100 (Fri, 20 Feb 2009)
New Revision: 25459
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
method Str returns Str seems rather redundant and repetitive
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
==
On Fri, 20 Feb 2009, Richard Hainsworth wrote:
a) I am strongly in favour of "Instant" over "DateTime" for several reasons,
one being that it marks a new approach.
I don't care _that_ much. I'm happy to leave it to @Larry.
b) Although for business we use a calendar derived from the one decree
On Fri, 20 Feb 2009, David Green wrote:
On 2009-Feb-19, at 11:26 am, Dave Rolsky wrote:
What I want to see in Perl 6 is a set of very minimal roles that can be
used to provide a simply object from gmtime() and localtime(). These
objects should not handle locales, proper Olson timezones, string
On Thu, 19 Feb 2009, Larry Wall wrote:
Is there a way in which a class which does the Date role could change the
type $.year so it was "Int|Undef"?
Doesn't have to. Int already comes with an undefined value known as
Int, aka the protoobject. Only subset types (and their cousins, native
types
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed
[snip]
Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, ea
Dave Rolsky wrote:
After some discussion I made a number of drastic revisions to
S32-setting-library/Temporal.pod
What I want to see in Perl 6 is a set of very minimal roles that can
be used to provide a simply object from gmtime() and localtime().
These objects should not handle locales, pro
Em Sex, 2009-02-20 às 11:19 +1100, Timothy S. Nelson escreveu:
> if(! defined($footree.root)) { warn "Unrooted tree"; }
There are some other very interesting possibilities:
unless ($footree.can(root)) { warn "Unrooted tree"; }
or even better
unless ($footree ~~ RootedTree) { warn "Unr
43 matches
Mail list logo
