github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 19 October 2013.
00:00 jnap joined 01:18 jnap joined
diakopter .. was supposed to be a pun on indirection 01:25
TimToady well, a pun on a pun is just another layer of misdirection... 01:33
diakopter gets confused by my own pun
TimToady think nothing of it 01:34
lue diakopter: then who wrote the pun? 02:04
TimToady Who did. 02:09
lue Who's Who? 02:21
TimToady Horton, I hear. 02:32
lue No, he *heard* a Who. So I guess my question then is Which Who? 02:38
02:59 benabik joined 06:15 dalek joined 07:07 FROGGS joined
FROGGS what branches are we on? master/master/moar-support? 08:06
nwc10 22:46 < jnthn> So we're back to moar-support/master/master for latest Rakudo on Moar progress 08:41
I think his list is reversed from yours 08:42
14:51 < jnthn> moritz: Currently, MoarVM master, NQP master, moar-support
should have pasted that one, as it's clearer
dalek arVM: 43ccbf0 | (Dagur Valberg Johannsson)++ | src/core/exceptions.c:
check if cur_frame is NULL
 09:01
arVM: 9429734 | jonathan++ | src/core/exceptions.c:
Merge pull request #61 from dagurval/crash-on-input

check if cur_frame is NULL
10:17 woolfy1 joined 10:25 woosley left
FROGGS nwc10: thank you 10:51
dalek arVM: 2ca897c | jnthn++ | / (5 files):
Re-order ops.

This is mostly aimed at bringing related things together, where they ended up scattered because it's typically easier to add things at the end. Also add a note that from now on, this order should be considered API, with new things to be added at the end.
The order is operationally unimportant; putting related things near to each other is simply a convenience for those working on the VM.		 11:47
arVM: 8a348d7 | jnthn++ | / (6 files):
Consistently use 32-bit string indexes.

