Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-04-10

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:24 brrt joined #moarvm
04:24 brrt good * #moarvm
04:25 samcv hey brrt
04:25 samcv i have appimages working for rakudo star :)
04:25 samcv would you like to try it
04:25 brrt appimages? hang on.. i'm not sure I'm that far awake
04:26 brrt what's an appimage?
04:26 samcv it's like a binary that's self contained
04:26 samcv only one file. and you can +x and then run it
04:26 samcv no install required
04:26 brrt oh, that's pretty cool
04:26 brrt is that for linux?
04:27 samcv ye
04:27 brrt aw
04:27 samcv what do you have
04:27 brrt i'm on OS-X
04:27 samcv ah ok
04:27 samcv well so far it's working great. all the modules in rakudo star work
04:28 samcv and got -I lib working right, and got giving it relative directories
04:28 brrt i have a bunch of linux VM's available to me
04:28 brrt srsly? did you make them? how?
04:28 brrt i'm very impressed
04:28 brrt we've been wanting single binary installs for …. years
04:29 samcv 10MB
04:29 samcv ok here's the dl https://cry.nu/files/org.perl6.rakudo-x86_64.AppImage
04:29 samcv 2017.01 rakudo star
04:30 samcv well. so we compile in hard directories for moarvm and .moar bytcode and a ton of places
04:31 brrt cool
04:31 brrt i'm on a slow network
04:31 samcv once you install it somewhere you have to replace all occurances of the old directory with a relative one that is the same length
04:31 samcv so installed in /rsu and replaced that with ././
04:31 samcv something like that
04:32 samcv the documentation could be better
04:32 samcv doesn't even tell you how to install it... though i found some travis ci scripts and reverse engineered them so i could figure out wtf i had to do to get this working
04:33 brrt pretty cool :-)
04:33 samcv just uploaded the source files here https://github.com/samcv/rakudo-appimage the script doesn't fully work yet. but it's partially working
04:34 samcv yeah :-)
04:34 samcv i hate bad documentation. it could have been so much easier if they just said a few things
04:34 brrt hehehe
04:35 brrt stuff would be great if it didn't suck :-P
04:35 samcv the whole thing was like trying to sell you on how easy it was, but didn't tell you how to do it
04:35 samcv like oh you basically just do this and then and then hey! appimages are awesome
04:35 brrt hehe
04:36 samcv like didn't tell me i had to install into $DIRECTORY and then, i had to move them to a folder called usr
04:36 samcv that would be too easy if it said that
04:37 samcv and all the paths are off, and not good
04:38 samcv oh also i had to learn about all the ENV vars by dumping every env var
04:38 samcv and create directories with weird names, then cding into that directory, and then grepping all the ENV vars
04:38 samcv heh
04:39 samcv so basicaly the perl6 shell scripty cd's into the folder that's in this one ENV var. then processes all ARGS, ignoring ones with a dash, and ones without a dash, finds the absolute path of them. then cd's back into the original directory, and passes on the new args
04:39 samcv which have full paths
04:56 brrt uhuh
05:05 samcv hmm we don't seem to have any checksums on rakudo.org for rakudo star
05:08 brrt i'm vaguely aware of that, yes
05:17 domidumont joined #moarvm
05:22 domidumont joined #moarvm
05:26 brrt joined #moarvm
05:42 domidumont joined #moarvm
05:55 brrt ugh, i think i've found my bug… :-(
05:59 brrt (but why!!!!)
06:21 spebern joined #moarvm
06:23 brrt yay, found the answer
06:29 samcv argh travis
06:36 domidumont1 joined #moarvm
06:44 brrt joined #moarvm
07:21 domidumont joined #moarvm
07:45 Geth ¦ MoarVM/even-moar-jit: ddc94d9141 | (Bart Wiegmans)++ | src/jit/linear_scan.c
07:45 Geth ¦ MoarVM/even-moar-jit: Fix off-by-one in DO live range determination
07:45 Geth ¦ MoarVM/even-moar-jit:
07:45 Geth ¦ MoarVM/even-moar-jit: The first node of the DO list construct is the number of children,
07:45 Geth ¦ MoarVM/even-moar-jit: so the index of the last children reference is the index of the DO
07:45 Geth ¦ MoarVM/even-moar-jit: node, plus one, plus the number of children.
07:45 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ddc94d9141
07:45 Geth ¦ MoarVM/even-moar-jit: 7fb1b1011f | (Bart Wiegmans)++ | 2 files
07:45 Geth ¦ MoarVM/even-moar-jit: Rewrite 'LET' syntactic form to DO blocks
07:45 Geth ¦ MoarVM/even-moar-jit:
07:45 Geth ¦ MoarVM/even-moar-jit: The compiler for template 'expressions' supports 'let' expressions to
07:45 Geth ¦ MoarVM/even-moar-jit: declare a variable and construct more complex expression graphs than
07:45 Geth ¦ MoarVM/even-moar-jit: simple trees. To ensure that any declarations in the let block are
07:45 Geth ¦ MoarVM/even-moar-jit: available in its associated expression, the declarations should
07:45 Geth ¦ MoarVM/even-moar-jit: compiled before the expression is.
07:45 Geth ¦ MoarVM/even-moar-jit: <…commit message has 15 more lines…>
07:45 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7fb1b1011f
07:45 Geth ¦ MoarVM/even-moar-jit: 46b117fa0f | (Bart Wiegmans)++ | src/jit/expr.c
07:46 Geth ¦ MoarVM/even-moar-jit: Remove redundant and dangerous 'rooting' construct
07:46 Geth ¦ MoarVM/even-moar-jit:
07:46 Geth ¦ MoarVM/even-moar-jit: Templates used to be able to enforce the 'rooting' of certain nodes
07:46 Geth ¦ MoarVM/even-moar-jit: so that they'd be compiled in a certain order; a feature that was used
07:46 Geth ¦ MoarVM/even-moar-jit: only for LET declarations. As LET declarations now compile via DO blocks
07:46 Geth ¦ MoarVM/even-moar-jit: instead, this is no longer necessary.
07:46 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/46b117fa0f
07:46 samcv brrt, you merged right. i never did run a coverage test for you
07:46 brrt i did
07:46 samcv k. will generate for you
07:51 brrt so, i think the above is pretty cool, because it means you can use let expressions in e.g. macros, conditionals, etc.
07:51 brrt and it will do the expected thing
08:02 samcv your commit?
08:03 brrt yeah
08:12 samcv brrt, so that pl script creates the other file there?
08:17 brrt eh, which other file are we talking about?
08:19 samcv https://github.com/MoarVM/MoarVM/commit/7fb1b1011ff51487e0935fdbbf853900f52f55bc
08:19 samcv the template thing creates which files
08:21 brrt oh, right
08:21 brrt so
08:21 brrt we have a list of template definitins in src/jit/core.expr
08:21 brrt they map moarvm opcodes to expression templates
08:22 brrt the template compiler converts that to a binary (actually, static integer array) format that can be easily processed by the JIT into trees
08:22 samcv here's your coverage https://cry.nu/coverage/even-moar-jit/libmoar/
08:22 brrt ouch, the printf shouldn't have gone in
08:23 samcv happens to the best of us
08:23 samcv i almost always do git add -p so i can review all the things.
08:23 samcv also helps me write a better commit message usually
08:23 Geth ¦ MoarVM/even-moar-jit: c3648238fc | (Bart Wiegmans)++ | 2 files
08:23 Geth ¦ MoarVM/even-moar-jit: Remove debugging output, reorganize plan a bit
08:23 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c3648238fc
08:24 brrt i'm using magit actually :-) should've seen it
08:24 samcv magit?
08:25 samcv hope the coverage gives some insights. very interesting stuff
08:27 brrt mostly a bunch of assertions
08:27 brrt that don't work
08:27 brrt i should get that story cleaned up, as well
08:28 brrt ANY is clearly currently not yet used
08:28 brrt interesting stuff samcv, very helpful
08:28 brrt https://magit.vc/
08:29 samcv no problem :)
08:52 brrt ehm, i'm wondering if even-moar-jit is out of date again
08:52 brrt cause i can't compile rakudo correctly?
08:53 samcv dunno
08:53 samcv is it missing an op?
09:10 Ven joined #moarvm
09:22 brrt maybe....
09:22 brrt not sensitive to spesh
09:22 brrt let me check
09:26 zakharyas joined #moarvm
09:27 brrt git is not merging nicely :-(
09:37 Ven_ joined #moarvm
09:46 Ven_ joined #moarvm
10:27 Ven joined #moarvm
10:45 Ven_ joined #moarvm
11:15 Ven_ joined #moarvm
11:28 brrt i don't know what did it, but rakudo compiles again on even-moar-jit, so yay
11:30 brrt samcv; ehm, ....
11:30 brrt would you consider using a for loop in this commit: 9b9b1b5ec680833ba844953ae7bdd51c68327bdb
11:32 timotimo a for loop can't replicate a do/while, can it?
11:32 Geth ¦ MoarVM/even-moar-jit: 30 commits pushed by (Zoffix Znet)++, (Samantha McVey)++, (Jonathan Worthington)++, (Timo Paulssen)++, timo++, (Bart Wiegmans)++
11:32 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/compare/c3648238fc...2dd7a1127d
11:32 brrt you can do a bunch of things if you're creative
11:32 brrt hmm, not sure if i'm asking for the right thing, now :-)
11:32 timotimo huh.
11:33 timotimo trying to checkout that branch gives me a bunch of files in my working copy that "would be overwritten"
11:33 timotimo src/jit/linear_scan.c
11:33 timotimo src/jit/x64/tiles.list
11:33 timotimo tools/expr-template-compiler.pl
11:33 timotimo tools/tiler-table-generator.pl
11:33 timotimo how did i end up with these loose in my working copy, i wonder
11:33 brrt i dunno
11:34 timotimo oh, i still had to fast-forward on the branch itself
11:34 timotimo expr_ops.h gives me a warning a bunch of times; backslash-newline at end of file
11:37 timotimo i have no idea what i'm looking at in the jit graphs :D
11:37 timotimo a do with a discard is like a void-return-value do node?
11:38 timotimo hm. there's an add node that has a do-node with a discard in one of its operands
11:41 timotimo Build tree out of: [null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, ]
11:41 timotimo i bet we make real good machine code for this :D
11:44 nwc10 I can't check the sound on this, but I assume that it's appropriate: https://www.youtube.com/watch?v=M_eYSuPKP3Y
11:45 timotimo heh.
11:45 timotimo brrt: we can only callv so far, right? no call-with-return-value?
11:46 brrt indeed
11:46 timotimo right
11:47 timotimo i just sorted the list of "could not get" outputs and wval was really high up in there :)
11:47 brrt a discard takes a register value and converts it into void; it makes the value 'tileable'
11:47 brrt i'm wondering if it'd be a reasonable idea to put wvals in our data segment
11:48 timotimo they can't change, but they *can* be "not yet resolved"
11:48 timotimo so that might be problematic perhaps?
11:48 brrt well, i can enforce resolving?
11:49 timotimo same reason we now refuse to inline stuff when it'd cause a wval to have to be deserialized
11:49 timotimo are you allowed to hold mutexes in the jit?
11:49 timotimo like, safe-point-wise?
11:49 brrt honestly, no idea
11:50 brrt no better than spesh, i presume
11:50 timotimo i think it comes down to "did you write a whole bunch of "mark" functions for all datastructures that might point at some MVMCollectable?
11:50 timotimo "
11:55 Ven joined #moarvm
11:55 brrt no
11:55 brrt but
11:55 brrt the jit doesn't use any MVMCollectable structures
11:56 timotimo well, that could be good, then
11:56 brrt but, i don't understand why it can't be done in inlining
11:56 timotimo well, if we cause an object to be deserialized, we have to take the lock for sc stuff
11:56 brrt so that makes me suspicious if it's safe to do in the jit
11:57 timotimo that means we'll be blocked and another thread might start doing gc for us
11:57 timotimo right now spesh will prevent gc from happening while it's doing a single thing
12:01 geekosaur joined #moarvm
12:10 brrt hmmm
12:10 brrt well, the alternative is just to insert the call
12:11 timotimo one thing about spesh is we play it really loose with the memory management
12:11 timotimo right
12:11 timotimo but that call requires a return value :D
12:11 brrt hush, you'll wake up the rusk evangeism task force
12:12 timotimo the what now o_O
12:13 brrt well, the group of people who have been trampling over themselves to tell others they should use Memory Safe Languages, particularly if they have a strong type system, no GC, an LLVM-based compiler, and a hipster cult following
12:14 timotimo oh
12:14 timotimo are they against functions with return values? :)
12:15 brrt no, they're not
12:15 brrt but i'd suspect that 'playing it really loose with the memory managment' would set a few bells riniging
12:15 timotimo oh
12:15 timotimo i see
12:16 timotimo well, that's just how we allocate and "deallocate" memory in spesh :)
12:16 Ven_ joined #moarvm
12:21 domidumont joined #moarvm
12:25 timotimo "Furthermore, at least on Red Hat, glibc regularly whacks around the behavior of OS-native collations in minor releases, which effectively corrupts PostgreSQL's indexes, since the index order might no longer match the (revised) collation order."
12:25 timotimo wow.
12:30 timotimo brrt: i wonder why we get a "cannot get template for *" before and after each graph dump?
12:38 AlexDaniel joined #moarvm
12:39 brrt yeah, i read that too
12:39 brrt that's because the template compiler tries to make a graph until it can't anymore
12:39 brrt and the usual reason it can't make a graph is tbecause the template is not yet available
12:41 brrt and the template is not available, because, either i didn't implement it yet, or it uses some feature that doesn't work yet
12:42 timotimo timo@schmand ~/p/moarvm (even-moar-jit)> perl6 tools/expr-template-compiler.pl
12:42 timotimo ===SORRY!===
12:42 timotimo Attempt to unlock mutex by thread not holding it
12:42 timotimo yikes!
12:42 timotimo yeah, i know :)
12:42 timotimo but why does it output it twice?
12:45 timotimo hm, so i tried to add a template
12:45 timotimo and it compiles
12:45 timotimo but it doesn't prevent any "couldn't get template for myop"
12:45 timotimo (macro: ^cu_callsite (,a) (idx  (^getf (cu) MVMCompUnit body.callsites) ,a ptr_sz))
12:45 timotimo (template: prepargs (^setf (^getf (tc) MVMThreadContext cur_frame) MVMFrame cur_args_callsite
12:45 timotimo (^cu_callsite $0)))
12:45 timotimo does that look about right?
12:48 timotimo { &MVM_jit_expr_templates[285], "..l..l..l...l..l..lf..ll.", 25, 21, 0 },
12:48 zakharyas joined #moarvm
12:48 timotimo this is how it shows up in the expr tables
12:50 Ven_ joined #moarvm
12:51 timotimo oh, did i forget "make install"?
12:51 timotimo Can't add constant for operand type 13  -  so i've implemented the template wrong. a step up from not having it at all :)
12:56 timotimo i don't see anything obvious wrong ... ^cu_callsite is almost a 1:1 copy of ^cu_string, which accesses a field that looks the same, i.e. MVMString **strings vs MVMCallsite **callsites
12:58 timotimo huh. for the exploding program, prepargs doesn't even show up in the jitlog? i wonder why.
13:09 brrt joined #moarvm
13:10 brrt hang on
13:13 brrt joined #moarvm
13:13 brrt so, i'm back
13:13 brrt okay, so, the expr compiler is not a perl6 program
13:14 brrt :-)
13:14 brrt that's the first bit
13:15 brrt so, what did you write and add
13:15 brrt alltogether
13:15 brrt ah, i see
13:16 Ven joined #moarvm
13:30 timotimo did i wronged?
13:31 brrt not sure
13:32 brrt i don't have time directly to look into it too much
13:32 timotimo ah, OK
13:32 timotimo i'll drop it for now, then
13:34 brrt could you stash it in a gist? i'll debug what's happening then
13:34 brrt would also help me in figuring out how to improve the ergonomics of the process
13:34 brrt :-)
13:35 timotimo sure
13:37 timotimo https://gist.github.com/timo/3ac9a97cbaf710d0d13a13eb27f6c504 - brrt's gist for future reference
13:38 brrt does cu_string macro actually work, i wonder
13:40 timotimo if it doesn't that could explain what's going wrong ;)
13:41 timotimo i have a graph here that has it in it, but i don't know how to properly verify
13:41 timotimo http://imgur.com/a/mhCIG
13:43 brrt it looks reasonable enough at first site
13:43 brrt *sight
13:44 brrt the const is somewhat large, though...
13:47 timotimo how do i read this format ...
13:47 timotimo okay so MVMObject itself is 24 bytes big
13:48 timotimo inside of MVMCompUnitBody, the offset of "strings" seems to be 80
13:48 timotimo m: say 0x2c9
13:48 camelia rakudo-moar 10fe02: OUTPUT: «713␤»
13:48 timotimo hm
13:49 brrt so the cheap thing to do is to add a printf and check the number we're adding :-)
13:50 timotimo where does that go?
13:51 timotimo m: say (80 + 24).base(16)
13:51 camelia rakudo-moar 10fe02: OUTPUT: «68␤»
13:51 timotimo it seems i was looking at the wrong thing
13:52 timotimo addr(0x68) -> cu is definitely right for the strings field
13:54 timotimo of course the spesh log doesn't tell me what the index of a literal string is
13:54 timotimo because that's otherwise a useless information
13:55 brrt that should go… let me check
13:55 timotimo const_s          r49(9), lits(exact_invocant)
13:55 timotimo const_i64_16     r50(3), liti16(1)
13:55 timotimo hllboxtype_i    r28(23)
13:55 timotimo that's the piece of code we're compiling here
13:56 brrt okay
13:56 brrt is that not working?
13:57 brrt src/jit/expr.c line 182, below MVM_operand_str
13:57 brrt that's where you want to printf the lit_str_idx
13:58 timotimo well, the program runs just fine
13:58 timotimo this is inside the code for !sort_dispatchees_internal
14:00 timotimo why doesn't prepargs appear even once in the jitlog ...
14:01 timotimo i just put an fflush into MVM_jit_log
14:01 timotimo so that can't be the problem, right?
14:01 timotimo oh hold on
14:02 timotimo "Can't add constant for operand type %d" is something in the exprjit compiler
14:02 timotimo not inside rakudo or something
14:02 brrt yes
14:02 timotimo so it *is* choking on my template
14:02 timotimo not generating wrong code that then crashes rakudo
14:02 brrt no
14:02 brrt that's good news
14:02 brrt anyway
14:02 timotimo ooooh
14:02 timotimo there's an operand type for callsites
14:02 brrt yes
14:02 timotimo that's the one that's missing
14:02 timotimo *facepalm*
14:03 brrt :-)
14:04 timotimo now it compileth
14:04 timotimo and runeth
14:06 timotimo seems correct, definitely
14:06 timotimo nice.
14:06 brrt awesome
14:06 brrt cool
14:07 timotimo huh. something weird is going on
14:07 timotimo i'm diffing the output of what Cannot get template for * we get
14:07 timotimo for the same program
14:07 timotimo and the numbers differ wildly
14:07 timotimo prepargs was only there 12 times (i.e. in 6 different spots)
14:08 timotimo but atkey_o went from 160 to 116 ... ?!
14:08 timotimo and wval from 135 to 105
14:09 timotimo hm. why was i working on prepargs in the first place when arg_* ops just immediately make the jit bail out anyway?
14:09 timotimo OH!
14:09 timotimo maximum facepalm
14:10 timotimo prepargs was special-cased in the normal jit to build an invocation; it'd slurp up all arg_* and the final call op, too
14:10 brrt hehehe
14:11 brrt right'
14:11 brrt maybe comment the prepargs template out, with a note saying 'don't add this, it'll break invocation compilation'
14:12 timotimo and push to your branch?
14:14 timotimo the annoying thing is: the only op that takes a callsite argument is prepargs :D
14:14 brrt heehe
14:15 brrt welll, even if we once convert that to expr jit, we're still going to special-case it
14:15 brrt anyway, i have a bigger fish to fry
14:15 brrt i want to have live range hole analysis, and I think I know how to do it
14:15 timotimo i committed, want me to push it to your branch?
14:16 brrt sure
14:16 brrt feel free
14:16 Geth ¦ MoarVM/even-moar-jit: 7f84ede186 | (Timo Paulssen)++ | 2 files
14:16 Geth ¦ MoarVM/even-moar-jit: add an impl of prepargs, which mustn't actually be used yet
14:16 Geth ¦ MoarVM/even-moar-jit:
14:16 Geth ¦ MoarVM/even-moar-jit: need to implement the rest of function invocation first, i.e.
14:16 Geth ¦ MoarVM/even-moar-jit: arg_* and invoke_*.
14:16 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7f84ede186
14:18 timotimo a few ops i can add are bindpos_*, bindkey_*, push and unshift
14:19 timotimo if i know how to throw an exception i can also implement ctxlexpad :)
14:20 brrt (when (….) (^throw_adhoc error))
14:20 brrt but the challenge is that we can't deal with strings...
14:20 timotimo oh
14:21 timotimo but strings are just pointers like regular MVMObject*?
14:22 brrt not MVMStrings :-)
14:22 brrt literal strings in the expr compiler
14:22 brrt that would need a better lexer
14:23 brrt i can spend time on that, but the live range hole is more relevant
14:23 brrt because that will solve the restore-garbage problem which is the main challenge against CALL with return values
14:23 brrt so, what are live range holes?
14:24 timotimo oh! for the error message
14:24 timotimo yeah, what are those?
14:25 brrt - they are regions in the code between the first definition and the last use, in which a value is *not* live, because the first definition does not flow into the basic block OR because the definition is overwritten in the basic block
14:26 brrt e.g. if I have (let (($foo (…))) (if (nz $foo) $foo (load …))) ;
14:27 brrt by PHI node resoution, the result of the first and second branch are the same thing, right
14:27 brrt they are the same value
14:27 brrt (after the 'let')
14:27 timotimo sure
14:27 brrt however, wihtin the second branch, $foo is *not* defined
14:27 brrt or rather
14:27 brrt it's never used
14:27 timotimo right, we could just use constant 0 in that branch instead
14:28 brrt right
14:28 brrt now
14:28 brrt suppose the second branch has in it a CALL
14:28 brrt because we often have ocnditional laternative branches
14:28 brrt eh
14:28 brrt conditional calls
14:30 brrt the CALL handling code inserts a 'restoring' spill-and-load of the $foo, which is after all used after the $foo (it's part of the live range that includes the result of the IF)
14:31 brrt in which case it could end up overwrititng the result of CALL
14:31 brrt to make a long story short
14:31 brrt stuff is broken
14:32 brrt the correct way to deal with it, from my perspective, is to make sure that the live range of $foo is correctly seen as 'not live' over the call
14:33 timotimo i'm not sure why it could overwrite the result of CALL there
14:34 timotimo because it might be in the register that the abi uses for return values?
15:13 brrt joined #moarvm
15:14 brrt ehm, i have a whole thing written about it
15:15 brrt https://github.com/MoarVM/MoarVM/blob/even-moar-jit/docs/jit/plan.org#solve-garbage-restore-problem
15:36 timotimo ah
15:36 timotimo of coursi think i read that
15:38 timotimo i cant copypaste from this ash client
15:38 timotimo becaus eit doesnt understand the alternative buffer
15:38 timotimo which tmux or weechat uses
16:10 brrt well, weechat is at least not adium
16:12 brrt joined #moarvm
16:27 zakharyas joined #moarvm
16:31 timotimo that's ... true
16:33 brrt so yeah, i hope that's reasonably clear :-)
16:33 timotimo no i mean weechat not being adium
16:34 brrt hehe
16:34 brrt i know
16:34 brrt i'll be blogging about what i've done soonish, i think
16:34 timotimo This sucks because %rcx
16:35 timotimo is only defined in
16:35 timotimo oh, is that so?
16:35 brrt i probably did not finish a sentence :-)
16:35 timotimo it could be assumed
16:50 brrt :-)
17:06 brrt hmm, stuff is hard
17:07 timotimo unlike fluff
17:09 brrt indeed
17:09 brrt well, actually
17:09 brrt stuff is mostly messy
17:12 TimToady joined #moarvm
17:29 domidumont joined #moarvm
17:40 brrt joined #moarvm
20:05 samcv oooo. looks like i might be able to setup Github pages with coverage reporting on travis
20:05 samcv and have travis upload to github page
20:05 samcv that would be neat
20:35 timotimo *neat*
20:35 timotimo yes, yes very neat, yes
21:00 lizmat and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/04/10/2017-15-kaboom-⁽¹⁾/
21:52 TimToady joined #moarvm

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