00:00 Peter_R joined 04:42 pyrimidi_ joined 07:01 brrt joined
brrt \o 07:01
ok, i have finally arrived at a rather annoying answer
did you maybe recall that i reduced the time to create the rulesets by using a topological sort? 07:02
it's the right direction, i still think, but the wrong answer
because the grammar 'graph' has cycles
and topological sort clearly cannot function on a graph that has cycles
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:03
and combinations, meaning i can miss rulesets, meaning my tiling table is worthless 07:04
i'm currently working on a way arround that....
or rather
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
07:05 edsc joined
brrt so, :-(, but on the other hand, *I understand the problem again*, which is kind of important 07:06
does this actually happen? yes. there is a subtle other problem, relating to the 'chosen rule' in a table
07:22 ely-se joined 07:30 pyrimidine joined 07:44 edsc left
arnsholt brrt: What kind of grammar is it? 07:52
(That is, is it context-free, or something else?) 07:53
brrt ehm.. i suppose context-free?
arnsholt In that case, you might just want to CKY it 07:54
brrt CKY?
arnsholt Of course, CKY is O(n^3)
Cocke-Kasami-Younger. Bottom-up dynamic programming algorithm for matching CFGs
brrt oh, that one :-)
nah, that's not really acceptable 07:55
arnsholt Yeah, I figured
Most "normal" CFGs are parseable in linear time, though
But if you have some kind of cost factor, I'm not sure if that still holds
brrt hmmm 07:56
let me look at that
arnsholt Incidentally, for CFGs with cost, what you probably want to look for is probabilistic CFGs
ely-se what does parsing a CFG mean? 07:57
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
arnsholt Yeah, it's not quite the same 07:59
brrt and my problem isn't really generating matches but generating a matching table 08:02
:-)
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
that's the tiler :-)
it uses a DFA generated from the tiling grammar 08:04
it is generating the DFA - transition tables that i'm having something of a problem with
generating the table is simple enough, but it pre-requires knowing the combinations of rules that generatee rulesets 08:05
arnsholt Right, right
brrt wait, i'll make a gist of the pathological case
arnsholt In that case, you might just want to restructure your grammar 08:06
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:07
And regular languages are matched with [ND]FAs, of course 08:08
08:08 zakharyas joined
brrt sorry... what *exactly* is a terminal? i'm known to use these terms rather sloppiliy 08:08
and a nonterminal? 08:09
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
so if i have (foo reg) -> reg the non-terminal is the reg, the terminal is the (foo reg) ?
arnsholt I think, so, yeah 08:11
brrt gist.github.com/bdw/5fccd561f75bb4a185df is an example of the pathological case 08:13
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.
brrt arnsholt: s-expressions. 08:35
tile: declare tile
(tile: name (tree) nonterminal) 08:36
arnsholt Right. So "t (t) r" is means that an r can be replaced with a t, and it's named t? 08:38
ely-se Is there API documentation for MoarVM's C API? 08:40
Or is there no C API?
JimmyZ no doc ...
ely-se :O
jnthn ely-se: We've never specified one really, though anything with the marker MVM_PUBLIC is something we'd consider an "in"
ely-se amazing :3
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
jnthn ely-se: If it attracts wider interest that's fine.
ely-se: And it's surely nice for a lot more.
ely-se ok
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 :)
(In terms of doing other things)
The bytecode format is accurately documented, though (I've tried to keep that doc up to date)
ely-se oh nice
so I can generate bytecode and run it? 08:43
jnthn I don't see why not
ely-se instead of MAST
jnthn Sure, MAST just abstracts you from the bytecode format.
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
So you can re-create the MAST nodes in your own language if you wished.
But there bytecode format hasn't changed incompatibly much at all 08:45
*the
brrt arnsholt: that is correct, yes 08:48
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
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
and generate code that acts on those
jnthn Don't though...then spesh won't make sense of much at all :) 08:54
When I've had to do such things, the first shot was just treat registers like stack locations
brrt arnsholt: yes
jnthn r0 is stack location 0, r1 is stack location 1, etc.
brrt and, that's ok
jnthn Keep an array of those 08:55
brrt has no real idea how to translate from stackbased to registerbased code
jnthn You can then make stack loads from locals (if you have them) lazy to and get better code.
For my final year project at university, I worked on translating code from a stack to a register machine :) 08:56
ely-se nice!
jnthn So this problem I did have to ponder once :)
ely-se my compiler currently turns SSA into stack code, using a local variable for every SSA variable
brrt jnthn... what happens if you pop an integer and push an object (i.e. how to ensure pointer validity?)
ely-se so the generated code is absolutely awful
brrt oh, you use multiple arrays
ely-se but it works :p
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
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?
i mean you don't have to worry about register allocation, which is a huge timesaver :-)
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
brrt well, make different output :-)
or just generate MAST instead
'just\
' 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
JimmyZ CLI is stack? 09:00
ely-se CIL is stack-based, yes.
brrt like jvm, python, etc 09:02
lizmat: that was a really nice article, btw :-)
ely-se jnthn: do you know any articles on such a translation? 09:07
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
jnthn jnthn.net/papers/2006-cam-net2pir-d...tation.pdf 09:11
ely-se tailcalls may prove a challenge though :p
jnthn: thanks, I'll read it 09:16
brrt oh, really cool jnthn :-) 09:22
jnthn Be careful, I wrote that when I was 9 years more ignorant than now :) 09:24
brrt probably still a few years less ignorant than me today :-) 09:25
jnthn: if you could take a look at this, maybe you have an idea 09:26
gist.github.com/bdw/5fccd561f75bb4...anation-md
i'd be very happy :-)
jnthn OK, lemme grab another coffee... :)
(also, wait for my list assignment impl attempt to compile...) 09:27
ely-se jnthn: where can I find the bytecode docs? 09:30
brrt there are no bytecode docs... as far as i know 09:31
oh, that's not true
ely-se 10:42 < jnthn > The bytecode format is accurately documented, though (I've tried to keep that doc up to date)
brrt github.com/MoarVM/MoarVM/blob/docs/...e.markdown 09:32
github.com/MoarVM/MoarVM/blob/maste...e.markdown
ely-se oh, I thought the documents in that directory were obsolete
brrt why assume that?
ely-se readme 09:33
jnthn bytecode.markdown is the one I've been maintaining
brrt: looking
brrt thanks :-) 09:35
ely-se nice
why are things like mkdir instructions instead of functions? 09:40
brrt well, they're functions alright 09:42
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? :)
ely-se: Unlike many VMs that have two ways to invoke logic implemented by the VM, MoarVM has just one.
brrt see the file below. rule t1 is (tile: t1 (t) r)
ely-se ok
brrt and at2 is the 'generated rule' (t) -> t' which takes the place of the (t) in (a (t)) 09:44
make sense?
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.
ely-se very nice 09:46
jnthn brrt: I think I need to get the terminology straightened out a bit better in my head. :) 09:47
brrt: So, considering the first entry in x64.tiles: 09:48
(tile: load_stack (stack) reg 1)
tile: just says "it's a tile". load_stack is the name of it. How should I interpret the next 3 things?
brrt (stack) is the terminal (if i understand it correctly). that is, it represeents part of the input tree 09:49
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)
1 is the estimated cost according to some cost function i haven't really worked out very well yet
jnthn I guessed the 1 correctly at least :) 09:50
Lower is cheaper (and so preferable), yes?
brrt yes
it's basically, 1 for an instruction, 1 for using a register, 1 or two for an arithmetic operation, 4 for memory access
but not used very consistently yet
jnthn At the top of the file you have:
# Terminals: reg, mem, flag, void, expr, lab
Is this incomplete? 09:51
brrt that should be nonterminals
sloppy terminology from my part
jnthn That's like, the opposite man :P
brrt yeah
sorry about that :-)
jnthn So local and cu are actually terminals?
They can't expand to anything else? 09:52
brrt yes
no
jnthn OK, so
(tile: load_cu (cu) reg 1)
brrt matches (cu), yields reg, costs 1
jnthn Means "if you need to get the cu into a register, this is a good way to do it"
brrt yes 09:53
jnthn And considering: 09:54
(tile: add_reg (add reg reg) reg 2)
(tile: add_const (add reg (const)) reg 3)
The extra parens around (const) are because const is a terminal?
brrt well... ehm... yes 09:55
jnthn Or because it's a nested tree node to match?
brrt yes, that
jnthn (tile: load_mem (load mem) reg 5) 09:57
brrt and it expands to (add_const (add reg PLACEHOLDER) reg 1.5) and (placeholder (const) PLACEHOLDER 1.5)
jnthn What is "load mem" in this one?
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
jnthn ah, yeah, I see one generating a mem 09:58
brrt in the tile implementation, it generates a 'memory descriptor'
which can be placed virtually anywhere (part of x86 instruction set)
jnthn And load/store are...? 09:59
brrt the names of expression tree ops 10:00
(load mem) is a terminal
that refers to the mem nonterminal
jnthn OK
brrt (store mem reg) -> same story :-) 10:01
jnthn *nod*
brrt i.. am currently thinking i should rephrase the problem in terms of temrinal sets and coreduction 10:03
but that's not totally worked out yet
jnthn Yeah, we need a better way to talk about these things, I can see that :)
OK, so back to the problem at hand 10:04
foo.scm in your gist is the input we're considering?
brrt aye
i called it scm because that way github formats them nicely
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}
that one is included (called at1 :-))
jnthn I'd get somewhere faster with this is the names were a little more consistent :) 10:06
brrt sorry about that...
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
because there is no ruleset that only generates {a1} if applied to all rules starting with a
does that make sense?
jnthn Starting to... 10:13
jnthn is still missing a piece
brrt ok, which piece is that
:-)
jnthn So, we expand the rules as discussed 10:15
BUT that doesn't mean we consider the original rules "discarded" in some way
brrt ehm, no 10:16
well
eh
you mean like (add reg (const)) expanded to (add reg const') -> reg and (const) -> const', that expansion? 10:17
the original tree is actually kind of lost, yes
jnthn I mean:
# (tile: at1 (a (t)) r)
(tile: at2 (t) t')
(tile: at1 (a t') r)
The comment being what we started with, and the latter being the two things we expand it into 10:18
But then in the rule sets, you talk about a rule for (a (t))
brrt yeah, that one
yeah, that's actually the rule expanded to (a t'), what i mean 10:19
(i really should've talked more about this, that way other people might understand my thoughts a bit better)
jnthn So, in the rule sets 10:20
(s) -> {s1, as2}
brrt yes
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
in fact, *at any time* you see (s), s1 and as2 are equally applicable
only at the point you see (a s'), then you can decide
(clearly, in this case, the isolated (s) node is completely redundant. but let's not worry about that :-)) 10:22
jnthn OK, so considering
(a (t)) -> {a1, at1}
brrt yes
jnthn Would I be reading that in the light of the rename, or not? 10:23
As in, is it really
(a (t')) -> {a1, at1}
brrt that one is weird. what i mean by that is that (a (t)) can expand to (a r) or (a t')
because (r) can reduce (i think it's called to either of {r, t'}
i'm going to have lunch :-) be back in an hour or so 10:25
jnthn OK
brrt thanks for looking at it :-)
jnthn One of the oddities here 10:26
Is that topological sort is defiend on a DAG
brrt uhuh
jnthn But here you have a DCG
:)
brrt exactly
there you have my problem
anyway, i'm pondering on it over lunch :-)
10:26 brrt left 11:00 rurban_ joined
ely-se brrrr I just ate pure cocoa 11:07
arnsholt Mmmmm. Bitter =) 11:12
11:30 brrt joined
brrt lunched :-) 11:31
11:53 japhb joined
timotimo ohai 12:06
ely-se Is it possible to extend MoarVM with custom instructions? 12:31
jnthn ely-se: yes 12:33
ely-se: Rakudo does it
ely-se when I do that, do I have to write my own interpreter and JIT compiler for those instructions? 12:35
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.
ely-se oh, ok.
jnthn You can optionally also have the dynamic optimizer call you back
ely-se nice
jnthn So you can do stuff at optimization time 12:37
ely-se Is there documentation on that?
jnthn Though not currently specify what to JIT into; brrt++'s current work may well get us that
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
ely-se ok! thanks! 12:39
brrt jnthn: have you accidentally looked any further at it, or just any old thoughts about it? :-) 12:45
i'd be much obliged
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
brrt: Rather than trying to hack thing into a DAG
brrt yeah... i don't think there is
jnthn (e.g. DFS, BFS, etc.)
(Which just have a "seen" hash over the nodes, so cycles are fine)
brrt hmmmmmm 12:48
hmmmm 12:49
that... is not a bad idea at all
that makes sense
i think
jnthn I'm not clever enough to tell you which of the two you might want to try... :)
At least, not without pondering it a bunch more
And I'm also trying to untangle Perl 6's slicing bullcrap at the moment :/
brrt well, you should probably focus on that, then :-) 12:50
but thanks
that is already a huge help
jnthn OK, good :) 12:51
ely-se where should dynload.h come from? make says it can't be found 13:17
I'll install libffi 13:19
brrt not sure that's necessary?
oh, i think dynload.h is probably from the dyncall sources? you will want to -I${MOARVM_PREFIX}include/dyncall probably 13:20
in fact there are a few such directories you'll want on the search path
jnthn ely-se: Are you trying to build MoarVM itself, or your extension ops? 13:21
ely-se MoarVM
as a library
brrt hmm....
make libmoar.so :-)
*should* just work
what platform are you on
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
here's the full output: gist.github.com/rightfold/1a5555c2eb3d5e2ef3d1 13:23
brrt ehm.. can you do a git submodule init followed by a git submodule update? 13:24
ely-se <3 13:26
it worked! :D
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
according to your output, that is
ely-se: try make -j4 for faster builds
ely-se it already built :p 13:29
brrt dunno who did write the moarvm makefile, but it parallelizes quite nicely 13:30
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:31
ShimmerFairy when complining moar, make NOISY=1 will get you the actual lines used to compile 13:33
brrt actually, rakudo knows about it 13:34
so that may be the simplest way to do it
jnthn You may be able to get nqp to spit out the info 13:35
nqp --backend-config or so
brrt otherwise, you can make a Makefile target that says what_are_my_flags: echo $(CFLAGS)
ely-se ah, CINCLUDES 13:36
brrt moar::ccincludes
from nqp-m --show-config 13:37
nqp-m --show-config | grep cincludes | cut -c 18-1000
ely-se I'll make my build system append such a rule to the Makefile :p 13:38
brrt nqp-m --show-config | grep cincludes | perl -pe 's/^.+= //' 13:39
also works
ely-se this works :) gist.github.com/rightfold/603b66a516acf15d95c8 13:40
I'll find a workaround for the void* assignment, probably -fpermissive or somethnig
jnthn Yeah; please don't try and convince us to make the MoarVM codebase valid C++ also :) 13:41
It's hard enough to keep it in a dialect of C that compiles on all the targets. :)
brrt NO
ely-se I'll probably just write some glue in C
brrt nobody takes my void* away from me
jnthn And I decided against writing the VM in C++ for a reason :)
Well, multiple. :)
brrt what reason was that, by the way
*reasons were those
not arguing against it, just pointing out that e.g. v8 is written in C++ and works well enough 13:42
btw, did you perchance see the design document of the interpreter the v8 guys want to build
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
so that would've been a problem with c++, for me 13:44
ShimmerFairy what, that you don't know it? :)
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:47
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: github.com/sehe/mill/tree/develop/mill/src
a *very old* one; I rewrote it after that fork
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: github.com/tomalakgeretkal/mill/tr...p/mill/src :)
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:50
jnthn ShimmerFairy: No because MSVC 13:52
And the delcaration one is *really* annoying :/
timotimo i constantly fuck it up and force jnthn to fix my mistakes ;_;
brrt msvc :-( 13:53
anyway, yeah, pointer screwery is really handy
i had no idea c++ didn't allow that
timotimo what?
c++ doesn't allow pointer arithmetic ?!?!
ShimmerFairy jnthn: I think gcc lets me get away with a mid-body declaration
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)
brrt iterators are not generalised pointes, what nonsense is that
pointers are the generalised thing
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:56
"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
its an abstraction, but not a generalisation, imho :-) 13:58
ShimmerFairy well, you can dereference iterators just like pointers as well.
ely-se yay, I got it to work :)
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 :)
timotimo looking forward to seeing what you come up with
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.
brrt well, i disagree with that :-)
foo + x is much shorter than &foo[x] 14:00
or cleaner, i think
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
brrt actually, i mean foo + 1 to get the same
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:02
ely-se this works :) github.com/vlinder-lang/dexter/tree/master/src 14:03
brrt maybe C is just close to my mental representation of the program :-)
ely-se C++ \o/
brrt maybe not start a C/C++ discussion today :-)
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:04
ely-se I'd write this thing in Haskell but I don't like the idea of having two GCs in one program 14:05
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
if you can make a PR that adds the appropriate flags to CFLAGS, i'd be more than happy to review it
ely-se my build system: printf 'includes:\n\t@echo $(CINCLUDES)\n' >> vendor/MoarVM/Makefile 14:11
ShimmerFairy I don't suppose I could make a pull request without forking though, right? :/
(I really don't like the idea of forking when I'm not actually, well, forking the project) 14:12
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
no need to build a fork
brrt if you have a commitbit, that is, do you?
timotimo correct
ShimmerFairy I don't, and I wouldn't expect to get one without making contributions first :) 14:14
brrt well, just send in a patch if you don't want to fork 14:15
i understand the hesitation. my own repo is also littered with forks of project to which i've done nothing
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)
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
no, not really, actually 14:17
just add your fork as a remote
git remote add my_fork [email@hidden.address]
git push -u my_fork my_branch
tada!
ShimmerFairy yeah, that's probably I would go about it :)
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
ShimmerFairy will probably create a fork soon, that'll have history preservation advantages over patches 14:19
ely-se so I can just write this: make --eval=$'includes:\n\t@echo $(CINCLUDES)\n' includes 14:20
14:21 lizmat joined 15:22 tgt joined 15:23 tgt left 15:53 TEttinger joined 16:43 ely-se joined 17:23 zakharyas joined
ely-se Alright, got my build system to work! 17:32
17:57 ely-se joined 19:19 zakharyas joined 19:49 japhb joined
dalek arVM/even-moar-jit: d00ae0c | brrt++ | src/jit/ (7 files):
Minor fix in tiler, small additions
 20:10