d83796b | jnthn++ | src/6model/reprs/P6opaque.c: Handle auto_viv_container in P6opaque.compose.
FROGGS cool! 11:56
jnthn: sorry that I wasn't here yesterday, I felt (and feel) ill these days
jnthn FROGGS: Ugh...hope you feel better soon! 11:57
FROGGS: And no worries about not being about; I tend to figure stuff out :)
FROGGS yeah :/
jnthn: I know you do *g*
jnthn Given db75765 in nqp, nqp-cc's role in MoarVM's development is now over. 12:05
From it, we'll want to rescue t/moar
Preferably, creating ourselves a top-level test target. 12:06
diakopter jnthn: written in NQP I guess? 12:25
jnthn: er, NQP that's not generating MAST directly?
moritz imagines the hilarious circularity when MoarVM's Configure.pl gets a --gen-nqp option for running the tests 12:27
jnthn My idea is that we use an NQP script to generate .moarvm files 12:29
And then we check those in
moritz and then the test suite becomes super fast, because it doesn't even invole running NQP?
jnthn So you write the tests in an NQP file, but we only use that to generate the binaries 12:30
moritz (not that it was very slow before...)
diakopter moritz: "command line [or filename] too long: 'moar/nqp/moar/nqp/moar/nqp/moar/nqp/moar/nqp...'"
jnthn (when we want to update them)
And then 'make test' in MoarVM just runs those.
And yeah, it should be fast :)
Note that we don't write the tests in NQP in the sense of "they're NQP programs that need NQP"
Rather, we write them like t/moar is written today. It's just that the harness puts them into .moarvm files. 12:31
"harness"
moritz builder
jnthn Right
And then we have a make test-update or so
Or however it's most convenient to work. 12:32
moritz likes the plan 12:33
diakopter likes plans 12:34
jnthn: I updated to win 8.1 enterprise yesterday.. and no windows updates available last night. check again this morning... 7 available 12:37
jnthn whoa 12:40
[Coke] Belatedly: The answer to which who is either 10 or 4. 13:02
... someone needs to make me a deck of cards now. 13:03
13:37 benabik joined 13:52 jnap joined
jnthn Bad news. The BOOTSTRAP issue I have is a GC bug. 13:54
diakopter eek 13:55
bad news... FOR YOU!!! :D
jnthn :P
Well, it *looks* like we may be obtaining an outdated object pointer from an SC
diakopter (would be for me, except I'm ultra-busy right now) :( can't help atm, sorry :(
can't help other than irc wannabe-quips 13:56
.. which I realize are less-than-helpful 13:57
benabik GC bugs are annoying. One seems to have kept me from building nqp-m for some time.
benabik has no idea how to track it down. 13:58
diakopter benabik: they're quite tricky to track down, inversely related to how much of the code you wrote/touched
jnthn benabik: Yeah, they tend to have a huge track-down-time to fix-time ratio...
dalek arVM: 0ad1059 | jnthn++ | src/6model/reprs/SCRef. (2 files):
Toss dead code.
 13:59
benabik diakopter: Sadly, this one is more related to how much of the code other people have touched, which is roughly all of it. :-/ 14:00
jnthn The macro in src/gc/debug.h sometimes helps 14:03
benabik Okay, now segfaulting when trying to build nqp-m. That's exciting. Let's try pulling everything again... 14:25
That's odd. A panicking nqp-m stage0 doesn't stop the build. 14:30
Blub. '50' is not a valid number at line 2268, near ",\\n 34,\\n" 14:31
diakopter yeah 14:32
you'd think that one would be easy to track down, since it's so deterministic
benabik I hadn't noticed that the number doesn't match the line.
Oh, never mind. The 50 is on the line prior. 14:33
I made radix print out its results. I'm getting a lot of lines like "radix: [str, 2, 140352486814240]" 14:37
(str is a placeholder, not the string it's parsing)
I assume this indicates some variety of bug?
Oddly enough, nqp seems to think those indicate a correct result. 14:39
jnthn benabik: What's producing that output? 14:40
That is, where does the 3rd number come from? 14:41
benabik fprintf(stderr, "radix: [str, %"PRId64", %"PRId64"]\\n", base, pos);
radix returns the value, base, and pos.
This is just before it puts those values into the return array.
jnthn Sure yoru debug output is right? 14:42
benabik OH. Those are nuns, not integers.
jnthn base is a num, not an int
benabik But pos is an int.
jnthn yeah
benabik And that's the one coming back with bizzaro values.
jnthn But are you printing it unsigned when it's signed?
benabik pos is a MVMint64 14:43
jnthn right
benabik Which is signed, no?
jnthn Signed, yeah
benabik PRId64 is signed, PRIu64 is unsigned.
jnthn It starts as -1 and has offset assigned to it 14:44
So curious to know what offset is also 14:45
benabik Huh. Switching from PRId64 to lld fixed it. 14:46
PRIu64 should print a int64. :-( *sigh*
radix: [50.000000, 100.000000, 2] '50' is not a valid number at line 2268, near ",\\n 34,\\n" 14:47
benabik sighs.
jnthn What if you dump nqp::atpos($res, 2) and nqp::chars($src) ? 14:48
(edit HLL::Actions to do it)
oh, though depends if you are getting far enough into the bootstrap to do so I guess... 14:49
benabik Nope, this is building stage1... I guess I could see if nqp-cc gets me the same thing.
Oh, it won't because it's not on moar.
jnthn right
Hmm
benabik But I should be able to cc a new stage0?
(with the debugging)
jnthn hm, maybe 14:53
FROGGS huh: 15:18
--output=gen/moar/stage2/MASTOps.moarvm /home/froggs/dev/nqp/install/lib/MAST/Ops.nqp
String heap index beyond end of string heap
frame_name_55
somebody else has that too?
jnthn not here 15:19
You got up to date everything?
FROGGS yes, pull moarvm/master and nqp/master
I reconfigure and reinstall now just in case
diakopter [ot] new android update seems more responsive/speedier in a few places 15:20
FROGGS has balckberry -.-
err, blackberry*
benabik Huh. I added `~ nqp::atpos($res, 2) ~ " != " ~ nqp::chars($src))` to the panic in both nqp/src/HLL/Actions.pm and moar/nqp-cc/nqp-src/NQPHLL.nqp and it doesn't seem to the extra information.
FROGGS benabik: you made a new stage0 and copied the *.moarvm files to nqp's src/vm/moar/stage0? 15:21
benabik FROGGS: I only copied NQPHLLMoar.moarvm, but yes. 15:22
benabik will build the rest.
FROGGS jnthn: false alarm, after reconfiguring it works 15:25
as in: nqp builds
so, in nqp I can just do `perl Configure.pl --backends=moar` but in rakudo I have to specify the prefix? 15:26
benabik FROGGS++ 15:30
Helps if I copy all the files.
benabik was being too clever.
FROGGS I can't explain it, but it is good that it worked :o) 15:31
that is how it fails now in rakudo: 15:44
--vmlibs=dynext/libperl6_ops_moar.so=Rakudo_ops_init src/gen/m-BOOTSTRAP.nqp
failed to load library 'dynext/libperl6_ops_moar.so'
frame_name_0
jnthn FROGGS: Ok, then you get to debug that lib loading thingy on non-Windows ;-) 15:46
bah, you know you're having fun debugging when you have a watch on (MVMString *)(((char *)(*(MVMObject **)(((char *)(reg_base[*((MVMuint16 *)(cur_op + 2))].o->st->HOW)) + 80))) + 40)
diakopter hee 15:48
timotimo is unaware of an android update 15:52
diakopter timotimo: prob just Samsung
timotimo ah. maybe
i've got an lg with pretty-much-stock
a nexus, i should say
jnthn need a break; bbl 16:16
16:44 cognominal joined 17:20 jnap1 joined 17:48 FROGGS[mobile] joined
jnthn Seems it's a non-marking issue, or a gen2 freelist issue 17:52
diakopter guesses non-marking 17:55
the gen2 freelist is burned solidly in my brain...
jnthn I think I see a bug in it, though :) 17:56
Not in freelist management per se 17:57
17:57 lue joined
jnthn In else if (col->flags & MVM_CF_STABLE) { 17:57
diakopter oh
jnthn There's a copde-path like this:
/* Skip the freelist updating. */
continue;
diakopter istr adding that
jnthn But it doesn't actually advance the cur_ptr
meaning we immediately visit the collectable again, iiuc 17:58
And it's now marked as "should be freed"
diakopter WOW
nice find :)
jnthn I dunno if this is /the/ bug, but it's a bug ;)
diakopter my fav lines in MoarVM source code: 17:59
/* Chain in to the free list. */ *((char **)cur_ptr) = (char *)*freelist_insert_pos; *freelist_insert_pos = (char **)cur_ptr;
erm
/* Update the pointer to the insert position to point to us */ freelist_insert_pos = (char ***)cur_ptr;
those
dalek arVM: 5149557 | jnthn++ | src/gc/collect.c:
Fix delayed-by-1-run STable freeing in gen2.

We accidentally immediately re-considered the item, due not skipping the pointer increment.		 18:04
diakopter jnthn: so did it fix anything? :) 18:06
jnthn No :( 18:07
Well, probably something. But not the bug I'm chasing.
diakopter empathasizes strongly
18:10 FROGGS joined 18:23 dalek joined
jnthn Ok, it looks like it gets marked *and* ends up on the free list. 18:27
FROGGS that is how it is supposed to work, right? 18:28
jnthn No, if it's marked it's meant to, like, live. :P
FROGGS ahh, marked for living
jnthn right
FROGGS well, go on then :P 18:29
diakopter sometimes I wonder if I should be marked for living
FROGGS hehe 18:30
otherwise the great GC will collect you, ehh?
TimToady well, you could always become a tagger, and live for marking
FROGGS so, stovokor eq free_list?
jnthn Ah, ok, it's not so simple 18:33
It is marked in the 1st full run
It is *not* marked in the second full run.
And it's in that run that it's freelisted 18:34
So it's a "not getting marked" bug rather than a freelist management bug.
oh, that's an interesting thing 18:38
The object that references it isn't getting its mark cleared.
And it's big
I wonder if...
Darn, yeah, that's it... 18:40
We don't handle the overflows pool. 18:41
diakopter ohhhh
you know, I don't think I've read that code
jnthn I would so we don't handle it /properly/, but "jnthn forgot to ever implement proper handling of it" is more like the truth
D'oh
I just somehow assumed it was done. :)
TimToady nwc10 is asking for nqp/moar wisdom over <--
jnthn Well, or forgot about it... 18:42
TimToady (assuming moarvm.chan > perl6.chan) 18:44
nwc10 they are arranged that way in my irssi 18:45
diakopter too
tadzik same here
TimToady I can make mine go the other way, but only by turning my laptop upside-down... 18:47
FROGGS jnthn: my dlerror is: dynext/libperl6_ops_moar.so: undefined symbol: MVM_ext_register_extop 18:50
just for your info, don't wanna distract you :o)
tadzik IRC is for dIstRaCtion :P 18:52
FROGGS ahh yes, libmomar.s defines that symbol, so we just need to link to it
libmoar.a*
18:53 benabik joined
TimToady btw, if fudge adds .moarvm, is anyone going to get confused by other files using that extension to mean something else? 18:54
dalek arVM: e265d0d | jnthn++ | src/gc/ (2 files):
Implement handling of over-size gen2 objects.

The handling at collect time was missing, meaning that once marked in their first full run, they stayed marked forever. This meant gc_mark was never called, and anything they referenced was collected.		 18:56
benabik Uhm. That seems like a not-insignificant bug. jnthn++
timotimo except if there were never any over-size gen2 objects 18:57
jnthn Right, it's possible ClassHOW was one of the first things to trip it.
diakopter :D
jnthn A ClassHOW is bulky enough to be 336 bytes on a 64-bit machine.
benabik Landmines you haven't stepped on yet are still important. :-D
diakopter jnthn++ # how in the world did he track that one down...?
TimToady benabik: quick, send out the pigs, and plan for a big luau... 18:58
benabik TimToady: Right! I mean, how are you going to roast all those pigs in time for the party without landmines?
diakopter nwc10: oh yes. the bootstrap definitely needs updated, as the one Mouq merged stomped on jnthn's which was newer
jnthn diakopter: A lot of hutning but the thing that finally gave it away was when I put a data breakpoint on ->forwarder
diakopter jnthn: see my msg to nwc10 18:59
jnthn diakopter: And it was set, then never unset.
diakopter ^
jnthn: ah
cool
benabik And now nqp-m is building stage2... Stupid GC bugs. Adding debug information changed something enough to "fix" it.
jnthn Data breakpoints on forwarder pointers are REALLY quite useful, btw :)
diakopter jnthn: the bootstrap needs updated :)
jnthn diakopter: I, uh...what.
diakopter jnthn: Mouq's pull request overwrote your last one 19:00
jnthn Yes but I thought it contained an updated one that was newer than mine.
lemme look
diakopter oh.
hm
jnthn Yes, it looks correct
It must be an update based on the m-bootstrap-files target in the Makefile 19:01
'cus the filenames changed.
diakopter doesn't have time to try build from scratch..
diakopter looks at @others
(other than nwc10)
dalek arVM: e1b42ff | jnthn++ | src/core/interp.c:
Better error for unknown container spec.
jnthn Doing a clean build against latest Moar now 19:02
FROGGS jnthn: is it possible that we build a dynamic lib on windows, but only a static on linux? (I know the answer of the last part) 19:05
benabik Yay? nqp-m now seems to be building.
jnthn FROGGS: You have to --shared 19:06
FROGGS ahh, I remember
jnthn FROGGS: I think we should maybe default to that.
benabik I mean, yay building but I distrust GC bugs simply vanishing.
FROGGS yeah, seems wise :o)
benabik ohyaynewbug. "This type does not support elems\\nws" 19:07
jnthn Yeah, I don't think that's GC related though.
FROGGS ewww, --shared failed
jnthn I've just tried reverting one of my Moar patches I think may be to thank...
FROGGS: eww. I hope my patches to make it happy on Windows aren't to blame.
FROGGS we'll see
benabik I've been a bit hesitant to try --shared. It tends to be a bit tricky to to make dyld happy. 19:08
Might be easier now that I'm actually installing everything.
dalek arVM: 2e0147c | jnthn++ | src/6model/reprs/P6opaque.c:
Revert "Handle auto_viv_container in P6opaque.compose."

