01:48 ilbot3 joined 04:24 brrt joined
brrt good * #moarvm 04:24
samcv hey brrt 04:25
i have appimages working for rakudo star :)
would you like to try it
brrt appimages? hang on.. i'm not sure I'm that far awake
what's an appimage? 04:26
samcv it's like a binary that's self contained
only one file. and you can +x and then run it
no install required
brrt oh, that's pretty cool
is that for linux?
samcv ye 04:27
brrt aw
samcv what do you have
brrt i'm on OS-X
samcv ah ok
well so far it's working great. all the modules in rakudo star work
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
srsly? did you make them? how?
i'm very impressed
we've been wanting single binary installs for …. years
samcv 10MB 04:29
ok here's the dl cry.nu/files/org.perl6.rakudo-x86_64.AppImage
2017.01 rakudo star
well. so we compile in hard directories for moarvm and .moar bytcode and a ton of places 04:30
brrt cool 04:31
i'm on a slow network
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
so installed in /rsu and replaced that with ././
something like that
the documentation could be better 04:32
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
brrt pretty cool :-) 04:33
samcv just uploaded the source files here github.com/samcv/rakudo-appimage the script doesn't fully work yet. but it's partially working
yeah :-) 04:34
i hate bad documentation. it could have been so much easier if they just said a few things
brrt hehehe
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
like oh you basically just do this and then and then hey! appimages are awesome
brrt hehe
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
that would be too easy if it said that
and all the paths are off, and not good 04:37
oh also i had to learn about all the ENV vars by dumping every env var 04:38
and create directories with weird names, then cding into that directory, and then grepping all the ENV vars
heh
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
which have full paths
brrt uhuh 04:56
samcv hmm we don't seem to have any checksums on rakudo.org for rakudo star 05:05
brrt i'm vaguely aware of that, yes 05:08
05:17 domidumont joined 05:22 domidumont joined 05:26 brrt joined 05:42 domidumont joined
brrt ugh, i think i've found my bug… :-( 05:55
(but why!!!!) 05:59
06:21 spebern joined
brrt yay, found the answer 06:23
samcv argh travis 06:29
06:36 domidumont1 joined 06:44 brrt joined 07:21 domidumont joined
Geth MoarVM/even-moar-jit: ddc94d9141 | (Bart Wiegmans)++ | src/jit/linear_scan.c
Fix off-by-one in DO live range determination

The first node of the DO list construct is the number of children, so the index of the last children reference is the index of the DO node, plus one, plus the number of children.		 07:45
MoarVM/even-moar-jit: 7fb1b1011f | (Bart Wiegmans)++ | 2 files
Rewrite 'LET' syntactic form to DO blocks

The compiler for template 'expressions' supports 'let' expressions to declare a variable and construct more complex expression graphs than simple trees. To ensure that any declarations in the let block are available in its associated expression, the declarations should compiled before the expression is. ... (15 more lines)
MoarVM/even-moar-jit: 46b117fa0f | (Bart Wiegmans)++ | src/jit/expr.c
Remove redundant and dangerous 'rooting' construct

