|
🦋 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
|
|||