github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:24 evalable6 left, linkable6 left 01:26 linkable6 joined 01:27 evalable6 joined 01:34 lucasb left 03:09 raku-bridge left, raku-bridge joined 04:33 evalable6 left, coverable6 left, linkable6 left, tellable6 left, unicodable6 left, bloatable6 left, quotable6 left, squashable6 left, bisectable6 left, shareable6 left, notable6 left, committable6 left, releasable6 left, nativecallable6 left, greppable6 left, sourceable6 left, benchable6 left, statisfiable6 left 04:34 bloatable6 joined, releasable6 joined, linkable6 joined 04:35 tellable6 joined, notable6 joined, statisfiable6 joined, shareable6 joined, evalable6 joined, coverable6 joined, quotable6 joined 04:36 committable6 joined, sourceable6 joined, nativecallable6 joined, bisectable6 joined, greppable6 joined, benchable6 joined 04:37 unicodable6 joined, squashable6 joined 09:35 sena_kun joined
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
10:59 patrickb joined 12:10 Altai-man joined 12:12 sena_kun left 13:12 patrickb left 14:43 domidumont joined
nine Looks like I'm now trapped in a perpetual loop of fix one case, break another :( 15:04
15:27 MasterDuke left 15:29 MasterDuke joined 16:10 zakharyas joined 16:12 sena_kun joined 16:13 Altai-man left 16:45 MasterDuke left
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
19:23 Altai-man joined 19:25 sena_kun left 19:34 domidumont left
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
19:50 MasterDuke joined 19:53 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined
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
20:07 patrickb joined 20:11 sena_kun joined 20:13 Altai-man left 20:22 tib left, camelia left 20:25 tib joined, camelia joined
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
20:56 travis-ci joined
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
20:56 travis-ci left
jnthn vrurg: Probably you need to tweak the way signatures are lowered (lower_signature or some such in Actions) 21:09
21:09 sena_kun left
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
21:12 patrickb left
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
22:10 zakharyas left 23:07 leont joined 23:49 leont left

Powered by Cro and the Raku® Programming Language.

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

Thank you!