Templates used to be able to enforce the 'rooting' of certain nodes so that they'd be compiled in a certain order; a feature that was used only for LET declarations. As LET declarations now compile via DO blocks instead, this is no longer necessary.
samcv brrt, you merged right. i never did run a coverage test for you
brrt i did
samcv k. will generate for you
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
and it will do the expected thing
samcv your commit? 08:02
brrt yeah 08:03
samcv brrt, so that pl script creates the other file there? 08:12
brrt eh, which other file are we talking about? 08:17
samcv github.com/MoarVM/MoarVM/commit/7f...00f52f55bc 08:19
the template thing creates which files
brrt oh, right 08:21
so
we have a list of template definitins in src/jit/core.expr
they map moarvm opcodes to expression templates
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 cry.nu/coverage/even-moar-jit/libmoar/
brrt ouch, the printf shouldn't have gone in
samcv happens to the best of us 08:23
i almost always do git add -p so i can review all the things.
also helps me write a better commit message usually
Geth MoarVM/even-moar-jit: c3648238fc | (Bart Wiegmans)++ | 2 files
Remove debugging output, reorganize plan a bit
brrt i'm using magit actually :-) should've seen it 08:24
samcv magit?
hope the coverage gives some insights. very interesting stuff 08:25
brrt mostly a bunch of assertions 08:27
that don't work
i should get that story cleaned up, as well
ANY is clearly currently not yet used 08:28
interesting stuff samcv, very helpful
magit.vc/
samcv no problem :) 08:29
brrt ehm, i'm wondering if even-moar-jit is out of date again 08:52
cause i can't compile rakudo correctly?
samcv dunno 08:53
is it missing an op?
09:10 Ven joined
brrt maybe.... 09:22
not sensitive to spesh
let me check
09:26 zakharyas joined
brrt git is not merging nicely :-( 09:27
09:37 Ven_ joined 09:46 Ven_ joined 10:27 Ven joined 10:45 Ven_ joined 11:15 Ven_ joined
brrt i don't know what did it, but rakudo compiles again on even-moar-jit, so yay 11:28
samcv; ehm, .... 11:30
would you consider using a for loop in this commit: 9b9b1b5ec680833ba844953ae7bdd51c68327bdb
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)++
review: github.com/MoarVM/MoarVM/compare/c...2dd7a1127d
brrt you can do a bunch of things if you're creative
hmm, not sure if i'm asking for the right thing, now :-)
timotimo huh.
trying to checkout that branch gives me a bunch of files in my working copy that "would be overwritten" 11:33
src/jit/linear_scan.c
src/jit/x64/tiles.list
tools/expr-template-compiler.pl
tools/tiler-table-generator.pl
how did i end up with these loose in my working copy, i wonder
brrt i dunno
timotimo oh, i still had to fast-forward on the branch itself 11:34
expr_ops.h gives me a warning a bunch of times; backslash-newline at end of file
i have no idea what i'm looking at in the jit graphs :D 11:37
a do with a discard is like a void-return-value do node?
hm. there's an add node that has a do-node with a discard in one of its operands 11:38
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
i bet we make real good machine code for this :D
nwc10 I can't check the sound on this, but I assume that it's appropriate: www.youtube.com/watch?v=M_eYSuPKP3Y 11:44
timotimo heh. 11:45
brrt: we can only callv so far, right? no call-with-return-value?
brrt indeed 11:46
timotimo right
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'
i'm wondering if it'd be a reasonable idea to put wvals in our data segment
timotimo they can't change, but they *can* be "not yet resolved" 11:48
so that might be problematic perhaps?
brrt well, i can enforce resolving?
timotimo same reason we now refuse to inline stuff when it'd cause a wval to have to be deserialized 11:49
are you allowed to hold mutexes in the jit?
like, safe-point-wise?
brrt honestly, no idea
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:55 Ven joined
brrt no 11:55
but
the jit doesn't use any MVMCollectable structures
timotimo well, that could be good, then 11:56
brrt but, i don't understand why it can't be done in inlining
timotimo well, if we cause an object to be deserialized, we have to take the lock for sc stuff
brrt so that makes me suspicious if it's safe to do in the jit
timotimo that means we'll be blocked and another thread might start doing gc for us 11:57
right now spesh will prevent gc from happening while it's doing a single thing
12:01 geekosaur joined
brrt hmmm 12:10
well, the alternative is just to insert the call
timotimo one thing about spesh is we play it really loose with the memory management 12:11
right
but that call requires a return value :D
brrt hush, you'll wake up the rusk evangeism task force
timotimo the what now o_O 12:12
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:13
timotimo oh 12:14
are they against functions with return values? :)
brrt no, they're not 12:15
but i'd suspect that 'playing it really loose with the memory managment' would set a few bells riniging
timotimo oh
i see
well, that's just how we allocate and "deallocate" memory in spesh :) 12:16
12:16 Ven_ joined 12:21 domidumont joined
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
wow.
brrt: i wonder why we get a "cannot get template for *" before and after each graph dump? 12:30
12:38 AlexDaniel joined
brrt yeah, i read that too 12:39
that's because the template compiler tries to make a graph until it can't anymore
and the usual reason it can't make a graph is tbecause the template is not yet available
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:41
timotimo timo@schmand ~/p/moarvm (even-moar-jit)> perl6 tools/expr-template-compiler.pl 12:42
===SORRY!===
Attempt to unlock mutex by thread not holding it
yikes!
yeah, i know :)
but why does it output it twice?
hm, so i tried to add a template 12:45
and it compiles
but it doesn't prevent any "couldn't get template for myop"
(macro: ^cu_callsite (,a) (idx (^getf (cu) MVMCompUnit body.callsites) ,a ptr_sz))
(template: prepargs (^setf (^getf (tc) MVMThreadContext cur_frame) MVMFrame cur_args_callsite
(^cu_callsite $0)))
does that look about right?
{ &MVM_jit_expr_templates[285], "..l..l..l...l..l..lf..ll.", 25, 21, 0 }, 12:48
12:48 zakharyas joined
timotimo this is how it shows up in the expr tables 12:48
12:50 Ven_ joined
timotimo oh, did i forget "make install"? 12:51
Can't add constant for operand type 13 - so i've implemented the template wrong. a step up from not having it at all :)
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:56
huh. for the exploding program, prepargs doesn't even show up in the jitlog? i wonder why. 12:58
13:09 brrt joined
brrt hang on 13:10
13:13 brrt joined
brrt so, i'm back 13:13
okay, so, the expr compiler is not a perl6 program
:-) 13:14
that's the first bit
so, what did you write and add 13:15
alltogether
ah, i see
13:16 Ven joined
timotimo did i wronged? 13:30
brrt not sure 13:31
i don't have time directly to look into it too much 13:32
timotimo ah, OK
i'll drop it for now, then
brrt could you stash it in a gist? i'll debug what's happening then 13:34
would also help me in figuring out how to improve the ergonomics of the process
:-)
timotimo sure 13:35
gist.github.com/timo/3ac9a97cbaf71...eb27f6c504 - brrt's gist for future reference 13:37
brrt does cu_string macro actually work, i wonder 13:38
timotimo if it doesn't that could explain what's going wrong ;) 13:40
i have a graph here that has it in it, but i don't know how to properly verify 13:41
imgur.com/a/mhCIG
brrt it looks reasonable enough at first site 13:43
*sight
the const is somewhat large, though... 13:44
timotimo how do i read this format ... 13:47
okay so MVMObject itself is 24 bytes big
inside of MVMCompUnitBody, the offset of "strings" seems to be 80 13:48
m: say 0x2c9
camelia 713
timotimo hm
brrt so the cheap thing to do is to add a printf and check the number we're adding :-) 13:49
timotimo where does that go? 13:50
m: say (80 + 24).base(16) 13:51
camelia 68
timotimo it seems i was looking at the wrong thing
addr(0x68) -> cu is definitely right for the strings field 13:52
of course the spesh log doesn't tell me what the index of a literal string is 13:54
because that's otherwise a useless information
brrt that should go… let me check 13:55
timotimo const_s r49(9), lits(exact_invocant)
const_i64_16 r50(3), liti16(1)
hllboxtype_i r28(23)
that's the piece of code we're compiling here
brrt okay 13:56
is that not working?
src/jit/expr.c line 182, below MVM_operand_str 13:57
that's where you want to printf the lit_str_idx
timotimo well, the program runs just fine 13:58
this is inside the code for !sort_dispatchees_internal
why doesn't prepargs appear even once in the jitlog ... 14:00
i just put an fflush into MVM_jit_log 14:01
so that can't be the problem, right?
oh hold on
"Can't add constant for operand type %d" is something in the exprjit compiler 14:02
not inside rakudo or something
brrt yes
timotimo so it *is* choking on my template
not generating wrong code that then crashes rakudo
brrt no
that's good news
anyway
timotimo ooooh
there's an operand type for callsites
brrt yes
timotimo that's the one that's missing
*facepalm*
brrt :-) 14:03
timotimo now it compileth 14:04
and runeth
seems correct, definitely 14:06
nice.
brrt awesome
cool
timotimo huh. something weird is going on 14:07
i'm diffing the output of what Cannot get template for * we get
for the same program
and the numbers differ wildly
prepargs was only there 12 times (i.e. in 6 different spots)
but atkey_o went from 160 to 116 ... ?! 14:08
and wval from 135 to 105
hm. why was i working on prepargs in the first place when arg_* ops just immediately make the jit bail out anyway? 14:09
OH!
maximum facepalm
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
right' 14:11
maybe comment the prepargs template out, with a note saying 'don't add this, it'll break invocation compilation'
timotimo and push to your branch? 14:12
the annoying thing is: the only op that takes a callsite argument is prepargs :D 14:14
brrt heehe
welll, even if we once convert that to expr jit, we're still going to special-case it 14:15
anyway, i have a bigger fish to fry
i want to have live range hole analysis, and I think I know how to do it
timotimo i committed, want me to push it to your branch?
brrt sure 14:16
feel free
Geth MoarVM/even-moar-jit: 7f84ede186 | (Timo Paulssen)++ | 2 files
add an impl of prepargs, which mustn't actually be used yet

