Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-10-25

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

All times shown according to UTC.

Time Nick Message
00:00 jnap joined #moarvm
01:18 jnap joined #moarvm
01:25 diakopter .. was supposed to be a pun on indirection
01:33 TimToady well, a pun on a pun is just another layer of misdirection...
01:33 * diakopter gets confused by my own pun
01:34 TimToady think nothing of it
02:04 lue diakopter: then who wrote the pun?
02:09 TimToady Who did.
02:21 lue Who's Who?
02:32 TimToady Horton, I hear.
02:38 lue No, he *heard* a Who. So I guess my question then is Which Who?
02:59 benabik joined #moarvm
06:15 dalek joined #moarvm
07:07 FROGGS joined #moarvm
08:06 FROGGS what branches are we on? master/master/moar-support?
08:41 nwc10 22:46 < jnthn> So we're back to moar-support/master/master for latest Rakudo on  Moar progress
08:42 nwc10 I think his list is reversed from yours
08:42 nwc10 14:51 < jnthn> moritz: Currently, MoarVM master, NQP master, moar-support
08:42 nwc10 should have pasted that one, as it's clearer
09:01 dalek MoarVM: 43ccbf0 | (Dagur Valberg Johannsson)++ | src/core/exceptions.c:
09:01 dalek MoarVM: check if cur_frame is NULL
09:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/43ccbf09e5
09:01 dalek MoarVM: 9429734 | jonathan++ | src/core/exceptions.c:
09:01 dalek MoarVM: Merge pull request #61 from dagurval/crash-on-input
09:01 dalek MoarVM:
09:01 dalek MoarVM: check if cur_frame is NULL
09:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9429734d65
10:17 woolfy1 joined #moarvm
10:25 woosley left #moarvm
10:51 FROGGS nwc10: thank you
11:47 dalek MoarVM: 2ca897c | jnthn++ | / (5 files):
11:47 dalek MoarVM: Re-order ops.
11:47 dalek MoarVM:
11:47 dalek MoarVM: This is mostly aimed at bringing related things together, where they
11:47 dalek MoarVM: ended up scattered because it's typically easier to add things at the
11:47 dalek MoarVM: end. Also add a note that from now on, this order should be considered
11:47 dalek MoarVM: API, with new things to be added at the end.
11:47 dalek MoarVM:
11:47 dalek MoarVM: The order is operationally unimportant; putting related things near to
11:47 dalek MoarVM: each other is simply a convenience for those working on the VM.
11:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2ca897c809
11:47 dalek MoarVM: 8a348d7 | jnthn++ | / (6 files):
11:47 dalek MoarVM: Consistently use 32-bit string indexes.
11:47 dalek MoarVM:
11:56 FROGGS cool!
11:56 FROGGS jnthn: sorry that I wasn't here yesterday, I felt (and feel) ill these days
11:57 jnthn FROGGS: Ugh...hope you feel better soon!
11:57 jnthn FROGGS: And no worries about not being about; I tend to figure stuff out :)
11:57 FROGGS yeah :/
11:57 FROGGS jnthn: I know you do *g*
12:05 jnthn Given db75765 in nqp, nqp-cc's role in MoarVM's development is now over.
12:05 jnthn From it, we'll want to rescue t/moar
12:06 jnthn Preferably, creating ourselves a top-level test target.
12:25 diakopter jnthn: written in NQP I guess?
12:25 diakopter jnthn: er, NQP that's not generating MAST directly?
12:27 * moritz imagines the hilarious circularity when MoarVM's Configure.pl gets a --gen-nqp option for running the tests
12:29 jnthn My idea is that we use an NQP script to generate .moarvm files
12:29 jnthn And then we check those in
12:29 moritz and then the test suite becomes super fast, because it doesn't even invole running NQP?
12:30 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...)
12:30 diakopter moritz: "command line [or filename] too long: 'moar/nqp/moar/nqp/moar/nqp/moar/nqp/moar/nqp...'"
12:30 jnthn (when we want to update them)
12:30 jnthn And then 'make test' in MoarVM just runs those.
12:30 jnthn And yeah, it should be fast :)
12:30 jnthn Note that we don't write the tests in NQP in the sense of "they're NQP programs that need NQP"
12:31 jnthn Rather, we write them like t/moar is written today. It's just that the harness puts them into .moarvm files.
12:31 jnthn "harness"
12:31 moritz builder
12:31 jnthn Right
12:31 jnthn And then we have a make test-update or so
12:32 jnthn Or however it's most convenient to work.
12:33 * moritz likes the plan
12:34 * diakopter likes plans
12:37 diakopter jnthn: I updated to win 8.1 enterprise yesterday.. and no windows updates available last night. check again this morning... 7 available
12:40 jnthn whoa
13:02 [Coke] Belatedly: The answer to which who is either 10 or 4.
13:03 [Coke] ... someone needs to make me a deck of cards now.
13:18 dalek MoarVM: d83796b | jnthn++ | src/6model/reprs/P6opaque.c:
13:18 dalek MoarVM: Handle auto_viv_container in P6opaque.compose.
13:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d83796b9c3
13:37 benabik joined #moarvm
13:52 jnap joined #moarvm
13:54 jnthn Bad news. The BOOTSTRAP issue I have is a GC bug.
13:55 diakopter eek
13:55 diakopter bad news... FOR YOU!!! :D
13:55 jnthn :P
13:55 jnthn Well, it *looks* like we may be obtaining an outdated object pointer from an SC
13:55 diakopter (would be for me, except I'm ultra-busy right now) :(  can't help atm, sorry :(
13:56 diakopter can't help other than irc wannabe-quips
13:57 diakopter .. 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.
13:58 * 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
13:58 jnthn benabik: Yeah, they tend to have a huge track-down-time to fix-time ratio...
13:59 dalek MoarVM: 0ad1059 | jnthn++ | src/6model/reprs/SCRef. (2 files):
13:59 dalek MoarVM: Toss dead code.
13:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0ad1059141
14:00 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:03 jnthn The macro in src/gc/debug.h sometimes helps
14:25 benabik Okay, now segfaulting when trying to build nqp-m.  That's exciting.  Let's try pulling everything again...
14:30 benabik That's odd.  A panicking nqp-m stage0 doesn't stop the build.
14:31 benabik Blub.  '50' is not a valid number at line 2268, near ",\n    34,\n"
14:32 diakopter yeah
14:32 diakopter you'd think that one would be easy to track down, since it's so deterministic
14:32 benabik I hadn't noticed that the number doesn't match the line.
14:33 benabik Oh, never mind.  The 50 is on the line prior.
14:37 benabik I made radix print out its results.  I'm getting a lot of lines like "radix: [str, 2, 140352486814240]"
14:37 benabik (str is a placeholder, not the string it's parsing)
14:37 benabik I assume this indicates some variety of bug?
14:39 benabik Oddly enough, nqp seems to think those indicate a correct result.
14:40 jnthn benabik: What's producing that output?
14:41 jnthn That is, where does the 3rd number come from?
14:41 benabik fprintf(stderr, "radix: [str, %"PRId64", %"PRId64"]\n", base, pos);
14:41 benabik radix returns the value, base, and pos.
14:41 benabik This is just before it puts those values into the return array.
14:42 jnthn Sure yoru debug output is right?
14:42 benabik OH.  Those are nuns, not integers.
14:42 jnthn base is a num, not an int
14:42 benabik But pos is an int.
14:42 jnthn yeah
14:42 benabik And that's the one coming back with bizzaro values.
14:42 jnthn But are you printing it unsigned when it's signed?
14:43 benabik pos is  a MVMint64
14:43 jnthn right
14:43 benabik Which is signed, no?
14:43 jnthn Signed, yeah
14:43 benabik PRId64 is signed, PRIu64 is unsigned.
14:44 jnthn It starts as -1 and has offset assigned to it
14:45 jnthn So curious to know what offset is also
14:46 benabik Huh.  Switching from PRId64 to lld fixed it.
14:46 benabik PRIu64 should print a int64.  :-(  *sigh*
14:47 benabik radix: [50.000000, 100.000000, 2] '50' is not a valid number at line 2268, near ",\n    34,\n"
14:47 * benabik sighs.
14:48 jnthn What if you dump nqp::atpos($res, 2) and nqp::chars($src) ?
14:48 jnthn (edit HLL::Actions to do it)
14:49 jnthn 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.
14:49 benabik Oh, it won't because it's not on moar.
14:49 jnthn right
14:49 jnthn Hmm
14:49 benabik But I should be able to cc a new stage0?
14:49 benabik (with the debugging)
14:53 jnthn hm, maybe
15:18 FROGGS huh:
15:18 FROGGS --output=gen/moar/stage2/MASTOps.moarvm /home/froggs/dev/nqp/install/lib/MAST/Ops.nqp
15:18 FROGGS String heap index beyond end of string heap
15:18 FROGGS frame_name_55
15:18 FROGGS somebody else has that too?
15:19 jnthn not here
15:19 jnthn You got up to date everything?
15:19 FROGGS yes, pull moarvm/master and nqp/master
15:19 FROGGS I reconfigure and reinstall now just in case
15:20 diakopter [ot] new android update seems more responsive/speedier in a few places
15:20 * FROGGS has balckberry -.-
15:20 FROGGS err, blackberry*
15:20 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.
15:21 FROGGS benabik: you made a new stage0 and copied the *.moarvm files to nqp's src/vm/moar/stage0?
15:22 benabik FROGGS: I only copied NQPHLLMoar.moarvm, but yes.
15:22 * benabik will build the rest.
15:25 FROGGS jnthn: false alarm, after reconfiguring it works
15:25 FROGGS as in: nqp builds
15:26 FROGGS so, in nqp I can just do `perl Configure.pl --backends=moar` but in rakudo I have to specify the prefix?
15:30 benabik FROGGS++
15:30 benabik Helps if I copy all the files.
15:30 * benabik was being too clever.
15:31 FROGGS I can't explain it, but it is good that it worked :o)
15:44 FROGGS that is how it fails now in rakudo:
15:44 FROGGS --vmlibs=dynext/libperl6_o​ps_moar.so=Rakudo_ops_init src/gen/m-BOOTSTRAP.nqp
15:44 FROGGS failed to load library 'dynext/libperl6_ops_moar.so'
15:44 FROGGS frame_name_0
15:46 jnthn FROGGS: Ok, then you get to debug that lib loading thingy on non-Windows ;-)
15:46 jnthn 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)
15:48 diakopter hee
15:52 * timotimo is unaware of an android update
15:52 diakopter timotimo: prob just Samsung
15:52 timotimo ah. maybe
15:52 timotimo i've got an lg with pretty-much-stock
15:52 timotimo a nexus, i should say
16:16 jnthn need a break; bbl
16:44 cognominal joined #moarvm
17:20 jnap1 joined #moarvm
17:48 FROGGS[mobile] joined #moarvm
17:52 jnthn Seems it's a non-marking issue, or a gen2 freelist issue
17:55 * diakopter guesses non-marking
17:55 diakopter the gen2 freelist is burned solidly in my brain...
17:56 jnthn I think I see a bug in it, though :)
17:57 jnthn Not in freelist management per se
17:57 lue joined #moarvm
17:57 jnthn In else if (col->flags & MVM_CF_STABLE) {
17:57 diakopter oh
17:57 jnthn There's a copde-path like this:
17:57 jnthn /* Skip the freelist updating. */
17:57 jnthn continue;
17:57 diakopter istr adding that
17:57 jnthn But it doesn't actually advance the cur_ptr
17:58 jnthn meaning we immediately visit the collectable again, iiuc
17:58 jnthn And it's now marked as "should be freed"
17:58 diakopter WOW
17:58 diakopter nice find :)
17:58 jnthn I dunno if this is /the/ bug, but it's a bug ;)
17:59 diakopter my fav lines in MoarVM source code:
17:59 diakopter /* Chain in to the free list. */ *((char **)cur_ptr) = (char *)*freelist_insert_pos; *freelist_insert_pos = (char **)cur_ptr;
17:59 diakopter erm
17:59 diakopter /* Update the pointer to the insert position to point to us */ freelist_insert_pos = (char ***)cur_ptr;
17:59 diakopter those
18:04 dalek MoarVM: 5149557 | jnthn++ | src/gc/collect.c:
18:04 dalek MoarVM: Fix delayed-by-1-run STable freeing in gen2.
18:04 dalek MoarVM:
18:04 dalek MoarVM: We accidentally immediately re-considered the item, due not skipping
18:04 dalek MoarVM: the pointer increment.
18:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5149557720
18:06 diakopter jnthn: so did it fix anything? :)
18:07 jnthn No :(
18:07 jnthn Well, probably something. But not the bug I'm chasing.
18:07 * diakopter empathasizes strongly
18:10 FROGGS joined #moarvm
18:23 dalek joined #moarvm
18:27 jnthn Ok, it looks like it gets marked *and* ends up on the free list.
18:28 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
18:28 FROGGS ahh, marked for living
18:28 jnthn right
18:29 FROGGS well, go on then :P
18:29 diakopter sometimes I wonder if I should be marked for living
18:30 FROGGS hehe
18:30 FROGGS otherwise the great GC will collect you, ehh?
18:30 TimToady well, you could always become a tagger, and live for marking
18:30 FROGGS so, stovokor eq free_list?
18:33 jnthn Ah, ok, it's not so simple
18:33 jnthn It is marked in the 1st full run
18:33 jnthn It is *not* marked in the second full run.
18:34 jnthn And it's in that run that it's freelisted
18:34 jnthn So it's a "not getting marked" bug rather than a freelist management bug.
18:38 jnthn oh, that's an interesting thing
18:38 jnthn The object that references it isn't getting its mark cleared.
18:38 jnthn And it's big
18:38 jnthn I wonder if...
18:40 jnthn Darn, yeah, that's it...
18:41 jnthn We don't handle the overflows pool.
18:41 diakopter ohhhh
18:41 diakopter you know, I don't think I've read that code
18:41 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
18:41 jnthn D'oh
18:41 jnthn I just somehow assumed it was done. :)
18:41 TimToady nwc10 is asking for nqp/moar wisdom over <--
18:42 jnthn Well, or forgot about it...
18:44 TimToady (assuming moarvm.chan > perl6.chan)
18:45 nwc10 they are arranged that way in my irssi
18:45 * diakopter too
18:45 tadzik same here
18:47 TimToady I can make mine go the other way, but only by turning my laptop upside-down...
18:50 FROGGS jnthn: my dlerror is: dynext/libperl6_ops_moar.so: undefined symbol: MVM_ext_register_extop
18:50 FROGGS just for your info, don't wanna distract you :o)
18:52 tadzik IRC is for dIstRaCtion :P
18:52 FROGGS ahh yes, libmomar.s defines that symbol, so we just need to link to it
18:52 FROGGS libmoar.a*
18:53 benabik joined #moarvm
18:54 TimToady btw, if fudge adds .moarvm, is anyone going to get confused by other files using that extension to mean something else?
18:56 dalek MoarVM: e265d0d | jnthn++ | src/gc/ (2 files):
18:56 dalek MoarVM: Implement handling of over-size gen2 objects.
18:56 dalek MoarVM:
18:56 dalek MoarVM: The handling at collect time was missing, meaning that once marked in
18:56 dalek MoarVM: their first full run, they stayed marked forever. This meant gc_mark
18:56 dalek MoarVM: was never called, and anything they referenced was collected.
18:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e265d0dbb9
18:56 benabik Uhm.  That seems like a not-insignificant bug.  jnthn++
18:57 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.
18:57 diakopter :D
18:57 jnthn A ClassHOW is bulky enough to be 336 bytes on a 64-bit machine.
18:57 benabik Landmines you haven't stepped on yet are still important.  :-D
18:57 diakopter jnthn++ # how in the world did he track that one down...?
18:58 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?
18:58 diakopter nwc10: oh yes. the bootstrap definitely needs updated, as the one Mouq merged stomped on jnthn's which was newer
18:58 jnthn diakopter: A lot of hutning but the thing that finally gave it away was when I put a data breakpoint on ->forwarder
18:59 diakopter jnthn: see my msg to nwc10
18:59 jnthn diakopter: And it was set, then never unset.
18:59 diakopter ^
18:59 diakopter jnthn: ah
18:59 diakopter cool
18:59 benabik And now nqp-m is building stage2...  Stupid GC bugs.  Adding debug information changed something enough to "fix" it.
18:59 jnthn Data breakpoints on forwarder pointers are REALLY quite useful, btw :)
18:59 diakopter jnthn: the bootstrap needs updated :)
18:59 jnthn diakopter: I, uh...what.
19:00 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.
19:00 jnthn lemme look
19:00 diakopter oh.
19:00 diakopter hm
19:00 jnthn Yes, it looks correct
19:01 jnthn It must be an update based on the m-bootstrap-files target in the Makefile
19:01 jnthn 'cus the filenames changed.
19:01 * diakopter doesn't have time to try build from scratch..
19:01 * diakopter looks at @others
19:01 diakopter (other than nwc10)
19:01 dalek MoarVM: e1b42ff | jnthn++ | src/core/interp.c:
19:01 dalek MoarVM: Better error for unknown container spec.
19:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e1b42ffbc1
19:02 jnthn Doing a clean build against latest Moar now
19:05 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.
19:06 jnthn FROGGS: You have to --shared
19:06 FROGGS ahh, I remember
19:06 jnthn FROGGS: I think we should maybe default to that.
19:06 benabik I mean, yay building but I distrust GC bugs simply vanishing.
19:06 FROGGS yeah, seems wise :o)
19:07 benabik ohyaynewbug.  "This type does not support elems\nws"
19:07 jnthn Yeah, I don't think that's GC related though.
19:07 FROGGS ewww, --shared failed
19:07 jnthn I've just tried reverting one of my Moar patches I think may be to thank...
19:07 jnthn FROGGS: eww. I hope my patches to make it happy on Windows aren't to blame.
19:07 FROGGS we'll see
19:08 benabik I've been a bit hesitant to try --shared.  It tends to be a bit tricky to to make dyld happy.
19:08 benabik Might be easier now that I'm actually installing everything.
19:22 dalek MoarVM: 2e0147c | jnthn++ | src/6model/reprs/P6opaque.c:
19:22 dalek MoarVM: Revert "Handle auto_viv_container in P6opaque.compose."
19:22 dalek MoarVM:
19:22 dalek MoarVM: Breaks NQP. Need to look further into this at some point, but for
19:22 dalek MoarVM: now it's better to unbreak things.
19:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2e0147c92f
19:22 jnthn nwc10: ^^
19:26 * nwc10 tests
19:34 dalek MoarVM: 786b435 | (Tobias Leich)++ | Configure.pl:
19:34 dalek MoarVM: pass ccshared flags, to get -fPIC on linux
19:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/786b435c38
19:35 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 :)
19:35 jnthn But such is Windows ;)
19:36 FROGGS I did the same right now, without luck
19:36 FROGGS I guess it is looking in cwd only atm
19:37 benabik I think you need your lib/ in LD_LIBRARY_PATH
19:37 FROGGS yeah
19:37 FROGGS I was thinking about LD_RUN_PATH, but you might be right
19:37 nwc10 sort of "works on my machine"
19:38 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
19:38 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
19:39 FROGGS that is at least how I remember these things
19:39 jnthn nwc10: can I see the backtrace?
19:40 nwc10 http://paste.scsys.co.uk/273236
19:41 nwc10 useful backtrace http://paste.scsys.co.uk/273237
19:42 nwc10 see also http://paste.scsys.co.uk/273241
19:44 diakopter oh hm
19:45 FROGGS benabik: rpath is my friend now :o)
19:48 FROGGS cl can handle -Wl,-rpath,DIR too, right?
19:49 FROGGS ahh, I'll just test it
19:50 jnthn ohhhh...yeah, you don't free that on MoarVM, it's a static :)
19:51 nwc10 that would be a bug then? :-)
19:52 jnthn yeah. Dunno why we never hit it before
19:54 dalek MoarVM: 3502d9e | jnthn++ | src/6model/6model.c:
19:54 dalek MoarVM: Fix container spec cleanup; nwc10++.
19:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3502d9ea77
19:54 jnthn nwc10: Should do it.
19:54 nwc10 testing
19:55 diakopter jnthn: oh lol; oops <- failer
19:56 diakopter (I think)
20:00 nwc10 All tests successful.
20:01 diakopter nice.
20:01 FROGGS okay, rakudo dies now: Unhandled exception: While looking for 'ModuleLoader.moarvm': no such file or directory
20:02 jnthn OK, that's now how it should die :)
20:03 FROGGS cool
20:03 jnthn argh
20:03 jnthn that's NOT how...
20:03 jnthn Should fail in BOOTSTRAP.nqp over rakudo_scalar not being implemented yet.
20:03 FROGGS I'll push the linux --shared fix in a sec
20:03 FROGGS ohh :/
20:08 dalek MoarVM: 3628847 | (Tobias Leich)++ | Configure.pl:
20:08 dalek MoarVM: set rpath so libmoar.lib on linux is found
20:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3628847e34
20:08 FROGGS err, libmoar.so
20:18 jnap joined #moarvm
20:23 colomon joined #moarvm
20:33 FROGGS jnthn: okay, on windows I get that, like you: Cannot use unknown container spec rakudo_scalar
20:34 FROGGS I just wonder why it only searches for 'ModuleLoader.moarvm' on linux
20:34 FROGGS does it want the one in blib/Perl6/ or the one in nqp?
20:34 FROGGS and does it cd to that dir before?
20:35 FROGGS might make sense to print the cwd I guess
20:37 jnthn Not sure which one it's after
20:37 jnthn NQP one or Perl 6 one
20:37 jnthn When does it fail?
20:37 jnthn Can you gist me the ubild log?
20:38 FROGGS https://gist.github.com/FROGGS/efdc92​81f96dd6a82b8c#file-gistfile1-txt-L36
20:45 jnthn FROGGS: Weird that it makes it so far
20:55 jnthn FROGGS: Given other things depend on ModuleLoader.moarvm I mean
20:57 BenGoldberg joined #moarvm
21:01 FROGGS yeah...
21:01 FROGGS I'll investigate tmw, I am a bit sleepy now
21:03 jnthn ok :)
21:04 timotimo too sleepy to event ype tomorrow out? wow, that's pretty sleepy
21:56 dalek MoarVM: 2a3f7bf | jnthn++ | src/ (2 files):
21:56 dalek MoarVM: Add missing NULL checks for cont gc funcs.
21:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2a3f7bf317
21:56 dalek MoarVM: b43b8db | jnthn++ | src/ (4 files):
21:56 dalek MoarVM: Add some more functions to the public API.
21:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b43b8dbe6d
21:57 diakopter jnthn: you seem to be having fun today :)
22:00 jnthn diakopter: Well, only had a tiny number of $dayjob tasks and the odd vacation prep errand to distract me from stuff ;)
22:07 jnthn "Missing method cache; late-bound dispatch NYI"
22:07 jnthn ...and this time it's for real and I will actually have to do the late-bound dispatch stuff :)
22:07 jnthn But, that can be for tomorrow. :)
22:08 BenGoldberg nqp-m: 1
22:08 camelia nqp-moarvm: OUTPUT«Unhandled exception: Bytecode segment overflows end of stream␤»
22:08 jnthn Means we get to line 1472 of BOOTSTRAP now, at least...
22:09 diakopter o_O
22:12 jnthn Still think we'll de starting to dig into the CORE.setting build by the end of October. :)
22:12 jnthn *be
22:13 diakopter I'll giggle when most of CORE.setting compiles within a day
22:14 tadzik wow, is it _that_ slow? :P
22:14 tadzik it took 2 minutes last time I checked...
22:14 timotimo haa haa :)
22:15 jnthn diakopter: It'll be similar to last time: really slow to get the first bit, then gradually less time per line. :)
22:16 * jnthn gently reminds diakopter that ones of us is gonna have to implement continuations somewhere amongst all of this :)
22:17 jnthn I'm thinking of taking the test suite for the nqp:: continuation ops as used on JVM, doen by sorear++
22:17 jnthn *done
22:17 jnthn Then we can have the same API :)
22:23 diakopter k
22:47 jnap joined #moarvm
22:59 jnap joined #moarvm
23:49 ssutch joined #moarvm
23:55 FROGGS joined #moarvm

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