Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2013-11-16

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

All times shown according to UTC.

Time Nick Message
08:04 FROGGS[mobile] joined #moarvm
08:08 cognominal joined #moarvm
09:08 cognominal joined #moarvm
11:08 ssutch_ joined #moarvm
11:36 woolfy1 joined #moarvm
11:36 lizmat_ joined #moarvm
12:06 tgt joined #moarvm
12:24 lue joined #moarvm
13:20 lizmat_ joined #moarvm
13:21 woolfy joined #moarvm
13:33 woolfy1 joined #moarvm
14:09 jnthn I think savecapture may be mishandling flattening...
14:16 FROGGS in interp.c or in MVM_args_proc_init?
14:16 jnthn Probably in interp.c
14:18 jnthn yeah, I think it's wrong.
14:20 jnthn It is. It pairs the flattened args with an unflattened call site.
14:23 FROGGS hmmm, I can only scratch my head when looking at that code :o)
14:26 jnthn bah, my first attempt to fix it was wrong too :)
14:29 FROGGS O.o
14:29 FROGGS jnthn: is that you?
14:29 jnthn D'oh, invokewithcapture is also wrong :)
14:30 jnthn Thing is, flatten_args does a mixture of mutable and immutable things.
14:31 FROGGS /o\ we are lost /o\
14:32 jnthn Yeah. This is a bit icky.
14:32 jnthn callsite points off to the original callsite,, so we still have that. But we no longer have the original args.
14:32 jnthn 'cus we flattened those in place.
14:33 FROGGS ahh, in place
14:34 FROGGS sounds like either super optimised or a bad idea :o)
14:34 jnthn And there's no MVMCallSite that represents the result of the flattening.
14:34 jnthn Well, we don't really wan to re-flatten...
14:34 jnthn *want
14:34 jnthn So we may as well re-use the work
14:35 jnthn Though the Easy Fix is to not do so...
14:36 jnthn An MVMCallSite has an arg_count, num_pos, and a set of flags
14:36 jnthn And a MVMCallSite does also...
14:37 jnthn oops, and an arg proc context does
15:10 dalek MoarVM: 98a32f0 | jnthn++ | src/ (3 files):
15:10 dalek MoarVM: Fix capture objects / flattening interaction.
15:10 dalek MoarVM:
15:10 dalek MoarVM: In the case flattening took place, we want to re-use the work, but we
15:10 dalek MoarVM: must have an MVMCallsite that describes the work. Otherwise, we use an
15:10 dalek MoarVM: out-of-date one, which confuses anything on receiving end of being
15:10 dalek MoarVM: invoked with the capture. Future simplifications are likely possible,
15:10 dalek MoarVM: but this moves things forward a step in getting Rakudo working.
15:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/98a32f07eb
15:13 FROGGS extension op 'p6isbindable' not registered # \o/
15:13 FROGGS jnthn++ # :o)
15:39 FROGGS ohh
15:39 FROGGS Program received signal SIGSEGV, Segmentation fault.
15:39 FROGGS 0x00007ffff79df4a6 in MVM_gc_root_add_gen2s_to_worklist (tc=0x6033c0, worklist=0x47ab900) at src/gc/roots.c:193
15:39 FROGGS 193            if (*cur_item_ptr && !((*cur_item_ptr)->flags & MVM_CF_SECOND_GEN)) {
15:39 FROGGS :o(
15:40 FROGGS #8  0x00007ffff799997a in MVM_args_slurpy_positional (tc=0x6033c0, ctx=0x4816988, pos=1) at src/core/args.c:400
15:40 jnthn How'd you get that?
15:41 FROGGS https://gist.github.com/FROGGS/365ffb89aa33b12ac65a
15:43 jnthn Weird
15:43 FROGGS jnthn: I'll reconfigure/reinstall moar/nqp/rakudo
15:57 FROGGS jnthn: still the same
15:58 FROGGS I guess we are missing an MVMROOT at src/core/args.c:400
16:05 FROGGS Positional parameter binding NYI
16:05 FROGGS \o/
16:05 jnthn \o/
16:05 jnthn That's the one I'm working on at the moment :)
16:05 FROGGS jnthn: I guess this is sane then? https://gist.github.com/FROGGS/83d27ce3d9c3b67f7753
16:06 nwc10 doesn't work on "my" machine - Rakudo build fails with:
16:06 nwc10 gcc: dynext/perl6_ops.o: No such file or directory
16:07 nwc10 command line is:
16:07 nwc10 gcc -c -fPIC -g  -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC  -O3  -I/home/nicholas/Sandpit/moar-g/include/libatomic_ops \ -I/home/nicholas/Sandpit/moar-g/include/dyncall -I/home/nicholas/Sandpit/moar-g/include/linenoise -I/home/nicholas/Sandpit/moar-g/include/moar \
16:07 jnthn FROGGS: I assume we use type later on, after the allocate?
16:07 nwc10 -I/home/nicholas/Sandpit/moar-g/iclude/sha1 -I/home/nicholas/Sandpit/moar-g/include/tinymt  -I/home/nicholas/Sandpit/moar-g/include/liabtommath \ -I/home/nicholas/Sandpit/moar-g/include/libuv -I/home/nicholas/Sandpit/moar-g/include dynext/perl6_ops.o src/vm/moar/ops/perl6_ops.c
16:07 nwc10 I think that that command line is missing an -o
16:09 FROGGS jnthn: yes, it is passes to box_slurpy
16:09 FROGGS hmmm
16:10 FROGGS nqp-m --show-config | grep "\-o"
16:10 FROGGS moar::ldout=-o
16:10 FROGGS nwc10: ^^ can you run that?
16:10 FROGGS nqp-m: say(nqp::backendconfig<ldout>)
16:10 camelia nqp-moarvm: OUTPUT«-o ␤»
16:11 FROGGS or that
16:11 jnthn FROGGS: Then, needed.
16:11 jnthn FROGGS++
16:11 FROGGS yay!
16:11 FROGGS :o)
16:12 timotimo \o/
16:12 timotimo always happy to see moarvm progress
16:12 nwc10 moar::ldout=-o
16:12 dalek MoarVM: 54ebe1d | (Tobias Leich)++ | src/core/args.c:
16:12 dalek MoarVM: gc_root type
16:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/54ebe1da65
16:12 FROGGS hmmm
16:13 FROGGS rakudo$ grep ldout tools/build/Makefile-Moar.in
16:13 FROGGS $(LD) @moar::ldswitch@ @moar::ldshared@ $(LDFLAGS) @moar::ldout@$(M_PERL6_OPS_DLL) $(M_PERL6_OPS_OBJ) $(M_PERL6_CONT_OBJ) @moarimplib@
16:13 FROGGS that is there too?
16:14 FROGGS if that is positive too, then you must have an outdated nqp or so
16:14 FROGGS nqp-m --version
16:14 FROGGS This is nqp version 2013.10-241-gfd308ad built on MoarVM version 2013.10-130-g98a32f0
16:14 nwc10 $(LD) @moar::ldswitch@ @moar::ldshared@ $(LDFLAGS) @moar::ldout@$(M_PERL6_OPS_DLL) $(M_PERL6_OPS_OBJ) $(M_PERL6_CONT_OBJ) @moarimplib@
16:14 FROGGS that is sort of HEAD
16:15 nwc10 $ ~/Sandpit/moar-g/bin/nqp-m --version
16:15 nwc10 This is nqp version 2013.10-241-gfd308ad built on MoarVM version 2013.10-130-g98a32f0
16:15 nwc10 Segmentation fault
16:15 FROGGS yeah, ignore the segfault...
16:15 FROGGS but
16:15 FROGGS hmmm
16:15 FROGGS is the -o in the Makefile ?
16:15 FROGGS I mean, can't be
16:17 FROGGS wait wait wait
16:17 FROGGS -I/home/froggs/dev/rakudo/../nqp/install/include/libuv -I/home/froggs/dev/rakudo/../nqp/install/include dynext/perl6_ops.o src/vm/moar/ops/perl6_ops.c
16:17 FROGGS gcc: warning: dynext/perl6_ops.o: linker input file unused because linking not done
16:17 nwc10 and if you remove that file? :-) I think that your build will then fail
16:17 FROGGS I think it has a problem with the missing space?
16:18 FROGGS jnthn had stripped the space to make it work on windows...
16:18 FROGGS but.... that wouldn't work either
16:20 nwc10 there are two lines after this line:
16:20 nwc10 $(M_PERL6_OPS_DLL): $(M_PERL6_OPS_SRC) $(M_PERL6_CONT_SRC) Makefile
16:20 nwc10 the first has no -o anywhere. The second does
16:20 nwc10 er, two command lines to invoke gcc
16:20 FROGGS I see it
16:21 FROGGS the first two stmts, which produce the .o use @moar::ccout@
16:21 FROGGS the third stmt actually creates a dll
16:21 FROGGS but only one, where we need two
16:22 FROGGS so, two errors
16:22 FROGGS nqp-m: say(nqp::backendconfig<ccout>)
16:22 camelia nqp-moarvm: OUTPUT«-o ␤»
16:26 FROGGS the %config's in Configure.pl do *not* contain ccout
16:26 FROGGS only ldout
16:36 lizmat joined #moarvm
16:36 woolfy joined #moarvm
16:37 FROGGS nwc10: it looks like nqp-m --show-config hides ccout
16:42 FROGGS <FROGGS> yeah, ignore the segfault... </HEADDESK>
16:46 FROGGS wow
16:46 FROGGS nqp-m --show-config | grep ar
16:46 FROGGS moar::ar=ar
16:46 FROGGS moar::cco
16:46 FROGGS there is something in that string...
16:47 FROGGS at least when printing it
16:47 FROGGS apparently not when accessing it via backendconfig
17:02 jnthn Turns out we never brought the associative API in line with the positional one
17:03 * jnthn is working on clearing that up now
17:26 * jnthn looks at box_slurpy in args.c and cries
17:26 jnthn This is EXACTLY the wrong use of abstraction :/
17:26 jnthn Making future changes a complete pain in the arse.
17:26 jnthn What should be a 2 minute code tweak will now take 10 minutes of understanding this shit...
17:27 jnthn ...and another couple of minutes wasted ranting on IRC about it... :)
17:35 TimToady well, at least the ranting part is fun...
17:45 FROGGS (good that I did not wrote this)
17:49 jnthn FROGGS: If you're ever tempted to put in a macro taking ~15 arguments, resist it :)
17:50 FROGGS err, yes
17:50 FROGGS :o)
17:55 moritz erm, wat?
17:58 dalek MoarVM: 3657daa | jnthn++ | src/ (15 files):
17:58 dalek MoarVM: REPR at_key_[boxed|ref] become at_key.
17:58 dalek MoarVM:
17:58 dalek MoarVM: We pass the result register and also the kind down. This brings at_key
17:58 dalek MoarVM: in line with at_pos. Some cleanups along the way, and MVMContext gets
17:58 dalek MoarVM: to start working with natives as a side-effect.
17:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3657daa19d
17:58 dalek MoarVM: 384ae2c | jnthn++ | src/6model/ (6 files):
17:58 dalek MoarVM: Toss bind_key_ref.
17:58 dalek MoarVM:
17:58 dalek MoarVM: Will use the generalized bind_key in its favor.
17:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/384ae2c845
17:58 jnthn Darn, it missed the third commit...
18:00 FROGGS yeah
18:00 FROGGS MoarVM$ LC_ALL=C make
18:00 FROGGS linking moar
18:00 FROGGS ./libmoar.so: undefined reference to `MVM_repr_bind_key_boxed'
18:00 jnthn FROGGS: huh...
18:00 jnthn Missing dependency?
18:01 FROGGS config.c uses that
18:01 dalek MoarVM: 020c732 | jnthn++ | src/6model/reprs/MVMContext.c:
18:01 dalek MoarVM: Implement MVMContext.bind_key.
18:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/020c732097
18:01 jnthn Hm...how'd I not get the error?
18:01 FROGGS dunno
18:01 jnthn oh, do you have to make clean to get it?
18:01 jnthn Or when is config.c generated?
18:02 FROGGS maybe you need to reconfigure to hit it
18:02 FROGGS when configuring
18:02 jnthn ah
18:02 jnthn yeah, that'd do it
18:02 jnthn yup
18:03 jnthn fixing
18:04 dalek MoarVM: 0e9e19a | jnthn++ | build/config.c.in:
18:04 dalek MoarVM: Update config.c.in with function name change.
18:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0e9e19a4e0
18:04 FROGGS jnthn+
18:04 FROGGS jnthn++
18:10 jnthn Time to shop, cook dinner, etc.
18:10 FROGGS ahhhaha
18:10 FROGGS I know why the ccout is not showing up correctly
18:11 FROGGS a funny thing atually
18:11 FROGGS actually*
18:11 FROGGS nqp-m --show-config > cfg.out
18:11 FROGGS ll cfg.out
18:11 FROGGS -rw-r--r-- 1 froggs froggs 8192 Nov 16 19:10 cfg.out
18:11 FROGGS and that cfg.out ends with: moar::cco
18:12 FROGGS (2**something)++
18:19 TimToady hahaha
18:19 * TimToady blames the GC for making it impossible to close files automatically :)
18:21 TimToady do we need an EXIT phaser?
18:21 TimToady oh, wait, we have one :)
18:22 TimToady (called END)
18:23 TimToady or maybe it's the language designer's fault for missing an important scoping mechanism somewhere... :)
18:23 TimToady we're kinda weak on transactional scopes...
18:24 TimToady file closing is kind of an autocommit if there has been no rollback transaction
18:31 TimToady maybe we just need some official RAII mechanism that requires user intervention to propagate ref-counted objects, and requires everyone with a ref to "close" it.
18:32 TimToady well, probably wrong channel for such speculatin'
18:34 TimToady but this whole idea of "doneness" seems rather fragmented
18:36 FROGGS the fh closing issue is kinda weird
18:36 TimToady the one you're looking at?
18:37 FROGGS because we're opening the std filehandles in the compiler and in the to-be-compiled code... and it is hard to know (for me) when it is safe to close it
18:37 TimToady maybe it's more of an fflush issue?
18:37 FROGGS well, I am not sure the "ccout-problem" is related to the std-filehandels-problem
18:37 FROGGS yeah
18:37 FROGGS probably
18:40 FROGGS nqp-m -e 'say(nqp::x("a", 10_000))' | wc
18:40 FROGGS 1       1   10001
18:40 FROGGS hmmm
18:40 TimToady that looks rightish
18:40 FROGGS it does
18:41 FROGGS nqp-m --show-config | wc
18:41 FROGGS 102     319    8192
18:41 FROGGS :/
18:41 TimToady that looks negatively rightish
18:44 FROGGS as if it behaves differently in the compiler
19:20 FROGGS okay, libuv has an output buffer of 8192
19:24 jnthn mebbe something is calling a write function and thinking it will write everything, when it only promises to write some of it:
19:24 jnthn ?
19:24 FROGGS no
19:24 FROGGS I hecked our say op
19:25 FROGGS and it does a fwrite, which writes all it gets
19:25 FROGGS I printed the the same string to stderr, and it comes out correctly, while the stdout-put is truncated when piping it
19:26 jnthn Don't forget to purgatory to print op...
19:27 jnthn *the
19:32 FROGGS I wat?
19:35 jnthn Was just punning on your typo :P
19:36 FROGGS which one? :P
19:36 FROGGS ahh, "which"
19:36 FROGGS no
19:37 FROGGS wat?
19:38 jnthn < FROGGS> I hecked our say op
19:39 FROGGS that bloody c
19:39 FROGGS err
19:39 FROGGS it seems that my brane is already turned off
19:39 jnthn haha
19:40 * FROGGS feels almost diakopterish :P
19:45 FROGGS hold on, it can't be libuv
19:45 FROGGS since we're just using fwrite
19:48 FROGGS Program received signal SIGSEGV, Segmentation fault.
19:48 FROGGS 0x00007ffff7a03cf7 in gc_free (tc=0x6033c0, obj=0x7ffff67e2910) at src/6model/reprs/MVMCallCapture.c:55
19:48 FROGGS 55    if (ctx->body.effective_callsite != ctx->body.apc->callsite)
19:49 FROGGS that happens at the end of nqp-m --show-config
19:49 FROGGS don't think it is related though
19:51 jnthn eek
19:51 jnthn Can you work out why it SEGVs? Is something null?
19:53 FROGGS https://gist.github.com/FROGGS/49b9270a8e216e05a46a
19:54 FROGGS not very helpful I guess
19:54 FROGGS I'll run valgrind
19:55 jnthn Hm, isn't it
19:55 jnthn p ctx->body.effective_callsite
19:55 jnthn To see what it is?
19:55 jnthn and p  ctx->body.apc
19:55 woolfy joined #moarvm
19:55 FROGGS https://gist.github.com/FROGGS/49b9270a8e216e05a46a#file-vg
19:55 FROGGS hold on
19:56 lizmat joined #moarvm
19:56 FROGGS 0x00007ffff7a03cf7 in gc_free (tc=0x6033c0, obj=0x7ffff67e2910) at src/6model/reprs/MVMCallCapture.c:55
19:56 FROGGS 55    if (ctx->body.effective_callsite != ctx->body.apc->callsite)
19:56 FROGGS (gdb) p ctx->body.effective_callsite
19:56 FROGGS $1 = (MVMCallsite *) 0x0
19:56 FROGGS p  ctx->body.apc
19:56 FROGGS $2 = (MVMArgProcContext *) 0x0
19:56 jnthn Hmm.
19:56 FROGGS p  ctx->body
19:56 FROGGS $3 = {apc = 0x0, effective_callsite = 0x0, mode = 0 '\000'}
19:57 jnthn I wonder how it gets like that...
19:57 jnthn I mean, we can avoid the segfault by checking ctx->body.apc ain't null.
19:59 FROGGS hmm
20:21 ssutch joined #moarvm
20:28 dalek MoarVM: c0779bd | jnthn++ | / (6 files):
20:28 dalek MoarVM: Provide a capturenamedshash op.
20:28 dalek MoarVM:
20:28 dalek MoarVM: Gets the names in a capture as a hash. Needed for Rakudo binder.
20:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c0779bdbd5
20:53 dalek MoarVM: 9e56dc1 | jnthn++ | src/core/frame.c:
20:53 dalek MoarVM: Don't uncoditionally trash ->caller on unwind.
20:53 dalek MoarVM:
20:53 dalek MoarVM: If an exception is thrown, ->origin points to the frame we threw from.
20:53 dalek MoarVM: If we tried to get the backtrace after the unwind happened, the caller
20:53 dalek MoarVM: chain was already trashed, even though ->origin ref'd the frame. Move
20:53 dalek MoarVM: clearing up the caller chain to frame ref-count decrement to avoid the
20:53 dalek MoarVM: problem.
20:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9e56dc1041
21:01 FROGGS ummm
21:02 FROGGS jnthn: that segfault in MVMCallCapture.c does trigger the ccout-issue
21:02 FROGGS (which is good actually)
21:02 jnthn oh...
21:02 FROGGS so I don't have to hunt two bugs :o)
21:02 jnthn Gimme a moment and I'll try the patch I thought of
21:02 FROGGS ohh, okay
21:02 jnthn (sorry, I sorta thought you were trying it, but looking back I had no reason to think you were...)
21:03 timotimo gcc: error: dynext/perl6_ops.o: No such file or directory
21:03 timotimo i'm not sure what's going on?
21:03 FROGGS jnthn: trying what? I tried to hunt down both issues
21:04 FROGGS timotimo: lay back, jnthn++ sorts it out :o)
21:04 timotimo dynext is apparently intentionally left blank?
21:04 FROGGS yes, because the configure script can't get the moar::ccout config var value
21:04 FROGGS because there is a segfault in gc_free of the callsite repr
21:04 FROGGS *g*
21:04 FROGGS what a weird thing, ehh?
21:06 timotimo o_O
21:06 timotimo yeah, i agree
21:29 dalek MoarVM: fe8d4bd | jnthn++ | src/core/exceptions.c:
21:29 dalek MoarVM: Give backtrace strings useful content.
21:29 dalek MoarVM:
21:29 dalek MoarVM: Line numbers/files, not just the routine name.
21:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fe8d4bd430
21:29 dalek MoarVM: 360af6c | jnthn++ | src/core/ (2 files):
21:29 dalek MoarVM: Fix corrupt index in first backtrace line.
21:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/360af6c2d0
21:30 dalek MoarVM: b9cbb62 | jnthn++ | src/6model/reprs/MVMCallCapture.c:
21:30 dalek MoarVM: Missing null check.
21:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b9cbb62780
21:42 jnthn FROGGS: Hopefully ^ makes things better
21:45 FROGGS jnthn++ # it works! \o/
21:46 timotimo so, er, what works now? can i try to compile again?
21:46 FROGGS yes
21:47 FROGGS rakudo should build again
21:47 timotimo oooh
21:47 FROGGS well, "build" :o)
21:47 FROGGS perl6_ops.so should be made
21:51 FROGGS yes!
21:51 FROGGS -o dynext/perl6_ops.o
21:51 FROGGS nwc10: ^^
21:54 FROGGS WARNING: nominal type check NYI
21:55 FROGGS I think that means "yay" :o)
21:57 timotimo "make m-install" starts java-related compilations :\
21:58 timotimo i'm not getting it to work, tbh (:
21:58 timotimo :(
21:59 FROGGS timotimo: do a --backends=moar
22:00 timotimo did that
22:00 FROGGS dunno why it clashes with jvm if you pass that too
22:00 timotimo in that case it doesn't any more
22:00 timotimo but the dynext is still not existing for me. oh well. not that important
22:19 jnthn Looks like we're at around line 359 into CORE.setting, fwiw
22:20 FROGGS wow
22:20 FROGGS I thought we are still at around line 50 :o)
22:21 jnthn We crash now in multi trait_mod:<is>(Routine:D $r, :$rw!) {
22:21 jnthn Which is first called from the "is rw" on  from line 359
22:24 jnthn Ah, yeah. And...now we get to the point where we start discovering containers :)
22:26 FROGGS hehe, right, we never had them before
22:28 FROGGS now you need to say that the jvm port was way more painful
22:29 FROGGS well, it is not really painful for me, I am just feeling totally useless :o)
22:34 jnthn FROGGS: One thing you could look at: I think make clean in Rakudo doesn't clear dynext up...
22:35 FROGGS k
22:36 FROGGS and I'll look at the thing timotimo reported (--backends=jvm,moar && make m-install will make jvm)
22:36 FROGGS but I'll do that tomorrow
23:21 dalek MoarVM: fedb647 | jnthn++ | src/core/bytecode.c:
23:21 dalek MoarVM: Correct bytecode sanity check.
23:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fedb647400
23:21 dalek MoarVM: 69cc214 | jnthn++ | src/core/bytecode.c:
23:21 dalek MoarVM: Fix annotations thinko.
23:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/69cc214ae8
23:21 dalek MoarVM: 6b678b1 | jnthn++ | src/ (4 files):
23:21 dalek MoarVM: Fix arg_flags lifetime wrt effective callsite.
23:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6b678b1f1f
23:23 FROGGS ohh, I get backtrace now instead of a segfault after the NYI
23:25 jnthn :)
23:26 FROGGS I like it :o)
23:37 FROGGS gnight jnthn o/
23:37 dalek MoarVM: ec52026 | jnthn++ | src/core/ (2 files):
23:37 dalek MoarVM: Tweak lexical lookup semantics.
23:37 dalek MoarVM:
23:37 dalek MoarVM: This brings them in line with what we need in Rakudo, though we may
23:37 dalek MoarVM: want to re-visit this across all backends in the future.
23:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ec52026027
23:37 jnthn Line 453
23:37 jnthn 'night, FROGGS
23:40 timotimo 'night jnthn :)
23:40 timotimo er
23:41 timotimo 'night FROGGS
23:41 jnthn Yes, I've some more beer + hack to go :)
23:41 timotimo that's nice to hear :)
23:42 jnthn Oh darn
23:42 jnthn I was wrong above.
23:42 jnthn It's more like 409
23:45 timotimo still a decent step from 359 before

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