[Coke] tries a fresh run of rakudo.moar daily testing. 01:48
[Coke] ponders setting up a bench-style intermediate clone so doing the next daily run is that much quicker.
looks like the daily build box is now getting a ./perl6-m that can -e 'say 3' 02:19
(with lots of extra diag output). Hangs on spectests, though. 02:20
diakopter what.
WOW 02:21
[Coke]: thank you :)
02:36 diakopter joined 02:41 ssutch joined 02:50 diakopter joined
diakopter [Coke]: ping 02:56
[Coke]: I killed all your host06 things; crazy weirdness was occurring
03:09 _ilbot joined 03:24 ssutch joined 03:47 ssutch joined 03:56 cognominal joined 05:27 JimmyZ joined
nwc10 good *, #moarvm 07:24
diakopter O/ :) 07:29
08:15 ssutch joined
nwc10 jnthn: On a 64 bit linux system, I can't build NQP if I set the MoarVM nursery size to 320K. 348K is fine. 11:10
This command fails:
/home/nicholas/Sandpit/moar-g/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 --target=mbc --no-regex-lib --output=gen/moar/stage1/nqp.moarvm gen/moar/stage1/NQP.nqp
ctxlexpad needs an MVMContext 11:11
so I assume that this is a bug because something is not rooted
jnthn ooh 11:12
nwc10 er, I mean, 384K
with 256K there's a SEGV much earlier
I assume that it should all work, albeit very slowly, with small nursery sizes 11:13
jnthn Right.
So long as it's not smaller than the lagerst object we try to allocate
*largest
nwc10 and that bugs matter, because if things like deserialisation fail in NQP bootstrap because something in the deserialisation code fails to root 11:14
then they will also fail randomly in the runtime of any user code which tries to load something
jnthn Do you know it's load time?
nwc10 that question doesn't make enough sense to answer. 11:15
jnthn As in, deserialization time...
Ah, it's easier for me to reproduce it than ask. :) 11:16
jnthn sets nursery size to 327680K
nwc10: yay, I got that same error 11:21
FROGGS \o/ 11:31
13:27 tgt joined
nwc10 jnthn: I can't offer you this, but do you have access to a *nix system? (Something capable of mmap/mprotect/munmap) ? 13:51
jnthn: when building NQP, I believe that at line 16 of Lexotic.c, invokee is not rooted, and hence has ended up in fromspace 14:14
jnthn: paste.scsys.co.uk/285196 14:16
jnthn nwc10++ # great find! 14:18
nwc10 I'm going to mail perl6-compiler how I did it
jnthn
.oO( Not using the macro in src/gc/debug.h :) )
 14:19
nwc10 because, this won't be the last one. And I didn't even drop the nursery size
oh, far more evil than that
jnthn There's another vulnerability in there too 14:20
nwc10 OK. I'm not familiar enough with the code to spot them 14:30
let alone know the right way to fix them
(There's the "Cargo cult" way, but that's not helpful)
"my" machine doesn't have a new enough gcc for -g3, let alone ASAN 14:32
and not enough free space (yet) for me to built it locally
oh, sorry, patches are full of tabs. 14:33
nwc10 hopes that (eg) FROGGS will find it useful to get a handle on the handle problem 14:37
dalek arVM: 3149fda | jnthn++ | src/core/frame.c:
Unbust backtraces.
arVM: 3c8127f | jnthn++ | src/6model/reprs/Lexotic.c:
Fix two issues in Lexotic invoke found by nwc10++.

