|
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 :) | ||