01:30 colomon joined 02:01 woosley joined 02:15 colomon joined 03:06 colomon joined 03:12 woosley joined 03:13 colomon joined 03:50 ssutch joined 04:17 colomon joined 04:20 ggoebel17 joined
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
Is this a common-ish thing to run into?
(I see -fPIC flags here and there in the top-level makefile, so I'm not entirely sure what's happening.) 05:35
Ah, it appears linenoise is provided precompiled (and I'm not well-versed in re-creating an .a file, alas :/) 05:39
(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:43
Or this is just me not using --static and seeing no good reason to :) . 05:55
TimToady don't ask me--I just work here 05:57
kind of a night-time janitor who doesn't actually ever clean anything 05:58
more of a night-watchman, I guess 06:00
lue TimToady: I'm hoping somebody in a few hours will read the above and offer a solution. :) 06:01
TimToady well, I supposed it's a good thing that we make different kinds of trouble from each other :) 06:02
*pose 06:03
FROGGS lue: make realclean in MoarVM, reconfigure and rebuild 06:17
then rebuild at least rakudo
07:37 colomon joined 07:55 FROGGS joined
FROGGS morning 07:56
08:04 colomon joined 08:41 colomon joined 09:54 ssutch joined
jnthn morning 09:57
moritz moarning, jnthn 10:00
nwc10 morning 10:41
I get to this, which I assume is what you expect:
p6store NYI
Unhandled exception: Malformed UTF-8 at line 1 col 57 at gen/moar/stage2/NQPHLL.nqp:1219 (/home/nicholas/Sandpit/moar-g/languages/
...
jnthn The p6store bit, yes. The Malfmormed UTF-8 is a little worrying, though... 10:43
Memory corruption?
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
Mearning it's a bunch less efficient than it should be...
Though if you bottleneck on creating backtrace strings, you have a weird program :D
nwc10 I'll see if valgrind throws up anything
(chug chug chug) 11:11
diakopter jnthn: you're a backtrace string 11:47
(glug glug glug) 11:48
jnthn diakopter: Mostly, I was just too lazy to refactor the code :)
diakopter :) 11:49
FROGGS who needs to refactor anyway when there is a perfect design in the first place :P 11:50
11:52 tgt joined
dalek arVM: 436c194 | (Tobias Leich)++ | src/strings/utf8.c:
memset to zero so we can search for \0 safely
 12:06
FROGGS nwc10: ^^
jnthn ah, good catch 12:08
nwc10 FROGGS: working on it. I suspect it will take 60 minutes 13:38
take the computer, that is
FROGGS ahh 13:39
nwc10 single thread for the yawn.
FROGGS I was slightly shocked :o)
nwc10 it took bloody ages to run the the main parse under valgrind
jnthn I can't imagine... 13:40
FROGGS yeah, that sounds like valgrind :o)
14:15 odc joined
nwc10 FROGGS: fixes that one. 14:51
real 58m41.077s
user 58m27.594s
sys 0m6.880s
FROGGS cool
nwc10 one remaining valgrind error - I don't think that it's related: 14:52
paste.scsys.co.uk/280278
jnthn: paste.scsys.co.uk/280278 might be relevant - it might be a real failure to ROOT issue. Or might not.
FROGGS hmmm
nwc10 actually, "Address 0x3f92fbe8 is 8 bytes before a block of size 32 free'd" is not a message I've seen previously
FROGGS ummm 14:54
we are pushing a null pointer here... github.com/MoarVM/MoarVM/blob/mast...rgs.c#L424 14:55
jnthn FROGGS: No, we're not 14:56
FROGGS: We're pushign the address of a pointer that may be NULL
14:56 jnap joined
FROGGS true 14:56
phew
:o)
jnthn likes that many of the stack traces we see from C land are quite shallow :) 14:58
FROGGS yeah :o) 14:59
jnthn nwc10: That's a very weird error
3259 is in the exit opcode
oh, hang on...
MVMint64 exit_code = GET_REG(cur_op, 2).i64;
exit r(int64) 15:00
It should be GET_REG(cur_op, 0)
nwc10 point me at at patch, give me another 58+ minutes, and I can verify that :-)
jnthn That may well explain why we've seen weird issues where it doesn't stop building when there's a failure
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...
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)
jnthn: that would be a bad thing :-) 15:02
jnthn you don't say!
FROGGS hehe
dalek arVM: d5c9efe | jnthn++ | src/core/interp.c:
Fix exit op.

  nwc10++ for reporting issue, found thanks to valgrind++.		 15:03