Breaks NQP. Need to look further into this at some point, but for now it's better to unbreak things.		 19:22
jnthn nwc10: ^^
nwc10 tests 19:26
dalek arVM: 786b435 | (Tobias Leich)++ | Configure.pl:
pass ccshared flags, to get -fPIC on linux
 19:34
FROGGS it compiles fine, but I need to tweak it now so that bin/moar finds the lib in lib/ 19:35
jnthn I had it shove the .dll in bin also :)
But such is Windows ;)
FROGGS I did the same right now, without luck 19:36
I guess it is looking in cwd only atm
benabik I think you need your lib/ in LD_LIBRARY_PATH 19:37
FROGGS yeah
I was thinking about LD_RUN_PATH, but you might be right
nwc10 sort of "works on my machine"
benabik I may be mangling the Linux and OS X env vars together. :-D 19:38
nwc10 t/nqp/67-container.t fails with a backtrace from glibc about an invalid free
FROGGS I think I need to set LD_LIBRARY_PATH while compiling, LD_RUN_PATH only has effect when running it, at least on openbsd
that is at least how I remember these things 19:39
jnthn nwc10: can I see the backtrace?
nwc10 paste.scsys.co.uk/273236 19:40
useful backtrace paste.scsys.co.uk/273237 19:41
see also paste.scsys.co.uk/273241 19:42
diakopter oh hm 19:44
FROGGS benabik: rpath is my friend now :o) 19:45
cl can handle -Wl,-rpath,DIR too, right? 19:48
ahh, I'll just test it 19:49
jnthn ohhhh...yeah, you don't free that on MoarVM, it's a static :) 19:50
nwc10 that would be a bug then? :-) 19:51
jnthn yeah. Dunno why we never hit it before 19:52
dalek arVM: 3502d9e | jnthn++ | src/6model/6model.c:
Fix container spec cleanup; nwc10++.
 19:54
