Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
00:07
reportable6 left
00:08
reportable6 joined
01:37
statisfiable6 left,
statisfiable6 joined,
tellable6 left,
tellable6 joined,
bartolin left,
bartolin joined
01:40
frost joined
01:42
linkable6 left,
statisfiable6 left,
sourceable6 left,
releasable6 left,
tellable6 left,
evalable6 left,
coverable6 left,
quotable6 left,
kjp left,
sourceable6 joined,
bisectable6 left
01:43
kjp joined
01:44
statisfiable6 joined
02:07
sourceable6 left,
greppable6 left,
statisfiable6 left,
bartolin left,
statisfiable6 joined
02:10
statisfiable6 left
02:25
bartolin joined
02:32
linkable6 joined
02:39
coverable6 joined
02:40
tellable6 joined,
releasable6 joined,
bisectable6 joined,
evalable6 joined,
quotable6 joined
03:01
greppable6 joined
03:02
sourceable6 joined
03:08
statisfiable6 joined
|
|||
Nicholas | good *. * | 05:06 | |
strange bright thing in sky | 05:33 | ||
06:07
reportable6 left
06:10
reportable6 joined
|
|||
nine | I think I've seen that before | 10:21 | |
vrurg: I fail to see the difference in need for exception handling between low level locking hash and a high level implementation | 10:24 | ||
jnthnwrthngtn | The more general point is that we've already been down the "implement it in the VM, it'll be faster" and we already un-did a lot of that because it prevents spesh doing its job | 10:27 | |
Not to mention that writing stuff in HLL eliminates entire classes of bugs (can't get GC invariants wrong, for example) | 10:28 | ||
MasterDuke | i tried turning github.com/rakudo/rakudo/pull/4891...96f32R3344 directly into a call to `mul_I`, by making it `return QAST::Op.new(:op('mul_I'), $op[0], $op[0], QAST::WVal.new(:value($!symbols.find_in_setting('Int'))));`, but that just causes `P6opaque: get_boxed_ref could | 10:34 | |
not unbox for the representation 'P6bigint' of type Scalar` at runtime | |||
and i haven't figured out why yet | 10:35 | ||
jnthnwrthngtn | Missing decont | 10:38 | |
MasterDuke | oh...right...doh | 10:39 | |
hm, `nqp::decont($!symbols.find_in_setting('Int'))` still gives the same error. or you mean gen one? | 10:46 | ||
10:50
Altai-man joined
|
|||
jnthnwrthngtn | The $op[0] | 10:56 | |
nine | You need to decont $op[0] and/or $op[1] | ||
MasterDuke | doh (again) | 11:12 | |
huh. same | 11:16 | ||
11:42
wybpip[m] joined,
wybpip[m] left
12:06
reportable6 left
12:07
reportable6 joined
|
|||
lizmat | it just struck me that t/spec/S12-construction/destruction.t has been flapping a lot for the past 10 days or so | 12:10 | |
where the test is that a child DESTROY should be executed before a parent DESTROY | |||
nine | more like months | 12:31 | |
lizmat | ah... ok... :-( | 12:41 | |
13:07
rba left,
rba joined
13:28
[Coke]_ is now known as [Coke]
|
|||
MasterDuke | hm. i now have the mul_I generation working, but it obviously fails if the QAST::Var is not actually an Int. `nqp::istype($op[0].value, $!symbols.find_in_setting("Int"))` doesn't work. i'm obviously thinking even slower than usual today, what am i missing? | 14:19 | |
nine | What do you expect to find in $op[0].value? | 14:42 | |
MasterDuke wants to plead the 5th | 14:54 | ||
Nicholas | chocolate? coffee? | 14:55 | |
(this answers can be used for either question) | |||
these. pesky fingers | |||
nine | MasterDuke: you'll want to generate code that does the type check on that value (just like you need to do for the decont) | 14:57 | |
MasterDuke | ugh. i'll probably just stick with genning the &infix:<*> then, that's a bit simpler | 15:43 | |
though i do need to add some more checks, because currently in the optimizer `2.1 == 2` is true | 15:44 | ||
17:02
tailgate joined,
Util left,
Util joined
17:17
Altai-man left
17:53
sena_kun left
17:58
frost left
18:01
sena_kun joined
18:07
reportable6 left
18:08
reportable6 joined
20:03
sena_kun left
20:05
sena_kun joined
22:07
vrurg left
22:15
vrurg joined
22:55
vrurg left
23:23
vrurg joined
|