github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 wonders - if rr is the debugging tool of choice for pirates, what do ninjas use? 09:42
moritz constant vigilance 09:43
moon-child I wonder, is r2 the sequel to rr? 09:44
moritz shouldn't the sequel to rr be called rt? 09:47
moon-child m: say 'rr'.succ 09:48
camelia rs
moon-child it's confirmed: time to rewrite it in rust™ 09:49
nine Looks like I'm now trapped in a perpetual loop of fix one case, break another :( 15:04
nwc10 Anyone can anser, but I suspect... 18:00
nine: If I have a testcase, where I
1) delete .precomp 18:01
2) run it - behaviour A
3) run it again - behaviour B
what does this tell me?
oh, sigh, stranger
I think it's just sometimes A, sometimes B 18:02
I guess I need to remember how to turn off address space layout randomisation
this one is strange
yes, it is. smoetimes A, sometimes B 18:04
basically, run t/spec/S09-multidim/assign.t with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
(fortunately it doesn't seem to be the JIT - fun still happens with MVM_JIT_DISABLE=1 too) 18:05
lizmat is behaviour A "test pass" and B "some tests fail" ? 18:28
nwc10 one particular test fails in the bad case 18:29
this test fails, because the exception is not thrown: 18:30
dies-ok { my @a[2;2] = <a b>, <c d e> }, 'Cannot assign to many items at first dimension';
lizmat RAKU_TEST_DIE_ON_FAIL=1 rt 'dies-ok { my @a[2;2] = <a b>, <c d e> } for ^10000 18:35
looks like being a golf for it
it fails after 315 to about ~800 attempts 18:36
for me at least
s/rt/raku -MTest -e/
after it failed once, it does not recover it seems 18:37
taking the `my @a[2;2]` out of the loop, does not fix it 18:38
it just appears to increase the number of iterations to make it fail
making the array a native shaped array, does not appear to change the failure or the failure rate 18:39
nwc10 from sitting inside gdb, the failure (to fail) seems to be because the value that is being assigned to @a is 2 lists of 2 elements (not a list of 2, and a list of 3) 18:41
but I can't figure out why the wrong thing is there
"sometimes"
lizmat different golf: 18:42
my @a[2;2]; die unless dies-ok { @a = <a b>, <c d e f> } for ^10000; LEAVE dd @a
or perhaps: 18:43
my @a[2;2]; die @a.raku unless dies-ok { @a = <a b>, <c d e f> } for ^10000
nine sounds like spesh?
nwc10 well, I can only make it fail with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 18:44
nine what does it do with MVM_SPESH_DISABLE=1?
nwc10 which most definately is spesh
it has never failed for me without MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 so MVM_SPESH_DISABLE=1 isn't going to chagne that
nine tools/jit-bisect.pl has a --spesh mode
lizmat doesn't die with MVM_SPESH_DISABLE=1 for me
nwc10 nine: it's not a reliable fail. How does one bisect that? 18:45
*this* is my problem. If I can get a reliable testcase. or even one that happens often enough that I can cut it down, I'd be happier
lizmat: what is rt?
lizmat rt is an alias I have for raku -MTest -e 18:46
nwc10 nine: I already hash hash randomisation disabled.
aha
lizmat dies after ~ 20 iterations for me with MVM_SPESH_BLOCKING=1
actually, looks like it *always* breaks at the 22nd iteration that way 18:47
nine sounds quite reproducible then :)
lizmat with MVM_SPESH_NODELAY=1 it taks about 4500 iterations before it breaks 18:48
*takes
nwc10 OK. Thanks
right. That now seems to be something that relibly fails
what happened was
I decided that I was annoyed that various spectests always fail with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 18:49
so decided to fix it
github.com/MoarVM/MoarVM/pull/1386 fixes two 18:50
github.com/MoarVM/MoarVM/issues/1387 because I can't fix that one 18:51
oh, and github.com/MoarVM/MoarVM/pull/1384 beacuse the spectests fail on every 32 bit platform. 18:52
it's spesh but not the JIT. fails with MVM_JIT_DISABLE=1 18:54
sweet, yes, totally portable fail. <-- that window 18:55
has a ppc32 build, and it fails there. 18:56
no nasty grubby assembler here.
lizmat fwiw, I can't get it to fail on 1dim shaped array 18:57
3dim array fails in a way similar to the 2dim shaped array
nwc10 nine: it might have a spesh mode, but it seems to have no documentation 19:00
lizmat my guess is something is awry with nqp::atposnd 19:07
in fact: the code in src/core.c/Array/Shaped is using the nqp op to throw the exception *after* it figured it has too many vakues 19:08
*values
hmmm.. maybe the problem is, is that it doesn't get there... 19:10
hmmm.. indeed: 19:13
use nqp; my int @i = 1,2; my int @a[2;2]; dies-ok { nqp::atposnd(@a,@i) } for ^10000
doesn't fail for me at all
nwc10 confirm that it doesn't get there - breakpoint set with gdb isn't reached, the exception is not thrown, the test then fails 19:16
lizmat so either $pulled has become IterationEnd when it shouldn't have, or an index is not updated, or the iterator has become lazy all of a sudden 19:21
nwc10 OK, I have it running... 19:35
SPESH Broken frame: 3942. 19:40
SPESH Acquiring log: spesh-3942.txt
well, it says someting abuot Spesh of 'meta_methods' (cuid: 125, file: gen/moar/Metamodel.nqp:1041)
but I don't know how the rest of that file works.
Geth_ MoarVM: 9fbcdb4de6 | (Nicholas Clark)++ | src/6model/reprs/P6opaque.c
P6opaque's `spesh` must handle P6bigint values inline, as some are too big.

