|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:16
sxmx joined
00:40
squashable6 left,
squashable6 joined
01:22
squashable6 left
01:24
squashable6 joined
06:00
mtj left
06:03
mtj joined
09:11
benchable6 left,
bloatable6 left,
committable6 left,
shareable6 left,
nativecallable6 left,
sourceable6 left,
quotable6 left,
bisectable6 left,
evalable6 left,
greppable6 left
09:12
coverable6 left,
unicodable6 left,
linkable6 left,
squashable6 left,
notable6 left,
statisfiable6 left,
tellable6 left,
releasable6 left,
bisectable6 joined,
sourceable6 joined,
shareable6 joined
09:13
linkable6 joined,
quotable6 joined,
nativecallable6 joined,
committable6 joined
09:14
greppable6 joined,
statisfiable6 joined,
unicodable6 joined,
coverable6 joined,
releasable6 joined,
notable6 joined,
tellable6 joined,
squashable6 joined,
benchable6 joined,
evalable6 joined
09:15
bloatable6 joined
|
|||
| nine | I think I've fixed the final remaining 32 bit signed extension JIT issues in this commit :) github.com/MoarVM/MoarVM/commit/db...1466d31027 | 10:57 | |
| lizmat | nine++ | 10:59 | |
| missing Geth again :-( | 11:00 | ||
| the decont logging wasn't reverted yet, right ? | |||
| nine | don't think so | ||
| dogbert17 | am I correct in assuming the the decont log fix was aimed at providing spesh with more accurate statistics thereby improving its results? | 11:40 | |
| *that the | |||
| one of the test programs I run from time to time has improved from taking 15s -> 10s thanks to that fix (well; I believe it's that fix anyway :) | 11:42 | ||
| lizmat | yes, that was the idea | 11:58 | |
| MasterDuke | nine: so you checked all the functions your plugin found? | 12:11 | |
| dogbert17 | hmm, there are a few spectest failures | 12:34 | |
| MasterDuke | nqp: for nqp::split(",", "abc,def", "ghasdfi") { say($_) } # uh yeah, wtf | 12:40 | |
| camelia | ghasdfi | ||
| MasterDuke | nqp: for nqp::split(",", "abc,def") { say($_) } # no wtf | ||
| camelia | abc def |
||
| MasterDuke | github.com/MoarVM/MoarVM/blob/mast...plist#L279 only supposed to take two args | 12:41 | |
| dogbert17 turns out that dogbert17 ran the spectest suite with a 100% full disk which isn't a good idea :( | 12:42 | ||
| MasterDuke | gist.github.com/MasterDuke17/8988a...f7a0a5370b some gdb info of the above split. GET_REG(cur_op, 2).s is "abc,def" and GET_REG(cur_op, 4).s is "ghasdfi" | 13:35 | |
| GET_REG(cur_op, 2).s should be "," and GET_REG(cur_op, 4).s should be "abc,def" | 13:36 | ||
| nqp-j: for nqp::split(",", "abc,def", "ghasdfi") { say($_) } # uh yeah, wtf | 13:39 | ||
| bartolin_ | ... "Operation 'split' requires 2 operands" | ||
| bartolin_ just tried that out | |||
| MasterDuke | thanks | ||
| bartolin_ | :) | ||
| MasterDuke | github.com/Raku/nqp/blob/master/sr....nqp#L2461 doesn't seem anything special about it's handling here... | 13:42 | |
| gist updated with bytecode. i can never read it well enough figure stuff out, but here the three strings are referenced gist.github.com/MasterDuke17/8988a...og-L51-L55 | 14:09 | ||
|
15:30
domidumont joined
16:07
zakharyas joined
17:23
domidumont left
|
|||
| nine | MasterDuke: yes | 17:35 | |
| I think QASTOperationsMAST.compile_mastop has an off-by-one error in arg count checking | 17:47 | ||
| nqp: note(nqp::eq_i(1, 1)) | 17:48 | ||
| camelia | No registered operation handler for 'eq_i' at gen/moar/stage2/QAST.nqp:1503 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op) from gen/moar/stage2/QAST.nqp:6172 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_node)… |
||
| nine | nqp: note(nqp::iseq_i(1, 1)) | ||
| camelia | 1 | ||
| nine | nqp: note(nqp::iseq_i(1, 1, 2)) | ||
| camelia | 0 | ||
| nine | nqp: note(nqp::iseq_i(1, 1, 2, 3)) | ||
| camelia | Arg count 4 doesn't equal required operand count 3 for op 'eq_i' at gen/moar/stage2/QAST.nqp:1567 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_mastop) from gen/moar/stage2/QAST.nqp:1780 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/Q… |
||
| nine | @core_operands_counts contains the op argument count including the write register (for the return value) yet compile_mastop increments the count for writing ops | 17:49 | |
|
20:28
squashable6 left
20:31
squashable6 joined
|
|||
| MasterDuke | nine: cool, then i won't bother to look at them | 20:45 | |
| nine: and wow, how long do you think that's been there? | |||
| lizmat | I guess pretty long | 20:47 | |
| but then again... you would only run into that when specifying too many params, right ? | 20:48 | ||
| so correct code would get serialized correctly, no? | |||
| MasterDuke | i've gotta assume so | 20:51 | |
|
20:56
zakharyas left
22:45
evalable6 left
22:48
evalable6 joined
|
|||
| japhb | It looks like there might have been a problem with the last libuv bump, back in February. After that, I can relatively easily trigger a "Failed to open dir: Too many open files" while uninstalling a dist with zef. Going back to a Rakudo from immediately before the libuv/MoarVM/NQP bump chain, I can't recreate the problem. | 23:36 | |