need to implement the rest of function invocation first, i.e. arg_* and invoke_*.
timotimo a few ops i can add are bindpos_*, bindkey_*, push and unshift 14:18
if i know how to throw an exception i can also implement ctxlexpad :) 14:19
brrt (when (….) (^throw_adhoc error)) 14:20
but the challenge is that we can't deal with strings...
timotimo oh
but strings are just pointers like regular MVMObject*? 14:21
brrt not MVMStrings :-) 14:22
literal strings in the expr compiler
that would need a better lexer
i can spend time on that, but the live range hole is more relevant 14:23
because that will solve the restore-garbage problem which is the main challenge against CALL with return values
so, what are live range holes?
timotimo oh! for the error message 14:24
yeah, what are those?
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:25
e.g. if I have (let (($foo (…))) (if (nz $foo) $foo (load …))) ; 14:26
by PHI node resoution, the result of the first and second branch are the same thing, right 14:27
they are the same value
(after the 'let')
timotimo sure
brrt however, wihtin the second branch, $foo is *not* defined
or rather
it's never used
timotimo right, we could just use constant 0 in that branch instead
brrt right 14:28
now
suppose the second branch has in it a CALL
because we often have ocnditional laternative branches
eh
conditional calls
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:30
in which case it could end up overwrititng the result of CALL 14:31
to make a long story short
stuff is broken
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:32
timotimo i'm not sure why it could overwrite the result of CALL there 14:33
because it might be in the register that the abi uses for return values? 14:34
15:13 brrt joined
brrt ehm, i have a whole thing written about it 15:14
github.com/MoarVM/MoarVM/blob/even...re-problem 15:15
timotimo ah 15:36
of coursi think i read that
i cant copypaste from this ash client 15:38
becaus eit doesnt understand the alternative buffer
which tmux or weechat uses
brrt well, weechat is at least not adium 16:10
16:12 brrt joined 16:27 zakharyas joined
timotimo that's ... true 16:31
brrt so yeah, i hope that's reasonably clear :-) 16:33
timotimo no i mean weechat not being adium
brrt hehe 16:34
i know
i'll be blogging about what i've done soonish, i think
timotimo This sucks because %rcx
is only defined in 16:35
oh, is that so?
brrt i probably did not finish a sentence :-)
timotimo it could be assumed
brrt :-) 16:50
hmm, stuff is hard 17:06
timotimo unlike fluff 17:07
brrt indeed 17:09
well, actually
stuff is mostly messy
17:12 TimToady joined 17:29 domidumont joined 17:40 brrt joined
samcv oooo. looks like i might be able to setup Github pages with coverage reporting on travis 20:05
and have travis upload to github page
that would be neat
timotimo *neat* 20:35
yes, yes very neat, yes
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/04/10/...aboom-⁽¹⁾/ 21:00
21:52 TimToady 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!