Missing rooting (refactored to avoid needing it) and also an object was on the args stack that could move.
nwc10 anway, dogs don't walk themselves
mmm, my fan club has just come up to wag at me...
jnthn nwc10++ 14:38
nwc10 manual debugging is tedious. I want to make the computer do it. :-)
jnthn Hopefully the patch I just pushed helps. 14:42
moritz nwc10++ 14:43
[Coke] diakopter: thanks. I had an infinite loop somewhere. 15:05
ok. now the spec test runs and fails (nearly?) every test with a lot of diagnostic output. 15:11
gist.github.com/coke/7974107
jnthn [Coke]: I'd guess it fails all of them given Test.pm doesn't build yet? 15:12
[Coke] very likely. I was just excited that I could run r-m a bit. 15:17
jnthn++ 15:24
15:43 timotimo joined
FROGGS sad, it still explodes in m-BOOTSTRAP using -O3 16:18
nwc10 FROGGS: if you can whack the moles that I indentify (or use the thing I sent to the list to whack moles locally) we might get there 16:19
FROGGS nwc10: I already saved your patches :o)
but I need to do a bit more v5 today, which includes writing the advent calender post for tomorrow :/ 16:20
nwc10 ah 16:22
16:52 tgt joined 17:49 colomon joined 18:04 colomon joined 19:11 colomon joined 19:14 dalek joined 19:57 colomon joined
timotimo nwc10: cool stuff! :) 20:04
i wonder what the error we get when trying to build Test.pm really means 20:09
jnthn timotimo: Run it with --ll-exception to find out 20:10
timotimo oh, P6opaque: no such attribute '$!filename'? 20:11
jnthn Innerestin'
timotimo it tries to access an $! in a role 20:12
in X::Comp
jnthn oh, could that just be that we're missing the attribute fix from nom?
timotimo perhaps
jnthn no, can't be 20:13
timotimo well, very likely actually
... oops?
jnthn Otherwise, how'd we have got code that relies on it merged?
timotimo did we actually get any working X::Comp based exceptions?
jnthn Don't think so
timotimo so we never hit that, except now when i asked for a --ll-exception 20:14
timotimo writes up an ugly hack to see how much further he gets 20:15
jnthn gets latest builds of stuff on his laptop
timotimo: Yeah, get the same error. Hmmm. 20:40
moritz ./perl6-m --ll-exception -e 'Path.new("/foo/")' 20:43
MVMArray: atpos expected string register at src/Perl6/World.nqp:2464 (blib/Perl6/World.moarvm:frame_name_679:35)
there is no atpos or [] around line 2464 :( 20:44
timotimo what's the way to dump moarvm bytecode? 20:45
can we figure out what frame_name_679:35 does?
jnthn The $!filename error is actually looking like it's 'cus the export trait failed somehow 20:46
timotimo mhm, good to know 20:47
jnthn That is, that's why it's trying to construct an exception.
timotimo i wasn't able to fix it by making it is rw and using $. access
jnthn No, it's some Real bug.
FROGGS timotimo: there is moar --dump perl6.moarvm ..., but that last time I tried it just exploded 20:48
jnthn I don't imagine the reason --dump explodes is very deep
It's probably just out of date with something 20:49
Seems to be a generic instantiation issue. 20:56
Or something like that.
nwc10 jnthn: I broke it again. Oops. :-) 20:58
jnthn nwc10: If your "how I broke it" report is as accurate as last time, I'm happy :) 20:59
nwc10 I had guessed at maybe 15 GC bugs lurking
but as 2047K found a bug, I wonder if it's more like 150
however, the problem looks tractable 21:00
we just keep whacking moles until no more show up
jnthn Unfortunately, few of the GC bugs are actually anywhere under src/gc/
nwc10 but we have a very stubbon automated whacker
jnthn They're code elsewhere breaking invariants.
nwc10 yes. 21:01
jnthn I can only say, thank heavens the tricky stuff (parser, MOP, compiler, etc) is written in something running *on* the VM, not inside the VM. :)
nwc10 yes. If you wanted Perl 5, you know where to find it :-) 21:02
moritz thought the same, but with s/Perl 5/Parrot/ :-)
jnthn Also, (automated whacking)++ :)
nwc10 moritz: I think your thought is more accurate. When Perl 5 was new, it didn't know any better 21:03
and I think it's partly down to Moore's Law that we can write stuff in high level code and not have to wait forever for it to run
as in: A Computer's Perspective on Moore's Law - Humans are getting more expensive at an exponential rate 21:05
from www.caplet.com/adages.html
21:19 colomon joined 21:42 cognominal joined
dalek arVM: 1811ddf | jonathan++ | src/gc/collect.c:
Eliminate unreachable code.
 21:46
arVM: bcdcaa3 | jonathan++ | src/core/frame.h:
Add frame ref-count inc/dec to public API.