jnthn nwc10: Should do it.
nwc10 testing
diakopter jnthn: oh lol; oops <- failer 19:55
(I think) 19:56
nwc10 All tests successful. 20:00
diakopter nice. 20:01
FROGGS okay, rakudo dies now: Unhandled exception: While looking for 'ModuleLoader.moarvm': no such file or directory
jnthn OK, that's now how it should die :) 20:02
FROGGS cool 20:03
jnthn argh
that's NOT how...
Should fail in BOOTSTRAP.nqp over rakudo_scalar not being implemented yet.
FROGGS I'll push the linux --shared fix in a sec
ohh :/
dalek arVM: 3628847 | (Tobias Leich)++ | Configure.pl:
set rpath so libmoar.lib on linux is found
 20:08
FROGGS err, libmoar.so
20:18 jnap joined 20:23 colomon joined
FROGGS jnthn: okay, on windows I get that, like you: Cannot use unknown container spec rakudo_scalar 20:33
I just wonder why it only searches for 'ModuleLoader.moarvm' on linux 20:34
does it want the one in blib/Perl6/ or the one in nqp?
and does it cd to that dir before?
might make sense to print the cwd I guess 20:35
jnthn Not sure which one it's after 20:37
NQP one or Perl 6 one
When does it fail?
Can you gist me the ubild log?
FROGGS gist.github.com/FROGGS/efdc9281f96...e1-txt-L36 20:38
jnthn FROGGS: Weird that it makes it so far 20:45
FROGGS: Given other things depend on ModuleLoader.moarvm I mean 20:55
20:57 BenGoldberg joined
FROGGS yeah... 21:01
I'll investigate tmw, I am a bit sleepy now
jnthn ok :) 21:03
timotimo too sleepy to event ype tomorrow out? wow, that's pretty sleepy 21:04
dalek arVM: 2a3f7bf | jnthn++ | src/ (2 files):
Add missing NULL checks for cont gc funcs.
 21:56
