🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth nqp/new-disp: ec787abdf1 | Altai-man++ (committed using GitHub Web editor) | tools/templates/MOAR_REVISION
Update MOAR_REVISION
 10:42
rakudo/new-disp: ba0e77cae3 | Altai-man++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Update NQP_REVISION
 10:43
nqp/lift_generator_hash_lookups: 8ea45b6445 | (Timo Paulssen)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
move lookups of op generators out of repeated code

in some cases that moves it from the body of a closure that generates an op to the sub that creates the closure (when we use the same closure for ops that are extremely similar), and in others it moves the lookup from the body of a loop to before the loop, or from two usages to before the usages.		 10:48
nqp: timo++ created pull request #737:
move lookups of op generators out of repeated code		 10:49
nqp/lift_generator_hash_lookups: 93ccf380b3 | (Timo Paulssen)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
move lookups of op generators out of repeated code

in some cases that moves it from the body of a closure that generates an op to the sub that creates the closure (when we use the same closure for ops that are extremely similar), and in others it moves the lookup from the body of a loop to before the loop, or from two usages to before the usages.		 10:57
nqp/lift_generator_hash_lookups: 4e6d9bca05 | (Timo Paulssen)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
move lookups of op generators out of repeated code

in some cases that moves it from the body of a closure that generates an op to the sub that creates the closure (when we use the same closure for ops that are extremely similar), and in others it moves the lookup from the body of a loop to before the loop, or from two usages to before the usages.		 11:22
timo sorry for the noise :)
Geth nqp/new-disp: 77a76c4584 | (Timo Paulssen)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
move lookups of op generators out of repeated code

in some cases that moves it from the body of a closure that generates an op to the sub that creates the closure (when we use the same closure for ops that are extremely similar), and in others it moves the lookup from the body of a loop to before the loop, or from two usages to before the usages.		 12:14
lizmat sanity question: does it ever make sense with Lock, to have a $lock.protect { ...; $lock.protect { } } ??? 14:35
aaah... ok, if it inside of a Promise.then: { } I guess 14:36
sena_kun releasable6, status 15:02
releasable6 sena_kun, Next release in ≈8 days and ≈3 hours. There are no known blockers. Changelog for this release was not started yet
sena_kun, Details: gist.github.com/60a070c1fea2fa03ac...8f50d8aaf7
ugexe you can start new threads inside a protect block 15:28
lizmat ugexe: that too 15:32
I was glancing through the Cache::Async code, and was going whaaa ?
Geth rakudo/new-disp: 63f2f310f0 | (Jonathan Worthington)++ | 2 files
Eliminate setting no inline marker for callsame

And other such functions. With the new dispatch mechanism, MoarVM already has the knowledge to only go inlining what it can (at the time of writing it can't do any such inlinings, but it knows not to try and then get it wrong).		 18:24
Xliff m: say +DateTime.now 18:38
camelia Cannot resolve caller Numeric(DateTime:D: ); none of these signatures match:
(Mu:U \v: *%_)
in block <unit> at <tmp> line 1
Xliff m: say DateTime.now.Int
camelia No such method 'Int' for invocant of type 'DateTime'
in block <unit> at <tmp> line 1
Xliff Why don't either of those use .posix behind the scenes?
lizmat there's a PR for that, afaik 18:40
Xliff lizmat: That returns an Instant. 18:45
lizmat m: dd now.Int
camelia 1631299590
lizmat hmmm 18:46
Xliff Indeed. Also consider:
m: now.Int.say; DateTime.now.posix.say 18:47
camelia 1631299659
1631299622
Xliff m: now.^name.say
camelia Instant
Xliff So I get a difference of 37 from both camelia and my local machine. Odd. 18:48
m: my $m = 42.^lookup('Int'); $m.file.say; $m.line.say 18:50
camelia SETTING::src/core.c/Int.pm6
52
japhb Xliff: TAI v. UTC seconds (leap second offset) 20:04
Xliff japhb: Is that value always going to be 37? 20:10
Ah.... or will it drift further over time? 20:11
Would 37 be a safe value up to the lifetime of the Obama's grandkids?! :) 20:13
Rather... how long will that value be accurate? 20:14
lizmat well, everybody thought that value would only increase.. 20:27
but now there's talk of a negative leap second.. in which case that value would decrease 20:28
Xliff Figures. :) 20:29
japhb Yeah, what lizmat++ said. Personally I think doing a negative leap second would be a horrible idea, but I'm not exactly the one with decision authority on that one. :-) 21:16
Xliff So ballpark... how long will that 37 value last? 21:18
japhb Xliff: ~months 21:19
Sometimes a few years
Xliff: Come to think of it, you can see the frequency in the Rakudo source -- search for `BEGIN leap-second-dates` in src/core.c/Rakudo/Internals.pm6 21:24
ugexe so apparently there is something really slow about the table generated by `zef update`, which i assume is something like unneccesary stringification or some such. however it is interesting that 3.3ghz i7 macbook takes ~20s whereas a m1 takes ~10s 21:28
Xliff ugexe: m1? Instance type? 21:41
ugexe apple silicon 21:42
both macs are maxed out 13" but they also means the intel is only a dual core 21:45
s/they/that/ 21:46
Xliff ugexe: OK, cool. 22:05
Getting the last pieces to my Threadripper setup, today. Want me to run anything?
ugexe sounds like fun. if i think of anything i'll let you know 22:12

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!