jnthn nwc10: While you're having "fun" with JavaScript, my "fun" is with WPF... 15:08
At lesat I'm finding ways to amuse myself writing this stuff...
enum Unpets { Manatee, PolarBear, Babirusa }
moritz WPF has a nice short hamming distance to WTF 15:09
nwc10 WPF?
moritz windows presentation framework, I guess 15:10
s/framework/foundation/
jnthn Yes, that :)
And the distance to WTF is not lost on us.
Works for WCF too, which deserves it far, far more. 15:11
timotimo at least you don't have to touch MFC any more
jnthn Phew, yes :)
FROGGS hey, don't talk bad about MFC, it is almost as old as Perl :o) 15:24
(20 years by now)
diakopter com+++ 15:29
timotimo ole ole ... 15:31
15:37 eternaleye joined
nwc10 valgrind now clean 16:30
jnthn \o/
diakopter I always read that as vulgarind 16:31
jnthn You're vulgar/ind... 16:32
16:52 ssutch joined 16:59 FROGGS joined 17:14 eternaleye joined 18:05 eternaleye joined 19:09 FROGGS[mobile] joined
lue FROGGS: realclean doesn't help :/ 19:56
FROGGS hmm 19:57
you still get the -RPIC or -fPIC msg?
lue yep, still "recompile with -fPIC" on linenoise 19:58
FROGGS then delete the linenoise folder from 3rdparties, reconfigure and rebuild 19:59
you only need to `make` in rakudo afterwards, no need to touch nqp
jnthn If yo'v enothing valuable around, a git clean -fdx . may help
lue Eh, I just ran make realclean and then make and it worked. Somehow the intermediate "configure" step caused the problem?
FROGGS errm, no 20:00
after realclean you should not be able to make
(in theory)
lue OK, all of a sudden it works fine, and I have no clue why :/ 20:01
FROGGS yeah, no lue either :o) 20:03
lue but make realclean (some ls commands) make did work, which apparently it shouldn't've? 20:04
FROGGS normally realclean deletes the Makefile 20:05
maybe it does not do that (yet) for MoarVM
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:21
"Unable to parse expression in method_def; couldn't find final ')' at line 4403, near "MAST::Node"" to be precise 20:22
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.
FROGGS could well be 20:26
can you gist the version of moar and nqp-m together with you build output?
lue FROGGS: sure, just a minute 20:28
FROGGS cool
lue FROGGS: gist.github.com/lue/766f22eb0ac9f9c4c816 20:31
FROGGS lue: your --prefix points to the MoarVM repo? 20:35
lue FROGGS: yes, for the time being.
FROGGS k
I have no idea what is going on :/ 20:36
the assertion at the bottom is unrelated as you already said 20:37
(and it shows up because printing to stderr) 20:38
lue that's strange; none of my incredibly simple changes have made a dent in the outcome so far :P 20:53
FROGGS: care to see a gdb 'bt' output from my end? 21:04
FROGGS sure
maybe a valgrind run would be helpful too
you'd just need to invoke the failing line 21:05
lue FROGGS: it's in the gist now (it would *appear* the libuv is the culprit, but don't trust my interpretations :P) 21:06
FROGGS lue: that is just about the uv_loop_delete... the main problem is the parser error though 21:07
that is what gdb won't show 21:09
lue valgrind <build command> sure takes a while :) 21:12
FROGGS: gist updated with probably unhelpful memcheck results 21:20
FROGGS :( 21:22
lue could this possibly be an issue with stage0 nqp? 21:23
FROGGS I can't tell 21:25
lue As a note, that offending line is the only one in the originating file that does InstructionList.new([$sigil-var] ... 21:28
I don't think that would be significant though :/
21:34 colomon joined
FROGGS I have no such line O.o 21:44
lue: what file+line exactly?
lue src/vm/moar/QASTCompilerMAST.nqp 21:45
:1241
(the build output should show the gen'd file location)
FROGGS nqp/src/vm/moar/QAST/QASTCompilerMAST.nqp:1241: MAST::InstructionList.new([$node], MAST::VOID, $MVM_reg_void)
lue that's the one 21:46
jnthn lue: It's highly likely that you're looking at a GC bug...
FROGGS there is no $sigil-var
lue FROGGS: sigil-var is a placeholder name :)
FROGGS bah!
don't do that while repoting a bug!
NO PHANTASIE PERMITTED :P
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)
FROGGS: that was just memcheck though, i.e. sticking `valgrind' in front of the command. 21:48
FROGGS that is what I wanted, yes
lue not even the "re-run with --leak-check=full" bit was used! :) 21:50
[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.]
FROGGS nah, I dont think it will help
as long as we operate in fromspace/tospace (even by accident), we are still in our memory area 21:51
jnthn Right.
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:52
jnthn The nursery size collect.h is what determines how "often" collections happen 21:57
lue jnthn: I'll halve the nursery size and see how it goes with NQP. 22:03
jnthn
.oO( Well, that doubles the risk... )
 22:04
lue oh. I thought the goal was to force it to do something more often. 22:06
lue doubles the original size instead :) 22:07
jnthn lue: Well, it depends if you want to explore the problem or hide the problem ;)
lue jnthn: I'm not sure how making it more likely to happen helps figure it out, for me at least :) 22:08
bah, size doubling fails anyway :/ 22:14
jnthn In the same place? 22:15
lue jnthn: yes 22:16
jnthn you certainly make install'd the change?
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.
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:21
jnthn Hm, indeed. 22:22
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 &
(to clarify: even the line number is the same, despite that number belonging to the my @a line) 22:37
FROGGS hmmm 22:40
I'd add more blank lines, so that at the given line number is nothing
this file gets installed by moarvm btw 22:41
22:55 BenGoldberg joined
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
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)"
it is a stage0 problem after all, if that's to be believed. 23:02
(Either that or somehow stage2 stuff is being touched during/before stage1 stuff, which seems a whole 'nother issue in that case)
FROGGS, jnthn: could this be a slightly-too-outdated stage0 in NQP? (or was it, say, just updated 2 days ago?) 23:10
I would try to generate a new stage0 myself, but, well... :) 23:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!