Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2013-11-18

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:30 colomon joined #moarvm
02:01 woosley joined #moarvm
02:15 colomon joined #moarvm
03:06 colomon joined #moarvm
03:12 woosley joined #moarvm
03:13 colomon joined #moarvm
03:50 ssutch joined #moarvm
04:17 colomon joined #moarvm
04:20 ggoebel17 joined #moarvm
05:33 lue trying to compile MoarVM, I just got "/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: 3rdparty/linenoise/liblinenoise.a(linenoise.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC"
05:33 lue Is this a common-ish thing to run into?
05:35 lue (I see -fPIC flags here and there in the top-level makefile, so I'm not entirely sure what's happening.)
05:39 lue Ah, it appears linenoise is provided precompiled (and I'm not well-versed in re-creating an .a file, alas :/)
05:43 lue (after switching to readline) aaaaand now libuv is killing the compilation. I guess somebody didn't compile these (on a 64-bit system|with -fPIC) :)
05:55 lue Or this is just me not using --static and seeing no good reason to :) .
05:57 TimToady don't ask me--I just work here
05:58 TimToady kind of a night-time janitor who doesn't actually ever clean anything
06:00 TimToady more of a night-watchman, I guess
06:01 lue TimToady: I'm hoping somebody in a few hours will read the above and offer a solution. :)
06:02 TimToady well, I supposed it's a good thing that we make different kinds of trouble from each other :)
06:03 TimToady *pose
06:17 FROGGS lue: make realclean in MoarVM, reconfigure and rebuild
06:17 FROGGS then rebuild at least rakudo
07:37 colomon joined #moarvm
07:55 FROGGS joined #moarvm
07:56 FROGGS morning
08:04 colomon joined #moarvm
08:41 colomon joined #moarvm
09:54 ssutch joined #moarvm
09:57 jnthn morning
10:00 moritz moarning, jnthn
10:41 nwc10 morning
10:41 nwc10 I get to this, which I assume is what you expect:
10:41 nwc10 p6store NYI
10:41 nwc10 Unhandled exception: Malformed UTF-8 at line 1 col 57   at gen/moar/stage2/NQPHLL.nqp:1219  (/home/nicholas/Sandpit/moar-g/languages/
10:41 nwc10 ...
10:43 jnthn The p6store bit, yes. The Malfmormed UTF-8 is a little worrying, though...
10:43 jnthn Memory corruption?
10:44 jnthn The code that puts together backtrace lines is pretty retarded. I mean, the original code makes sense 'cus it was written for dumping out a backtrace to C. But that means it spits out C strings, which we then turn back into MoarVM ones...
10:44 jnthn Mearning it's a bunch less efficient than it should be...
10:44 jnthn Though if you bottleneck on creating backtrace strings, you have a weird program :D
10:44 nwc10 I'll see if valgrind throws up anything
11:11 nwc10 (chug chug chug)
11:47 diakopter jnthn: you're a backtrace string
11:48 diakopter (glug glug glug)
11:48 jnthn diakopter: Mostly, I was just too lazy to refactor the code :)
11:49 diakopter :)
11:50 FROGGS who needs to refactor anyway when there is a perfect design in the first place :P
11:52 tgt joined #moarvm
12:06 dalek MoarVM: 436c194 | (Tobias Leich)++ | src/strings/utf8.c:
12:06 dalek MoarVM: memset to zero so we can search for \0 safely
12:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/436c1947b9
12:06 FROGGS nwc10: ^^
12:08 jnthn ah, good catch
13:38 nwc10 FROGGS: working on it. I suspect it will take 60 minutes
13:38 nwc10 take the computer, that is
13:39 FROGGS ahh
13:39 nwc10 single thread for the yawn.
13:39 FROGGS I was slightly shocked :o)
13:39 nwc10 it took bloody ages to run the the main parse under valgrind
13:40 jnthn I can't imagine...
13:40 FROGGS yeah, that sounds like valgrind :o)
14:15 odc joined #moarvm
14:51 nwc10 FROGGS: fixes that one.
14:51 nwc10 real    58m41.077s
14:51 nwc10 user    58m27.594s
14:51 nwc10 sys     0m6.880s
14:51 FROGGS cool
14:52 nwc10 one remaining valgrind error - I don't think that it's related:
14:52 nwc10 http://paste.scsys.co.uk/280278
14:52 nwc10 jnthn: http://paste.scsys.co.uk/280278 might be relevant - it might be a real failure to ROOT issue. Or might not.
14:52 FROGGS hmmm
14:52 nwc10 actually, "Address 0x3f92fbe8 is 8 bytes before a block of size 32 free'd" is not a message I've seen previously
14:54 FROGGS ummm
14:55 FROGGS we are pushing a null pointer here... https://github.com/MoarVM/MoarVM/blob/master/src/core/args.c#L424
14:56 jnthn FROGGS: No, we're not
14:56 jnthn FROGGS: We're pushign the address of a pointer that may be NULL
14:56 jnap joined #moarvm
14:56 FROGGS true
14:56 FROGGS phew
14:56 FROGGS :o)
14:58 * jnthn likes that many of the stack traces we see from C land are quite shallow :)
14:59 FROGGS yeah :o)
14:59 jnthn nwc10: That's a very weird error
14:59 jnthn 3259 is in the exit opcode
14:59 jnthn oh, hang on...
14:59 jnthn MVMint64 exit_code = GET_REG(cur_op, 2).i64;
15:00 jnthn exit                r(int64)
15:00 jnthn It should be GET_REG(cur_op, 0)
15:00 nwc10 point me at at patch, give me another 58+ minutes, and I can verify that :-)
15:00 jnthn That may well explain why we've seen weird issues where it doesn't stop building when there's a failure
15:01 nwc10 (you will not be charged for the 58 minutes)
15:01 jnthn it's 'cus it was reading a junk number for l'exit code...
15:01 nwc10 oh, complete aside. I've decided that Javascript docuentation makes about as much sense if I s/asynchronous/smurf/ but I don't get as stabby stabby angry)
15:02 nwc10 jnthn: that would be a bad thing :-)
15:02 jnthn you don't say!
15:02 FROGGS hehe
15:03 dalek MoarVM: d5c9efe | jnthn++ | src/core/interp.c:
15:03 dalek MoarVM: Fix exit op.
15:03 dalek MoarVM:
15:03 dalek MoarVM: nwc10++ for reporting issue, found thanks to valgrind++.
15:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d5c9efedcd
15:08 jnthn nwc10: While you're having "fun" with JavaScript, my "fun" is with WPF...
15:08 jnthn At lesat I'm finding ways to amuse myself writing this stuff...
15:08 jnthn enum Unpets { Manatee, PolarBear, Babirusa }
15:09 moritz WPF has a nice short hamming distance to WTF
15:09 nwc10 WPF?
15:10 moritz windows presentation framework, I guess
15:10 moritz s/framework/foundation/
15:10 jnthn Yes, that :)
15:10 jnthn And the distance to WTF is not lost on us.
15:11 jnthn Works for WCF too, which deserves it far, far more.
15:11 timotimo at least you don't have to touch MFC any more
15:11 jnthn Phew, yes :)
15:24 FROGGS hey, don't talk bad about MFC, it is almost as old as Perl :o)
15:24 FROGGS (20 years by now)
15:29 diakopter com+++
15:31 timotimo ole ole ...
15:37 eternaleye joined #moarvm
16:30 nwc10 valgrind now clean
16:30 jnthn \o/
16:31 diakopter I always read that as vulgarind
16:32 jnthn You're vulgar/ind...
16:52 ssutch joined #moarvm
16:59 FROGGS joined #moarvm
17:14 eternaleye joined #moarvm
17:14 eternaleye joined #moarvm
18:05 eternaleye joined #moarvm
19:09 FROGGS[mobile] joined #moarvm
19:56 lue FROGGS: realclean doesn't help :/
19:57 FROGGS hmm
19:57 FROGGS you still get the -RPIC or -fPIC msg?
19:58 lue yep, still "recompile with -fPIC" on linenoise
19:59 FROGGS then delete the linenoise folder from 3rdparties, reconfigure and rebuild
19:59 FROGGS you only need to `make` in rakudo afterwards, no need to touch nqp
19:59 jnthn If yo'v enothing valuable around, a git clean -fdx . may help
19:59 lue Eh, I just ran make realclean and then make and it worked. Somehow the intermediate "configure" step caused the problem?
20:00 FROGGS errm, no
20:00 FROGGS after realclean you should not be able to make
20:00 FROGGS (in theory)
20:01 lue OK, all of a sudden it works fine, and I have no clue why :/
20:03 FROGGS yeah, no lue either :o)
20:04 lue but make realclean (some ls commands) make did work, which apparently it shouldn't've?
20:05 FROGGS normally realclean deletes the Makefile
20:05 FROGGS maybe it does not do that (yet) for MoarVM
20:21 lue I get a failure on trying to compile stage1/QAST.nqp. Can I assume this isn't just me being terrible with this procedure? :)
20:22 lue "Unable to parse expression in method_def; couldn't find final ')'  at line 4403, near "MAST::Node"" to be precise
20:25 jnthn Argh, I thought we were free of those issues :(
20:25 lue there's also an assertion failure after a bunch of "from location" bt lines, but that doesn't seem like the cause of all this.
20:26 FROGGS could well be
20:26 FROGGS can you gist the version of moar and nqp-m together with you build output?
20:28 lue FROGGS: sure, just a minute
20:28 FROGGS cool
20:31 lue FROGGS: https://gist.github.com/lue/766f22eb0ac9f9c4c816
20:35 FROGGS lue: your --prefix points to the MoarVM repo?
20:35 lue FROGGS: yes, for the time being.
20:35 FROGGS k
20:36 FROGGS I have no idea what is going on :/
20:37 FROGGS the assertion at the bottom is unrelated as you already said
20:38 FROGGS (and it shows up because printing to stderr)
20:53 lue that's strange; none of my incredibly simple changes have made a dent in the outcome so far :P
21:04 lue FROGGS: care to see a gdb 'bt' output from my end?
21:04 FROGGS sure
21:04 FROGGS maybe a valgrind run would be helpful too
21:05 FROGGS you'd just need to invoke the failing line
21:06 lue FROGGS: it's in the gist now (it would *appear* the libuv is the culprit, but don't trust my interpretations :P)
21:07 FROGGS lue: that is just about the uv_loop_delete... the main problem is the parser error though
21:09 FROGGS that is what gdb won't show
21:12 lue valgrind <build command> sure takes a while :)
21:20 lue FROGGS: gist updated with probably unhelpful memcheck results
21:22 FROGGS :(
21:23 lue could this possibly be an issue with stage0 nqp?
21:25 FROGGS I can't tell
21:28 lue As a note, that offending line is the only one in the originating file that does InstructionList.new([$sigil-var] ...
21:28 lue I don't think that would be significant though :/
21:34 colomon joined #moarvm
21:44 FROGGS I have no such line O.o
21:44 FROGGS lue: what file+line exactly?
21:45 lue src/vm/moar/QASTCompilerMAST.nqp
21:45 lue :1241
21:45 lue (the build output should show the gen'd file location)
21:45 FROGGS nqp/src/vm/moar/QAST/QASTCompilerMAST.nqp:1241:        MAST::InstructionList.new([$node], MAST::VOID, $MVM_reg_void)
21:46 lue that's the one
21:46 jnthn lue: It's highly likely that you're looking at a GC bug...
21:46 FROGGS there is no $sigil-var
21:46 lue FROGGS: sigil-var is a placeholder name :)
21:46 FROGGS bah!
21:46 FROGGS don't do that while repoting a bug!
21:46 FROGGS NO PHANTASIE PERMITTED :P
21:47 FROGGS jnthn: true, sadly valgrind was useless
21:47 lue I meant originally that it's the only line to use the IL.new([$variable] ... format (with others using a similar IL.new([Node.new()] ... format)
21:48 lue FROGGS: that was just memcheck though, i.e. sticking `valgrind' in front of the command.
21:48 FROGGS that is what I wanted, yes
21:50 lue not even the "re-run with --leak-check=full" bit was used! :)
21:50 lue [it should be noted for completeness' sake that the valgrind output I posted is only what occurs immediately after moar fails, which incidentally is the only interesting part.]
21:50 FROGGS nah, I dont think it will help
21:51 FROGGS as long as we operate in fromspace/tospace (even by accident), we are still in our memory area
21:51 jnthn Right.
21:52 lue jnthn: if it is in fact a GC bug, any setting I can fiddle with in the MoarVM build process to give it more memory space or something?
21:57 jnthn The nursery size collect.h is what determines how "often" collections happen
22:03 lue jnthn: I'll halve the nursery size and see how it goes with NQP.
22:04 jnthn .oO( Well, that doubles the risk... )
22:06 lue oh. I thought the goal was to force it to do something more often.
22:07 * lue doubles the original size instead :)
22:07 jnthn lue: Well, it depends if you want to explore the problem or hide the problem ;)
22:08 lue jnthn: I'm not sure how making it more likely to happen helps figure it out, for me at least :)
22:14 lue bah, size doubling fails anyway :/
22:15 jnthn In the same place?
22:16 lue jnthn: yes
22:16 jnthn you certainly make install'd the change?
22:17 jnthn Does a factor of 1.5 help?
22:17 lue jnthn: yes, I hit make install (and even reconfig'd in nqp). I'll reduce the change from x2 to x1.5 and see what happens though.
22:21 lue gah, nope. I'm starting to think the nursery isn't the issue (unless you'd like me to x10 the original amount :P)
22:22 jnthn Hm, indeed.
22:34 lue jnthn: I decided to add a preceding line saying "my @a := [$node];" and use @a in the next line, **and I got the exact same error!** can't find final ')' and everything!
22:34 * lue &
22:37 lue (to clarify: even the line number is the same, despite that number belonging to the my @a line)
22:40 FROGGS hmmm
22:40 FROGGS I'd add more blank lines, so that at the given line number is nothing
22:41 FROGGS this file gets installed by moarvm btw
22:55 BenGoldberg joined #moarvm
22:59 lue FROGGS: still the exact same error, which means I'm a moron who doesn't realize how significant the "method_def" part of the error is: it has nothing to do with the file being compiled!
22:59 lue FROGGS: re-look at the "at " line of moar's backtrace: "  at gen/moar/stage2/NQPHLL.nqp:371  (src/vm/moar/stage0/NQPHLL.moarvm:panic:108)"
23:02 lue it is a stage0 problem after all, if that's to be believed.
23:02 lue (Either that or somehow stage2 stuff is being touched during/before stage1 stuff, which seems a whole 'nother issue in that case)
23:10 lue FROGGS, jnthn: could this be a slightly-too-outdated stage0 in NQP? (or was it, say, just updated 2 days ago?)
23:47 lue I would try to generate a new stage0 myself, but, well... :)

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary