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