Needed by Rakudo ext-ops.
jnthn nwc10++ # these bug reports are great 21:49
FROGGS: About? 21:52
FROGGS jnthn: what? 21:53
jnthn FROGGS: Rakudo sanity tests are still very sad under the debugger for me.
er
*junder the *harness*
Do you know what kind of I/O prove uses to get the results?
I get completely junk output... 21:54
(with -v)
t\01-sanity\10-say.t ............... 21:55
O U
No subtests run
By contrast, it actually captures the error backtraces...
ah, must be something with pipes... 21:56
FROGGS yeah, but I found nothing helpful when skimming through Test::Harness 21:57
jnthn C:\consulting\rakudo-moar>perl6-m -e "say 42" | more
O
Does it just happen on Windows?
FROGGS I can tell you in a few minutes... 21:58
jnthn C:\consulting\rakudo-moar>perl6-m -e "$*OUT.print('omg wtf bbq')" | more 22:00
ā•‘ā™„g wtf bbq
hmm...
FROGGS jnthn: is it a problem that we create the std handles that early? github.com/MoarVM/MoarVM/commit/35...9e155458fe 22:03
like, does it guess the stdout type at compile time of moarvm? 22:04
jnthn Well, I'd have rather we put that code outside of the 6model bootstrap, but it's happening in the right place, I think...
ooh, though, it happens before this: 22:05
/* get libuv default event loop. */
instance->default_loop = instance->main_thread->loop;
FROGGS ./perl6-m -e "say 42" | cat
42
22:05 colomon joined
jnthn Moving it for good measure but don't see it making a difference. 22:07
dalek arVM: 2eefa66 | jonathan++ | src/ (2 files):
Move standard handle setup to a better place.
 22:16
jnthn FROGGS: ooh... 22:17
body->u.handle->data = body;
It's that interior pointer thing... 22:18
FROGGS yeah, I am not sure I understand the approach of fixing it
well, I am sure I did not understand the proposed fix :/ 22:19
jnthn Hm, and I can't remember the proposed fix. D'oh! :) 22:22
FROGGS jnthn: you said something about hanging off the pointer we assign there another level away 22:24
jnthn Yeah, seeing if I can figure it... 22:31
Doesn't seem to help :( 22:32
FROGGS :(
dalek arVM: 0a28ddb | jonathan++ | src/ (2 files):
Try to eliminate OSHandle interior pointer use.

Doesn't seem to break anything, at least. Testing needed.		 22:33
jnthn I mean, it may well help something...
bah, I found it 22:47
FROGGS O.o 22:50
dalek arVM: 3122e83 | jonathan++ | src/io/fileops.c:
Enforce sync I/O when it's being assumed.

Not doing so was causing the string to write to get freed before it ever got written. With this, running tests under prove works reliably for Rakudo on Moar on Windows. Just got lucky on other OSes, I guess.
jnthn So, now I can see that we fail 6 of the sanity test files. 22:51
So we pass 23 - 6 = 17 of them. 22:52
FROGGS jnthn++ # !!
moar: 3rdparty/libuv/src/unix/stream.c:1452: uv_stream_set_blocking: Assertion `0 && "implement me"' failed. 22:54
a windows specifica :o)
diakopter hi
FROGGS hi diakopter 22:55
jnthn FROGGS: ugh, how'd you get that?
FROGGS jnthn: I just pulled, made install and went to my rakudo checkout and reconfigured
froggs@TL02L-R8RXTCW-linux:~/dev/MoarVM$ cd ../rakudo-moar/ 22:56
froggs@TL02L-R8RXTCW-linux:~/dev/rakudo-moar$ perl Configure.pl --backends=moar --prefix=../nqp/install --make-install
moar: 3rdparty/libuv/src/unix/stream.c:1452: uv_stream_set_blocking: Assertion `0 && "implement me"' failed.
like that
jnthn ugh...
FROGGS github.com/joyent/libuv/blob/maste...am.c#L1500 22:57
22:57 colomon joined
FROGGS NYI on linux 22:57
jnthn Oh, it only works on Windows?
FROGGS I suppose so
that is why it did not fail on my box
jnthn ok, mebbe for now I #ifdef WIN32 it. 22:58
And then we look into it further later.
FROGGS k
diakopter FUDGE
:)
jnthn TOFFEE
diakopter FROGGS: I no access the blog site 22:59
well, I didn't try this particular link
yeah, no access
dalek arVM: d3212c7 | jonathan++ | src/io/fileops.c:
Unbust non-Windows build.

Needs further investigation into what happens on other platforms.		 23:00
FROGGS diakopter: here gist.github.com/FROGGS/8ac40e7efed...langs.html
jnthn Teaching tomorrow, so gonna take some rest 23:05
Will take a look at the nwc10++ GC bug reports and other sanity tests tomorrow...feel free to beat me to it ;) 23:06
'night
TimToady o/ 23:07
FROGGS o/ 23:10
23:48 melnichuks joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!