01:42 eternaleye joined 02:22 colomon joined 02:47 _ilbot joined 02:50 lue joined
lue I was a moron like stated earlier, but in a way different than I though [ so facepalm×2 :) ] the error about "near MAST::Node" points to the method signature, not its body. 04:28
doing s/MAST/QAST/ there brings me to NQPP6QRegex.nqp , failing with a "This type does not support associative operations" (assumedly caused by my change) 04:29
One way or another, I'm not sure MAST::Node actually exists. It only occurs once in the nqp repo (where it was before I replaced it), and in a similar declaration in the nqp-cc directory of the MoarVM repo. 04:30
yep, adding a dummy "my MAST::Node $b;" under %WANTMAP (and in-between a sanity-checking dummy "my int $a;" line) causes the error there. Somehow, there is no MAST::Node 04:55
nqp: my $no-value; say nqp::islist($no-value) 05:35
camelia nqp-parrot: OUTPUT«Confused at line 2, near "say nqp::i"␤current instr.: 'panic' pc 16308 (gen/parrot/stage2/NQPHLL.pir:6020) (gen/parrot/stage2/NQPHLL.nqp:426)␤» 05:36
..nqp-jvm: OUTPUT«Confused at line 2, near "say nqp::i"␤ in panic (gen/jvm/stage2/NQPHLL.nqp:379)␤ in comp_unit (gen/jvm/stage2/NQP.nqp:922)␤ in TOP (gen/jvm/stage2/NQP.nqp:820)␤ in parse (gen/jvm/stage2/QRegex.nqp:1251)␤ in parse (gen/jvm/stage2/NQPHLL.nqp:1378)␤ in…»
..nqp-moarvm: OUTPUT«Confused at line 2, near "say nqp::i"␤panic␤»
lue nqp: my $no-value; say(nqp::islist($no-value))
camelia nqp-moarvm, nqp-jvm, nqp-parrot: OUTPUT«0␤»
lue For those moarers out there, I'm having an error triggered on " elsif MAST::ExtOpRegistry.extop_known($moarop) {" of QASTOperationsMAST.nqp (after making that MAST::Node->QAST::Node change previously). The error is "This type does not support associative operations" 06:44
08:41 FROGGS joined
FROGGS Unable to parse expression in method_def; couldn't find final ')' at line 4403, near "MAST::Node" 09:21
\o/ 09:22
lue: do you know what?
lue: your --prefix is the problem, please let it point to nqp/install 09:23
../nqp/install in your case I think
10:04 tgt joined
jnthn FROGGS: Is the problem when the prefix = "" or "." or so? Maybe we should detect that in Configure? 10:06
FROGGS jnthn: hmmm, not sure yet
I am testing with an absolute path to MoarVM
hmmm, even an absolute path explodes... 10:09
it doesnt look that bad though: 10:10
/home/froggs/dev/MoarVM/bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --module-path=gen/moar/stage1 --setting-path=gen/moar/stage1 \
--setting=NQPCORE --no-regex-lib --target=mbc \
--output=gen/moar/stage1/MASTNodes.moarvm /home/froggs/dev/MoarVM/lib/MAST/Nodes.nqp
hmmm 10:21
I have no idea why it doesn't like this prefix 10:22
ohh, now I know 10:23
jnthn: we can't install to MoarVM, because that is what happens then:
MoarVM$ ll lib/MAST/*.nqp
-rw-r--r-- 1 froggs froggs 0 Nov 19 11:07 lib/MAST/Nodes.nqp
-rw-r--r-- 1 froggs froggs 0 Nov 19 11:07 lib/MAST/Ops.nqp
jnthn Ohh!
moritz those aren't very big :-) 10:24
jnthn Yeah, they really byte the dust...
OK, let's just say in Configure, "don't do that" :)
FROGGS yeah... or we fix it :o)
moritz well, I think the current default prefix is . 10:25
jnthn Hm :)
moritz just change that to install/ or so
jnthn We may want to make that install/'
right. :)
moritz nobody[tm] will manually supply a prefix of ., I hope
FROGGS moritz: still then somebody could let it point to MoarVM/ and get this weird parser failure
is there a cross platform way to check if two directories are the same? 10:27
moritz I don't think so 10:29
FROGGS hmmm
okay, I'll go for s/./install/ then
jnthn Though, you could just check for a README in . and then at the prefix, and make sure that it's the same size, which is high probability to give an accurate result ;) 10:30
dalek arVM: 18f9765 | (Tobias Leich)++ | Configure.pl:
make "install" the default for --prefix, moritz++
10:43
arVM: b37d10e | (Tobias Leich)++ | Configure.pl:
die if cwd eq prefix, lue++, jnthn++
13:41 tgt joined 14:02 tgt joined 15:02 jnap joined 15:17 colomon joined 15:42 woolfy left 15:48 pmichaud_ joined 15:49 tgt joined 15:51 sorear_ joined 15:52 harrow joined 16:00 tadzik joined 16:12 FROGGS[mobile] joined 16:42 FROGGS joined 17:40 ssutch joined 17:46 jnap joined 18:10 colomon joined 18:34 lizmat joined 19:38 woolfy joined 20:28 colomon joined 21:44 lizmat joined 21:49 eternaleye joined, woolfy left 22:59 BenGoldberg joined 23:01 colomon joined 23:02 arnsholt_ joined
lue is having an interesting time trying to learn MVM C code in Rakudo :) 23:30
23:36 lizmat joined 23:41 woolfy joined
jnthn lue: Best way to learn MoarVM is to start with the data structures. 23:42
lue: 6model.h, frame.h, threadcontext.h, instance.h are the key ones to read.
lue you're referring to the land of structs, correct? :)
jnthn aye
lue [ I started this because I thought "Oh, I'll just fix the p6store NYI issue". Didn't take me long to realize why I might not be the best candidate atm for implementing something essential :P ] 23:45
jnthn Oh, p6store is evil.
I'm still debating with myself over 2 ways to do it...
I was originally thinking "C to be faster", then realized that if I do it in C it'll need special handling when we get a specializer and JIT... 23:46
...and that even a non-JIT specializer will be able to do branch elimination...
(on the nqp::iscont(...)) 23:47
So I'm now learning back to emitting it as a series of ops.
lue did learn something about how MVM handles in/out params for the ops though, although GET_REG obviously doesn't work *exactly* like array indexing.
jnthn GET_REG(cur_op, 0) looks up the register number 0 bytes offset from the current PC 23:48
And register numbers take 16 bits
Which is why you'll see GET_REG(cur_op, 2) for the second arg.
lue jnthn: that kind of hidden nastiness that's beyond me is what I realized might be keeping a part of the CORE.setting compilation from working right now :)
jnthn Oh, p6store is the next blocker, yeah. 23:49
lue jnthn: I though there might've been some multi-byte (or generically, multi-'slot') stuff going on with that. Nice to see I was right :)