🦋 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.
00:03 reportable6 left 00:04 reportable6 joined 00:43 frost joined 02:10 linkable6 left, evalable6 left 02:12 evalable6 joined 03:12 linkable6 joined 05:38 unicodable6 left, reportable6 left, coverable6 left, nativecallable6 left, tellable6 left, bloatable6 left, evalable6 left 05:39 unicodable6 joined 05:40 coverable6 joined, reportable6 joined 05:41 evalable6 joined, tellable6 joined 06:02 reportable6 left 06:04 reportable6 joined 06:15 Xliff left, Xliff joined 07:41 nativecallable6 joined 08:56 [Tux] left 09:39 bloatable6 joined 10:30 squashable6 left 10:32 squashable6 joined 10:39 sena_kun joined
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 :)
11:29 hankache joined 11:36 hankache left 12:02 reportable6 left 12:04 reportable6 joined
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
12:21 [Tux] joined 12:44 frost left
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 ?
15:33 evalable6 left, linkable6 left 16:33 evalable6 joined 16:34 linkable6 joined 16:57 sena_kun left 17:49 leont left 17:50 leont joined 18:02 reportable6 left 18:04 reportable6 joined 18:16 melezhik joined 18:19 melezhik left
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
22:51 evalable6 left, linkable6 left 22:52 evalable6 joined 22:54 linkable6 joined 23:54 coverable6 left, tellable6 left, linkable6 left, unicodable6 left, benchable6 left, releasable6 left, nativecallable6 left, sourceable6 left, bloatable6 left, statisfiable6 left, bisectable6 left, reportable6 left, evalable6 left 23:55 tellable6 joined, benchable6 joined 23:57 nativecallable6 joined, coverable6 joined