Search in IRC logs

Index





Results

Results from days 1 to 10, from overall 81 days

Result pages: 1 2 3 4 5 6 7 8 9

2013-03-25

16:08 PerlJam yep :(
16:08 cognominal joined #perl6
16:08 masak we got DateTime/Temporal settled. it works. it's a success.
16:08 masak next up: IO.
16:08 masak let's do this, people.

2013-03-17

22:31 dalek Heuristic branch merge: pushed 17 commits to nqp/vmarray-list by arnsholt
22:31 arnsholt Oh, good bot! =D
22:38 masak LlamaRider: everyone and no-one is the maintainer, I guess. I initiated the last Temporal refactor, but the code was quickly appropriated and improved by various people.
22:39 masak LlamaRider: there have been suggestions now and then that we take a wider grasp around timezone handling. my response is always the same: "go ahead, commit away! if we like the result enough, we'll put it in the spec, too!"
22:39 LlamaRider masak: I am getting timezone failures in the spectest and when I debugged my way into the timezone code my instinct was to rewrite rather than patch.
22:41 LlamaRider I felt like rewriting since timezones are a lie in the current code - they're just syntax sugar behind doing offset arithmetic
22:42 LlamaRider at least that's the impression I got from the DateTime-local-timezone class
22:44 masak if something is outright wrong in Temporal, then of course we should fix that.
22:44 masak and yes, I got that impression too last time I looked at both the spec and the Rakudo implementation.
22:44 LlamaRider well, a timezone is just an Int that has a negative or positive number of minutes in it. But $*TZ isn't conforming to that and is being the above-mentioned syntax sugar. I have gripes mainly with $*TZ right now
23:20 LlamaRider The spec doesn't mention anything about the nature of $*TZ ... I guess I will switch it to an int and refactor... Though to actually compute the TZ I will need to port some of the DateTime::Timezone magic. Will see
23:20 LlamaRider Also, now I feel awkward since moritz threw push permissions on me and I don't know how the submission cycle to rakudo works. Should I wait for someone to review my code in a branch and then push it? Or just push directly in Temporal.pm?
23:20 masak right. I guess the proposal is to put more of such magic in src/core/Temporal.pm
23:21 masak LlamaRider: short answer: do what you feel is appropriate.
23:21 masak do a branch if you're unsure. do a direct commit if you're relatively sure.

2013-03-04

09:03 masak oh!
09:04 masak I'm assuming timezone is hours, but it's something else, right? :)
09:05 * masak reads S32/Temporal
09:05 kresike joined #perl6
09:05 kresike hello all you happy perl6 people
09:16 huf masak: it's not a particularly useful thing to construct a timezone from due to dst rules.
09:16 sorear and if you're around UTC-1200 or UTC+1200, it can flip by 24h depending on the whims of local politicians
09:17 masak huf: cf discussion on how much logic to include in S32/Temporal.
09:17 masak huf: I'm fine with someone adding all the world's timezone handling in there. that person should volunteer to do the work, though. and to maintain it.
09:18 sorear masak: we can outsource the ongoing data collection process - just need to make it read zoneinfo files

2013-01-24

15:28 [Coke] which is a different scenario that what I posed.
15:32 masak gfldex: we don't ignore time zones so much as leave most of the handling to the programmer or non-core modules.
15:32 masak gfldex: this was a conscious decision at the time we refactored S32/Temporal back in 2010, to delimit the scope of DateTime and surrounding classes.
15:33 SunilJoshi joined #perl6
15:38 hash_table joined #perl6
16:10 masak oh huh.
16:10 jnthn Well, + is defined in the setting :)
16:10 masak Temporal.pm is fairly late, though.
16:11 jnthn Consider givign the enum keys explicit values using the pair syntax
16:11 masak ok.
18:03 SmokeMac_ joined #perl6
18:04 masak agreed.
18:04 masak japhb: I'm glad we got S32/Temporal straightened up after years of fumbling in the dark.
18:05 moritz now somebody please do the same for IO :-)
18:05 japhb masak, I don't know if I am the man for that.  On the one hand, I have spent some time trying to get datetime handling "correct", but I really don't feel encyclopedic in such knowledge, and I have already committed to too many Perl 6 projects as it is.  So I am torn.  :-/

2013-01-21

21:24 moritz does adding a sentence about a calendar not being supported as "slightly more work"?
21:24 xenoterracide joined #perl6
21:26 masak it's nice to see that temporal bikeshedding is still alive and well ;)
21:26 masak anyway, I plan to add something like a .delta method into the spec when I find the tuits.
21:26 masak and then I might as well go and implement it, too :)
21:28 * masak .oO( mmm, Hebrew dates )
21:29 masak lue: yes, Duration is part of CPAN's DateTime.
21:29 masak lue: part of the reason the temporal spec doesn't have it yet is that civic time is so messy, and I'm not even sure Durations can be made to follow standard mathematical laws.
21:30 masak maybe they can, to the point where you can say "things either behave sanely, or throw an exception".
21:30 japhb_ masak, if by "standard mathematical laws" you mean associativity and suchlike, I'm pretty sure the answer is no.

2013-01-01

20:52 masak "What's up?" "2012." :P
20:53 lorn joined #perl6
20:53 masak (either in the sense of "all used up", or in the Chinese spatial-temporal synesthesia sense of time proceeding downwards)
20:55 Bruce__ Does anyone know why map loops don't seem to run with a print statement after them?
20:55 masak Bruce__: you've fallen victim to insufficient sink-ness in the Rakudo implementation.

2012-12-21

13:05 GlitchMr Those were first in Perl 5.
13:05 GlitchMr Similarly, (?: )
13:05 masak lichtkind: try to avoid phrasings like "that's how it's spelled now", which induces a temporal sequencing between Perl 5 and Perl 6 that does not accord with observable reality. ;)
13:05 Celelibi joined #perl6
13:05 masak GlitchMr: yes, but which languages?

2012-08-20

07:01 masak .ymd and .hms aren't in there.
07:02 masak that makes it easier to think that it might have been just an omission.
07:06 * masak is kinda glad we didn't end up with "hextime" in the Temporal spec: https://github.com/perl6/specs[…]2afc17596a#L0R151
07:12 brrt joined #perl6
07:12 sorear *blink*
07:15 masak well, it was good that that version got pushed, I think. for me, it was a wake-up call; the Temporal spec could be changed from something bad to something even worse. but it could also be improved through focused effort.
07:16 masak I think the current spec has stood the test of time.
07:16 masak well, apart from the parts that have drastically changed, of course ;)

2012-08-19

22:21 pmichaud anyway, seeing that I agree: BUG
22:21 * masak submits rakudobug
22:22 masak moritz: I agree that we should have .ymd and .hms in S32/Temporal... but...
22:23 masak moritz: some part of me in 2012 wonders what it was that made me reject it in 2010. because I'm pretty sure I considered it.
22:24 * geekosaur recalls a bunch of "don't hardcode a preference for one particular date / time system" back then
22:37 quietfanatic Ah, yes, interpolating strings directly would cause problems like 0:11:4
22:37 sorear DateTime.now.fmt('%d/%m/%y') would also be shorter
22:38 * masak will leave it to simmer in the general discourse for a day or so, and then add it to the Temporal spec
22:38 masak sorear: yes, but that would further overload format strings, and I don't like format strings.
22:38 quietfanatic yes, but it'd need a different name from .fmt

2012-06-19

13:43 masak aye. we did.
13:44 moritz says who?
13:44 masak S32/Temporal.
13:49 dalek joined #perl6
13:49 Util joined #perl6

Result pages: 1 2 3 4 5 6 7 8 9