# IRC log for #moarvm, 2015-08-12

All times shown according to UTC.

Time Nick Message
00:00 Peter_R joined #moarvm
04:42 pyrimidi_ joined #moarvm
07:01 brrt joined #moarvm
07:01 brrt \o
07:01 brrt ok, i have finally arrived at a rather annoying answer
07:02 brrt did you maybe recall that i reduced the time to create the rulesets by using a topological sort?
07:02 brrt it's the right direction, i still think, but the wrong answer
07:02 brrt because the grammar 'graph' has cycles
07:02 brrt and topological sort clearly cannot function on a graph that has cycles
07:03 brrt i can break those cycles just fine, but that means the order each node is evaluated becomes a) nondeterministic (because depending on hash keys order) b)  incomplete, meaning i  can miss nodes
07:04 brrt and combinations, meaning i can miss rulesets, meaning my tiling table is worthless
07:04 brrt i'm currently working on a way arround that....
07:04 brrt or rather
07:05 brrt another way to phrase the same problem so that we can a): determine all rulesets that can actually be generated from the grammar b): do so in a time that doesn't explode
07:05 edsc joined #moarvm
07:06 brrt so, :-(, but on the other hand, *I understand the problem again*, which is kind of important
07:06 brrt does this actually happen? yes. there is a subtle other problem, relating to the 'chosen rule' in a table
07:22 ely-se joined #moarvm
07:30 pyrimidine joined #moarvm
07:44 edsc left #moarvm
07:52 arnsholt brrt: What kind of grammar is it?
07:53 arnsholt (That is, is it context-free, or something else?)
07:53 brrt ehm.. i suppose context-free?
07:54 arnsholt In that case, you might just want to CKY it
07:54 brrt CKY?
07:54 arnsholt Of course, CKY is O(n^3)
07:54 arnsholt Cocke-Kasami-Younger. Bottom-up dynamic programming algorithm for matching CFGs
07:54 brrt oh, that one :-)
07:55 brrt nah, that's not really acceptable
07:55 arnsholt Yeah, I figured
07:55 arnsholt Most "normal" CFGs are parseable in linear time, though
07:55 arnsholt But if you have some kind of cost factor, I'm not sure if that still holds
07:56 brrt hmmm
07:56 brrt let me look at that
07:56 arnsholt Incidentally, for CFGs with cost, what you probably want to look for is probabilistic CFGs
07:57 ely-se what does parsing a CFG mean?
07:58 arnsholt Finding the (or a) sequence of rule applications that derives the target string from start rule
07:58 brrt hmmm.. maybe my use of the word grammar was only colloquially correct? i'm not really dealing with a string, but with a tree
07:59 arnsholt Yeah, it's not quite the same
08:02 brrt and my problem isn't really generating matches but generating a matching table
08:02 brrt :-)
08:03 arnsholt It's sort of inverse, I guess? You have a tree of things, and you want to convert that into a linear sequence of machine ops, right?
08:03 brrt yes
08:03 brrt that's the tiler :-)
08:04 brrt it uses a DFA generated from the tiling grammar
08:04 brrt it is generating the DFA - transition tables that i'm having something of a problem with
08:05 brrt generating the table is simple enough, but it pre-requires knowing the combinations of rules that generatee rulesets
08:05 arnsholt Right, right
08:05 brrt wait, i'll make a gist of the pathological case
08:06 arnsholt In that case, you might just want to restructure your grammar
08:07 arnsholt The grammar corresponding to regular languages is left-linear or right-linear grammars. That is, a grammar with at most one non-terminal and all the terminals on either the left or right side of the non-terminal
08:08 arnsholt And regular languages are matched with [ND]FAs, of course
08:08 zakharyas joined #moarvm
08:08 brrt sorry... what *exactly* is a terminal? i'm known to use these terms rather sloppiliy
08:09 brrt and a nonterminal?
08:10 arnsholt A non-terminal is a rule, bascially, while a non-terminal is the non-rule things generated/matched by the grammar
08:10 brrt aha
08:10 brrt so if i have (foo reg) -> reg the non-terminal is the reg, the terminal is the (foo reg) ?
08:11 arnsholt I think, so, yeah
08:13 brrt https://gist.github.com/bdw/5fccd561f75bb4a185df is an example of the pathological case
08:14 arnsholt So, what's the syntax of these?
08:14 ShimmerFairy I should really get to studying the formal stuff on grammars sometime. I've only ever understood them from a programming standpoint (esp. Perl 6 ☺). Doesn't help that I find BNF syntax an absolute chore to read, though.
08:35 brrt arnsholt: s-expressions.
08:35 brrt tile: declare tile
08:36 brrt (tile: name (tree) nonterminal)
08:38 arnsholt Right. So "t (t) r" is means that an r can be replaced with a t, and it's named t?
08:40 ely-se Is there API documentation for MoarVM's C API?
08:40 ely-se Or is there no C API?
08:40 JimmyZ no doc ...
08:40 ely-se :O
08:40 jnthn ely-se: We've never specified one really, though anything with the marker MVM_PUBLIC is something we'd consider an "in"
08:40 ely-se amazing :3
08:41 jnthn ely-se: You need to remember why MoarVM exists: to be a great VM for Perl 6.
08:41 ely-se oh, I thought it was meant to be a general-purpose VM :v
08:41 jnthn ely-se: If it attracts wider interest that's fine.
08:41 jnthn ely-se: And it's surely nice for a lot more.
08:41 ely-se ok
08:42 JimmyZ since we have HLL config :P
08:42 jnthn ely-se: Thing is, the people working on it are also generally working on Perl 6, and so are crazy busy, so it's a bit DIY :)
08:42 jnthn (In terms of doing other things)
08:42 jnthn The bytecode format is accurately documented, though (I've tried to keep that doc up to date)
08:42 ely-se oh nice
08:43 ely-se so I can generate bytecode and run it?
08:43 jnthn I don't see why not
08:43 jnthn Sure, MAST just abstracts you from the bytecode format.
08:44 jnthn If you get your own language up on MoarVM, then all the MAST -> bytecode compiler cares about is you give it objects that match its layout expectations
08:44 jnthn So you can re-create the MAST nodes in your own language if you wished.
08:45 jnthn But there bytecode format hasn't changed incompatibly much at all
08:45 jnthn *the
08:48 brrt arnsholt: that is correct, yes
08:49 arnsholt brrt: Right, so there's a cycle in the r -> (a r) rule, basically?
08:49 ely-se my language is stack-based so I'll have to figure out a way to turn that into MAST or register-based bytecode
08:52 ely-se the obvious choice is to generate code that allocates an array for the stack and an integer for the end of the stack :P
08:52 ely-se and generate code that acts on those
08:54 jnthn Don't though...then spesh won't make sense of much at all :)
08:54 jnthn When I've had to do such things, the first shot was just treat registers like stack locations
08:54 brrt arnsholt: yes
08:54 jnthn r0 is stack location 0, r1 is stack location 1, etc.
08:54 brrt and, that's ok
08:55 jnthn Keep an array of those
08:55 * brrt has no real idea how to translate from stackbased to registerbased code
08:55 jnthn You can then make stack loads from locals (if you have them) lazy to and get better code.
08:56 jnthn For my final year project at university, I worked on translating code from a stack to a register machine :)
08:56 ely-se nice!
08:56 jnthn So this problem I did have to ponder once :)
08:56 ely-se my compiler currently turns SSA into stack code, using a local variable for every SSA variable
08:56 brrt jnthn... what happens if you pop an integer and push an object (i.e. how to ensure pointer validity?)
08:56 ely-se so the generated code is absolutely awful
08:56 brrt oh, you use multiple arrays
08:56 ely-se but it works :p
08:57 jnthn brrt: Yes, that :)
08:57 ely-se i.e. "f(x, y)" stores f, x and y in local variables, then loads those local variables onto the stack, makes a call, then puts the result of the call in a local again
08:57 brrt if you have SSA, and given that moarvm lets you create as many registers as you like, it shouldn't be too hard to generate register code directly?
08:57 brrt i mean you don't have to worry about register allocation, which is a huge timesaver :-)
08:58 jnthn It's not quite "as many as you want", but yeah, it's a 16-bit number for register index :)
08:58 ely-se brrt: SSA is only present in the compiler, since stack code is hard to optimize. it's not present in the output
08:58 brrt well, make different output :-)
08:58 brrt or just generate MAST instead
08:58 brrt 'just\
08:59 brrt '
08:59 ely-se I chose to put stack code in my compiled module files since its more compact, and the modules are downloaded by web browsers a lot
09:00 JimmyZ CLI is stack?
09:00 ely-se CIL is stack-based, yes.
09:02 brrt like jvm, python, etc
09:02 brrt lizmat: that was a really nice article, btw :-)
09:07 ely-se jnthn: do you know any articles on such a translation?
09:10 jnthn ely-se: Not off hand now; it was quite a few years ago. My dissertation is online (but not sure it did the details on that), but it may have some papers referenced
09:10 ely-se coooooool :3
09:11 jnthn http://jnthn.net/papers/2006-cam-net2pir-dissertation.pdf
09:11 ely-se tailcalls may prove a challenge though :p
09:16 ely-se jnthn: thanks, I'll read it
09:22 brrt oh, really cool jnthn :-)
09:24 jnthn Be careful, I wrote that when I was 9 years more ignorant than now :)
09:25 brrt probably still a few years less ignorant than me today :-)
09:26 brrt jnthn: if you could take a look at this, maybe you have an idea
09:26 brrt https://gist.github.com/bdw/5fccd561f75bb4a185df#file-explanation-md
09:26 brrt i'd be very happy :-)
09:26 jnthn OK, lemme grab another coffee... :)
09:27 jnthn (also, wait for my list assignment impl attempt to compile...)
09:30 ely-se jnthn: where can I find the bytecode docs?
09:31 brrt there are no bytecode docs... as far as i know
09:31 brrt oh, that's not true
09:31 ely-se 10:42 <           jnthn > The bytecode format is accurately documented, though (I've tried to keep that doc up to date)
09:32 brrt http://github.com/MoarVM/MoarVM/blob/docs/bytecode.markdown
09:32 brrt http://github.com/MoarVM/MoarVM/blob/master/docs/bytecode.markdown
09:32 ely-se oh, I thought the documents in that directory were obsolete
09:32 brrt why assume that?
09:33 jnthn bytecode.markdown is the one I've been maintaining
09:33 jnthn brrt: looking
09:35 brrt thanks :-)
09:35 ely-se nice
09:40 ely-se why are things like mkdir instructions instead of functions?
09:42 brrt well, they're functions alright
09:43 brrt but they're also instructions, because you must dispatch to them in some way
09:43 jnthn brrt: "rules t1 and at2" - am I missing soemthing, or do you not define what t1 is? :)
09:43 jnthn ely-se: Unlike many VMs that have two ways to invoke logic implemented by the VM, MoarVM has just one.
09:43 brrt see the file below. rule t1 is (tile: t1 (t) r)
09:43 ely-se ok
09:44 brrt and at2 is the 'generated rule' (t) -> t' which takes the place of the (t) in (a (t))
09:44 brrt make sense?
09:45 ely-se I'll try to get hello world to work this weekend.
09:45 jnthn ely-se: On the JVM/CLR it's kinda OK to have VM-implemented methods because the object system is entirely defined inside of the VM. MoarVM by contrast leaves most of the object model definition out of the VM, so the VM has no real idea about things like inheritance and so on.
09:46 ely-se very nice
09:47 jnthn brrt: I think I need to get the terminology straightened out a bit better in my head. :)
09:48 jnthn brrt: So, considering the first entry in x64.tiles:
09:48 jnthn (tile: load_stack (stack) reg 1)
09:48 jnthn tile: just says "it's a tile". load_stack is the name of it. How should I interpret the next 3 things?
09:49 brrt (stack) is the terminal (if i understand it correctly). that is, it represeents part of the input tree
09:49 brrt reg is the nonterminal (it is the thing that the tile yields, an incidentally, it's also the place this can take in any other node)
09:49 brrt 1 is the estimated cost according to some cost function i haven't really worked out very well yet
09:50 jnthn I guessed the 1 correctly at least :)
09:50 jnthn Lower is cheaper (and so preferable), yes?
09:50 brrt yes
09:50 brrt it's basically, 1 for an instruction, 1 for using a register, 1 or two for an arithmetic operation, 4 for memory access
09:50 brrt but not used very consistently yet
09:50 jnthn At the top of the file you have:
09:50 jnthn # Terminals: reg, mem, flag, void, expr, lab
09:51 jnthn Is this incomplete?
09:51 brrt that should be nonterminals
09:51 brrt sloppy terminology from my part
09:51 jnthn That's like, the opposite man :P
09:51 brrt yeah
09:51 brrt sorry about that :-)
09:51 jnthn So local and cu are actually terminals?
09:52 jnthn They can't expand to anything else?
09:52 brrt yes
09:52 brrt no
09:52 jnthn OK, so
09:52 jnthn (tile: load_cu    (cu) reg 1)
09:52 brrt matches (cu), yields reg, costs 1
09:52 jnthn Means "if you need to get the cu into a register, this is a good way to do it"
09:53 brrt yes
09:54 jnthn And considering:
09:54 jnthn The extra parens around (const) are because const is a terminal?
09:55 brrt well... ehm... yes
09:55 jnthn Or because it's a nested tree node to match?
09:55 brrt yes, that
09:57 brrt and it expands to (add_const (add reg PLACEHOLDER) reg 1.5) and (placeholder (const) PLACEHOLDER 1.5)
09:57 jnthn What is "load mem" in this one?
09:57 brrt mem is a nonterminal, generated, in this case by (idx reg reg) and (addr reg) (and i think by (label (const)), too, but i haven't added that
09:58 jnthn ah, yeah, I see one generating a mem
09:58 brrt in the tile implementation, it generates a 'memory descriptor'
09:58 brrt which can be placed virtually anywhere (part of x86 instruction set)
10:00 brrt the names of expression tree ops
10:00 brrt (load mem) is a terminal
10:00 brrt that refers to the mem nonterminal
10:00 jnthn OK
10:01 brrt (store mem reg) -> same story :-)
10:01 jnthn *nod*
10:03 brrt i.. am currently thinking i should rephrase the problem in terms of temrinal sets and coreduction
10:03 brrt but that's not totally worked out yet
10:03 jnthn Yeah, we need a better way to talk about these things, I can see that :)
10:04 jnthn OK, so back to the problem at hand
10:04 jnthn foo.scm in your gist is the input we're considering?
10:04 brrt aye
10:04 brrt i called it scm because that way github formats them nicely
10:05 jnthn And we're considering what happens if we have those and *then* we also add (tile: at (a (t)) r)?
10:05 brrt the topological sort doesn't work, because after it has generated ruleset {s1, as2} and {t1, at1}
10:05 brrt that one is included (called at1 :-))
10:06 jnthn I'd get somewhere faster with this is the names were a little more consistent :)
10:08 brrt anyway, after it has generated rulesets {s1, as2} and {t1, at2}, it can only generate combinations {a1, at1} and {a1, as1}, but not {a1}
10:08 brrt because there is no ruleset that only generates {a1} if applied to all rules starting with a
10:08 brrt does that make sense?
10:13 jnthn Starting to...
10:13 * jnthn is still missing a piece
10:13 brrt ok, which piece is that
10:13 brrt :-)
10:15 jnthn So, we expand the rules as discussed
10:15 jnthn BUT that doesn't mean we consider the original rules "discarded" in some way
10:16 brrt ehm, no
10:16 brrt well
10:16 brrt eh
10:17 brrt you mean like (add reg (const)) expanded to (add reg const') -> reg and  (const) -> const', that expansion?
10:17 brrt the original tree is actually kind of lost, yes
10:17 jnthn I mean:
10:17 jnthn # (tile: at1 (a (t)) r)
10:17 jnthn (tile: at2 (t) t')
10:17 jnthn (tile: at1 (a t') r)
10:18 jnthn The comment being what we started with, and the latter being the two things we expand it into
10:18 jnthn But then in the rule sets, you talk about a rule for (a (t))
10:18 brrt yeah, that one
10:19 brrt yeah, that's actually the rule expanded to (a t'), what i mean
10:19 brrt (i really should've talked more about this, that way other people might understand my thoughts a bit better)
10:20 jnthn So, in the rule sets
10:20 jnthn (s) -> {s1, as2}
10:20 brrt yes
10:21 jnthn Should I read this as "if you see an s node in the expression tree, then s1 or as2 might be applicable here"?
10:21 brrt yes
10:21 brrt in fact, *at any time* you see (s), s1 and as2 are equally applicable
10:21 brrt only at the point you see (a s'), then you can decide
10:22 brrt (clearly, in this case, the isolated (s) node is completely redundant. but let's not worry about that :-))
10:22 jnthn OK, so considering
10:22 jnthn (a (t)) -> {a1, at1}
10:22 brrt yes
10:23 jnthn Would I be reading that in the light of the rename, or not?
10:23 jnthn As in, is it really
10:23 jnthn (a (t')) -> {a1, at1}
10:23 brrt that one is weird. what i mean by that is that (a (t)) can expand to (a r) or (a t')
10:23 brrt because (r) can reduce (i think it's called to either of {r, t'}
10:25 brrt i'm going to have lunch :-) be back in an hour or so
10:25 jnthn OK
10:25 brrt thanks for looking at it :-)
10:26 jnthn One of the oddities here
10:26 jnthn Is that topological sort is defiend on a DAG
10:26 brrt uhuh
10:26 jnthn But here you have a DCG
10:26 jnthn :)
10:26 brrt exactly
10:26 brrt there you have my problem
10:26 brrt anyway, i'm pondering on it over lunch :-)
10:26 brrt left #moarvm
11:00 rurban_ joined #moarvm
11:07 ely-se brrrr I just ate pure cocoa
11:12 arnsholt Mmmmm. Bitter =)
11:30 brrt joined #moarvm
11:31 brrt lunched :-)
11:53 japhb joined #moarvm
12:06 timotimo ohai
12:31 ely-se Is it possible to extend MoarVM with custom instructions?
12:33 jnthn ely-se: yes
12:33 jnthn ely-se: Rakudo does it
12:35 ely-se when I do that, do I have to write my own interpreter and JIT compiler for those instructions?
12:36 ely-se I have some special floating point computation semantics
12:36 jnthn You supply C functions for the interpreter to call. The JIT will emit calls to your functions.
12:36 ely-se oh, ok.
12:36 jnthn You can optionally also have the dynamic optimizer call you back
12:36 ely-se nice
12:37 jnthn So you can do stuff at optimization time
12:37 ely-se Is there documentation on that?
12:37 jnthn Though not currently specify what to JIT into; brrt++'s current work may well get us that
12:38 jnthn No, though I suspect you'll be able to pick it up by looking at what Rakudo does.
12:38 brrt yes, it is the intention that you can get a callback by the JIT to supply a template in place of the function
12:39 ely-se ok! thanks!
12:45 brrt jnthn: have you accidentally looked any further at it, or just any old thoughts about it? :-)
12:45 brrt i'd be much obliged
12:47 jnthn brrt: Well, I'm wondering if there's any traversal that *is* well defined on a cyclic graph that you can do.
12:47 jnthn brrt: Rather than trying to hack thing into a DAG
12:47 brrt yeah... i don't think there is
12:47 jnthn (e.g. DFS, BFS, etc.)
12:47 jnthn (Which just have a "seen" hash over the nodes, so cycles are fine)
12:48 brrt hmmmmmm
12:49 brrt hmmmm
12:49 brrt that... is not a bad idea at all
12:49 brrt that makes sense
12:49 brrt i think
12:49 jnthn I'm not clever enough to tell you which of the two you might want to try... :)
12:49 jnthn At least, not without pondering it a bunch more
12:49 jnthn And I'm also trying to untangle Perl 6's slicing bullcrap at the moment :/
12:50 brrt well, you should probably focus on that, then :-)
12:50 brrt but thanks
12:50 brrt that is already a huge help
12:51 jnthn OK, good :)
13:17 ely-se where should dynload.h come from? make says it can't be found
13:19 ely-se I'll install libffi
13:19 brrt not sure that's necessary?
13:20 brrt oh, i think dynload.h is probably from the dyncall sources? you will want to -I\${MOARVM_PREFIX}include/dyncall probably
13:20 brrt in fact there are a few such directories you'll want on the search path
13:21 jnthn ely-se: Are you trying to build MoarVM itself, or your extension ops?
13:21 ely-se MoarVM
13:21 ely-se as a library
13:21 brrt hmm....
13:21 brrt make libmoar.so :-)
13:21 brrt *should* just work
13:21 brrt what platform are you on
13:21 ely-se Linux kim-jong-deux 4.0.5-gentoo #1 SMP Wed Aug 5 12:16:38 CEST 2015 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux
13:23 ely-se here's the full output: https://gist.github.com/rightfold/1a5555c2eb3d5e2ef3d1
13:24 brrt ehm.. can you do a git submodule init followed by a git submodule update?
13:26 ely-se <3
13:26 ely-se it worked! :D
13:27 brrt well, more worryingly, the submodule update should be implied by the Configure.pl, didn't work, and Configure.pl did not complain
13:27 brrt according to your output, that is
13:27 brrt ely-se: try make -j4 for faster builds
13:29 ely-se it already built :p
13:30 brrt dunno who did write the moarvm makefile, but it parallelizes quite nicely
13:31 ely-se is there also a way to list all -I flags I have to pass to clang in order to use MoarVM library?
13:33 ShimmerFairy when complining moar,  make NOISY=1  will get you the actual lines used to compile
13:34 brrt actually, rakudo knows about it
13:34 brrt so that may be the simplest way to do it
13:35 jnthn You may be able to get nqp to spit out the info
13:35 jnthn nqp --backend-config or so
13:35 brrt otherwise, you can make a Makefile target that says what_are_my_flags: echo \$(CFLAGS)
13:36 ely-se ah, CINCLUDES
13:36 brrt moar::ccincludes
13:37 brrt from nqp-m --show-config
13:37 brrt nqp-m --show-config | grep cincludes | cut -c 18-1000
13:38 ely-se I'll make my build system append such a rule to the Makefile :p
13:39 brrt nqp-m --show-config | grep cincludes | perl -pe 's/^.+= //'
13:39 brrt also works
13:40 ely-se this works :) https://gist.github.com/rightfold/603b66a516acf15d95c8
13:40 ely-se I'll find a workaround for the void* assignment, probably -fpermissive or somethnig
13:41 jnthn Yeah; please don't try and convince us to make the MoarVM codebase valid C++ also :)
13:41 jnthn It's hard enough to keep it in a dialect of C that compiles on all the targets. :)
13:41 brrt NO
13:41 ely-se I'll probably just write some glue in C
13:41 brrt nobody takes my void* away from me
13:41 jnthn And I decided against writing the VM in C++ for a reason :)
13:41 jnthn Well, multiple. :)
13:41 brrt what reason was that, by the way
13:41 brrt *reasons were those
13:42 brrt not arguing against it, just pointing out that e.g. v8 is written in C++ and works well enough
13:42 brrt btw, did you perchance see the design document of the interpreter the v8 guys want to build
13:43 ShimmerFairy I happen to prefer C++ quite a bit more: sufficiently low level for my needs but not without some of the stuff I enjoy from higher-level languages :)
13:43 brrt i don't program in C++ at all
13:44 brrt so that would've been a problem with c++, for me
13:44 ShimmerFairy what, that you don't know it? :)
13:47 ShimmerFairy I don't have a problem with C, I just don't use it enough to be too familiar with the more functional nature of its code. My only problem is with restraining yourself on not-that-new versions of C/C++ because people still use inferior compilers :P
13:48 jnthn brrt: Partly 'cus I didn't feel comfortable enough with C++ to lead a project written in it, partly because I have a much harder time having an idea of the mapping to underlying hardware, partly because you really *do* want to be able to do C-style pointer screwery in a VM.
13:48 ely-se I once wrote a VM in C++. I deleted it but there's still an old fork around: https://github.com/sehe/mill/tree/develop/mill/src
13:48 ely-se a *very old* one; I rewrote it after that fork
13:49 ShimmerFairy jnthn: I had a feeling that was the reason, which is why I qualified "sufficiently low level" with "for my needs" :)
13:49 ely-se oh, I found a later fork: https://github.com/tomalakgeretkal/mill/tree/develop/mill/src :)
13:50 ShimmerFairy jnthn: incidentally, does MoarVM still not use C99 and its nifty features, like declaring variables beyond just the start of the function body? :)
13:52 jnthn ShimmerFairy: No because MSVC
13:52 jnthn And the delcaration one is *really* annoying :/
13:52 timotimo i constantly fuck it up and force jnthn to fix my mistakes ;_;
13:53 brrt msvc :-(
13:53 brrt anyway, yeah, pointer screwery is really handy
13:53 brrt i had no idea c++ didn't allow that
13:53 timotimo what?
13:53 timotimo c++ doesn't allow pointer arithmetic ?!?!
13:53 ShimmerFairy jnthn: I think gcc lets me get away with a mid-body declaration
13:54 brrt it does, but not as flexible (e.g. have to cast to and from void* and stuff)
13:54 ShimmerFairy C++ does, it's just frowned upon ("iterators" are generalized pointers, and you'd be wise to use them, as I understand it)
13:54 brrt iterators are not generalised pointes, what nonsense is that
13:54 brrt pointers are the generalised thing
13:56 ShimmerFairy brrt: I'd have to find it back, but IIRC the idea is that iterators support the same kinds of arithmetic pointers do (to varying extents based on the specific iterator), but they're more general than pointing to a memory address
13:57 ShimmerFairy "GNU dialect of ISO C90 (including some C99 features). This is the default for C code." <-- I think that's probably what lets me get away with in-body declarations
13:57 brrt but that assumes that i always want to iterate when i'm doing pointer arithmetic, which is not the case at all
13:58 brrt its an abstraction, but not a generalisation, imho :-)
13:58 ShimmerFairy well, you can dereference iterators just like pointers as well.
13:58 ely-se yay, I got it to work :)
13:59 timotimo cool
13:59 ShimmerFairy brrt: well, whatever the right word is, my understanding is that C++ iterators took a look at what pointers do and decided to run with it :)
13:59 timotimo looking forward to seeing what you come up with
13:59 ely-se Pointer arithmetic is an awful feature. It's UB if not within an array anyway, and there is x[n] and &x[n] already.
13:59 brrt well, i disagree with that :-)
14:00 brrt foo + x is much shorter than &foo[x]
14:00 brrt or cleaner, i think
14:01 brrt also, ((char*)foo)+sizeof(struct my_foo_struct)) to get the address beyond your struct? very nice imho
14:01 ShimmerFairy I actually don't run into the reinterpret_cast<> ugliness in C++ anymore, because I've since move on to converting bytes into multi-byte numbers in an platform-independent fashion
14:01 brrt actually, i mean foo + 1 to get the same
14:02 ShimmerFairy It's not nearly as nice as (uint16_t*)(foo)[0] , but I don't have to worry about flipping the endianness in the multi-byte number afterward :)
14:03 ely-se this works :) https://github.com/vlinder-lang/dexter/tree/master/src
14:03 brrt maybe C is just close to my mental representation of the program :-)
14:03 ely-se C++ \o/
14:03 brrt maybe not start a C/C++ discussion today :-)
14:04 ShimmerFairy brrt: I'm no stranger to thinking in low-level terms, I just find C++ really nice to whip up things in where speed is more of a concern :)  (can't say if it's nicer than C, because I've never really used it. C++ worked so I stuck with it :P)
14:05 ely-se I'd write this thing in Haskell but I don't like the idea of having two GCs in one program
14:08 ShimmerFairy out of curiosity, would it help moar if gcc and similar compilers were forced under -std=c90 (or whatever's appropriate) by default, so people on those compilers don't get away with writing too-new code?
14:08 brrt my suspicion is yes, that would help
14:08 brrt if you can make a PR that adds the appropriate flags to CFLAGS, i'd be more than happy to review it
14:11 ely-se my build system: printf 'includes:\n\techo \$(CINCLUDES)\n' >> vendor/MoarVM/Makefile
14:11 ShimmerFairy I don't suppose I could make a pull request without forking though, right? :/
14:12 ShimmerFairy (I really don't like the idea of forking when I'm not actually, well, forking the project)
14:13 brrt it's how github operates. you can also send in a patch
14:13 timotimo you can make pull-requests from inside the same project
14:13 timotimo no need to build a fork
14:13 brrt if you have a commitbit, that is, do you?
14:13 timotimo correct
14:14 ShimmerFairy I don't, and I wouldn't expect to get one without making contributions first :)
14:15 brrt well, just send in a patch if you don't want to fork
14:15 brrt i understand the hesitation. my own repo is also littered with forks of project to which i've done nothing
14:15 ShimmerFairy I'm well aware that's how github operates, I just think it's a crappy mode of operation :P  (It just seems really... superfluous to have forks appearing all over the place for the sake of a patch system)
14:16 ShimmerFairy brrt: I'll consider forking, but I'm not too keen on it. Especially the work I've done on MoarVM off in another branch already, that's likely going to be a pain to move into a fork if I decided to do so.
14:16 brrt github very probably does deduplication, of course
14:17 brrt no, not really, actually
14:17 brrt git remote add my_fork gitgithub.com/my-github-name/MoarVM.git
14:17 brrt git push -u my_fork my_branch
14:17 ShimmerFairy yeah, that's probably I would go about it :)
14:18 ely-se ooh wait, make has an --eval flags
14:18 ShimmerFairy Well, if I do decide to fork, then if I ever get a commitbit my first act will be to get rid of that fork :P
14:19 * ShimmerFairy will probably create a fork soon, that'll have history preservation advantages over patches
14:20 ely-se so I can just write this: make --eval=\$'includes:\n\techo \$(CINCLUDES)\n' includes
14:21 lizmat joined #moarvm
15:22 tgt joined #moarvm
15:23 tgt left #moarvm
15:53 TEttinger joined #moarvm
16:43 ely-se joined #moarvm
17:23 zakharyas joined #moarvm
17:32 ely-se Alright, got my build system to work!
17:57 ely-se joined #moarvm
19:19 zakharyas joined #moarvm
19:49 japhb joined #moarvm
20:10 dalek MoarVM/even-moar-jit: d00ae0c | brrt++ | src/jit/ (7 files):
20:10 dalek MoarVM/even-moar-jit: Minor fix in tiler, small additions
20:10 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d00ae0c8f2
20:12 brrt joined #moarvm
20:12 brrt good evening
20:13 brrt ok, i've tried to reconsider it as a graph problem, and got no further
20:21 timotimo :(
20:40 ely-se joined #moarvm
20:42 brrt i can probably figure out how to solve it if i just find *what* invariant must be held for me to generate all possible rulesets
20:44 brrt that's the great puzzle to me
20:44 * jnthn apologises for not being a better graph theorist...
20:44 jnthn I guess the paper gives no hints?
20:44 brrt well, no worries
20:44 brrt which paper?
20:45 jnthn No
20:45 jnthn The one that described tiling
20:45 brrt oh, no, doesn't
20:45 brrt hah
20:45 brrt if that paper described what i needed to know...
20:46 jnthn I guess dominance isn't helpful here?
20:46 brrt dominance? can you explain?
20:46 brrt it's not really a googleable term i think ^^
20:46 jnthn *lol*
20:46 jnthn It's the thing you compute during ssa
20:47 jnthn https://en.wikipedia.org/wiki/Dominator_(graph_theory)
20:47 brrt oh, i see
20:48 brrt hmmm
20:48 brrt maybe that has some applicability
20:48 jnthn (That's why SpeshBBs have dominance children :))
20:51 brrt hmm, no , doesn't look like what i mean
20:53 jnthn brrt: Is http://cs.nyu.edu/courses/fall04/G22.2130-001/burs.pdf any help?
20:54 brrt oh, maybe, hopefully
20:54 brrt it is the right algorithm
20:56 brrt cool, they have approached it much like me
20:58 brrt but i believe they don't have the single DFA table
20:58 brrt which is kind of desirable for a JIT
20:58 brrt because it means tiling a single node is always constant-time
21:02 brrt maybe i can convert the grammar to a trie
21:02 brrt hmmmm
21:07 brrt see you tomorrow, with hopefully a solution :-)
21:09 jnthn rest well, brrt++