arVM: b43b8db | jnthn++ | src/ (4 files):
Add some more functions to the public API.
diakopter jnthn: you seem to be having fun today :) 21:57
jnthn diakopter: Well, only had a tiny number of $dayjob tasks and the odd vacation prep errand to distract me from stuff ;) 22:00
"Missing method cache; late-bound dispatch NYI" 22:07
...and this time it's for real and I will actually have to do the late-bound dispatch stuff :)
But, that can be for tomorrow. :)
BenGoldberg nqp-m: 1 22:08
camelia nqp-moarvm: OUTPUT«Unhandled exception: Bytecode segment overflows end of stream␤»
jnthn Means we get to line 1472 of BOOTSTRAP now, at least...
diakopter o_O 22:09
jnthn Still think we'll de starting to dig into the CORE.setting build by the end of October. :) 22:12
*be
diakopter I'll giggle when most of CORE.setting compiles within a day 22:13
tadzik wow, is it _that_ slow? :P 22:14
it took 2 minutes last time I checked...
timotimo haa haa :)
jnthn diakopter: It'll be similar to last time: really slow to get the first bit, then gradually less time per line. :) 22:15
jnthn gently reminds diakopter that ones of us is gonna have to implement continuations somewhere amongst all of this :) 22:16
I'm thinking of taking the test suite for the nqp:: continuation ops as used on JVM, doen by sorear++ 22:17
*done
Then we can have the same API :)
diakopter k 22:23
22:47 jnap joined 22:59 jnap joined 23:49 ssutch joined 23:55 FROGGS 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!