20:12 brrt joined
brrt good evening 20:12
ok, i've tried to reconsider it as a graph problem, and got no further 20:13
timotimo :( 20:21
20:40 ely-se joined
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:42
that's the great puzzle to me 20:44
jnthn apologises for not being a better graph theorist...
I guess the paper gives no hints?
brrt well, no worries
which paper?
your dissertation?
jnthn No 20:45
The one that described tiling
brrt oh, no, doesn't
hah
if that paper described what i needed to know...
jnthn I guess dominance isn't helpful here? 20:46
brrt dominance? can you explain?
it's not really a googleable term i think ^^
jnthn *lol*
It's the thing you compute during ssa
en.wikipedia.org/wiki/Dominator_(graph_theory) 20:47
brrt oh, i see
hmmm 20:48
maybe that has some applicability
jnthn (That's why SpeshBBs have dominance children :))
brrt hmm, no , doesn't look like what i mean 20:51
jnthn brrt: Is cs.nyu.edu/courses/fall04/G22.2130-001/burs.pdf any help? 20:53
brrt oh, maybe, hopefully 20:54
it is the right algorithm
cool, they have approached it much like me 20:56
but i believe they don't have the single DFA table 20:58
which is kind of desirable for a JIT
because it means tiling a single node is always constant-time
maybe i can convert the grammar to a trie 21:02
hmmmm
see you tomorrow, with hopefully a solution :-) 21:07
jnthn rest well, brrt++ 21:09

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!