P6opaque's `spesh` will attempt to take a concrete P6bigint known value and convert it to a `MVM_OP_const_i64`. This doesn't work if big integer's value is to large than an MVMint64.
Previously the code was not considering this corner case. It was calling ... (12 more lines)		 19:42
MoarVM: d607387c34 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/P6opaque.c
Merge pull request #1386 from MoarVM/P6opaque-spesh-must-inline-bigint-value-lookup

P6opaque's `spesh` must handle P6bigint values inline, as some are too big
nwc10 good *, jnthn
jnthn o/
nwc10 \o
jnthn Just had a spare moment waiting for dinner to be delivered and figured I'd knock at least one PR off the review queue :)
nwc10 OK, I really don't know how to figure out what spesh-3942.txt is telling me. 19:44
ha, found the file. It's in rakduo. 19:45
And the culprit method is just this:
# Get the meta-methods in order of declaration.
method meta_methods($obj) {
@!meta_methods
}
Geth_ MoarVM/master: 9 commits pushed by (Nicholas Clark)++, (Jonathan Worthington)++ 19:46
Geth_ MoarVM/master: 4 commits pushed by (Nicholas Clark)++, (Jonathan Worthington)++ 19:56
nwc10 as best I could tell that was the only static variable
jnthn nwc10: Dinner is arriving, so will be away for a bit. I left a comment in the reivew of that PR about something that could also probably be simplified thanks to your work. 19:57
I should probably have filed an issue, but later (well, I just need to remember...) :)
nwc10 OK, mail arrived
jnthn bbl o/
nwc10 enjoy food 19:58
vrurg Can somebody help me with parameter binding a bit? I'm working on making this gist work: gist.github.com/vrurg/caeac11d7a2c...a2df96c30. Basically, everything works, the subset gets instantiated correctly, as introspection shows. But when method foo is called I get 'inconsistent bind error' and it looks like moar internally still typechecks against uninstantiated subset. 20:32
Can I do something about it or is it moar specifics? 20:34
travis-ci MoarVM build passed. Jonathan Worthington 'Merge pull request #1374 from MoarVM/eliminate-static-race-condition 20:56
travis-ci.org/MoarVM/MoarVM/builds/745269145 github.com/MoarVM/MoarVM/compare/9...a1af7724f1
jnthn vrurg: Probably you need to tweak the way signatures are lowered (lower_signature or some such in Actions) 21:09
jnthn You'll need to teach it to not enforce the type check if the value is undefined (e.g. fix up the code-gen for that) 21:10
vrurg jnthn: done already. I don't see it invoked though after all.
jnthn Try dumping the bytecode to make sure it looks right
(e.g. it's doing a isconcrete and then not doing the istype or whatever) 21:11
Oh, or maybe it's about the constraint type checks, which are emitted separately from the nominal ones
Nominal ones happen before the symbol is bound, constraint ones after
I guess it's the latter
But again, can be worth checking it only does them conditionally 21:12
vrurg Somehow I forgot to check the AST. But at least you re-assured me that binding wouldn't bypass what lower_signature prdouces. So, it's now clear where to look at. 21:15
jnthn: BTW, glad to see you again!
jnthn No, other than unboxing for native types, the VM doesn't enforce any parameter type checks 21:16
So it'll all be in lower_signature
vrurg Oh, my... At least it was so nice of me to inject debug printing into a generic branch of a condition and expect it to fire for a nominal one...
jnthn: Some of your help might be needed, if you have a spare minute. In the big rework of coercions I touched handling of generics in lower_signature. But to work at runtime the code needs to have access to the signature object. The only way I found is through ctxcode/getcodeobject which breaks inlining. If you have any idea how to help this situation I'd highly appreciate it. 21:19

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!