| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:05 konvertex left 01:03 lucasb left 02:48 linkable6 left, evalable6 left 02:50 linkable6 joined 02:51 evalable6 joined 03:39 discoD left
nwc10 good *, #moarvm 06:41
timotimo hi 06:45
06:50 domidumont joined 07:31 MasterDuke joined 07:41 zakharyas joined
jnthn o/ 09:22
nwc10 \o 09:26
09:40 konvertex joined 09:44 Altai-man_ joined
Geth MoarVM/new-disp: e7b738fae2 | (Jonathan Worthington)++ | 2 files
Move initial capture into recording state
nwc10 jnthn: NQP is happy. SEGVs in optimize in the Rakudo core setting build - same place as before (I think) and I know that that's not yet interesting to you. 10:27
10:28 sena_kun joined 10:30 Altai-man_ left 10:42 squashable6 left 10:44 squashable6 joined
Geth MoarVM/new-disp: 77317336d3 | (Jonathan Worthington)++ | 3 files
Start recording capture transformations in a tree

And provide a means to get the path through the tree to a given capture too.
jnthn This one is a bit more interesting :)
11:07 MasterDuke left
Geth MoarVM/new-disp: d6716950dd | (Jonathan Worthington)++ | src/disp/program.c
Add debug dumping of dispatch recording captures

To see that what is happening is sensible (which, so far, it is).
11:42 zakharyas left 12:27 Altai-man_ joined 12:30 sena_kun left 12:51 zakharyas joined
Geth MoarVM/new-disp: 89d2dbbe99 | (Jonathan Worthington)++ | src/disp/program.c
Dump dispatch outcome too
MoarVM/new-disp: a70b9d211a | (Jonathan Worthington)++ | src/disp/program.c
Start recording literal values used in dispatch
MoarVM/new-disp: fda0676e1a | (Jonathan Worthington)++ | src/disp/program.c
Add dumping of values in dispatch record
12:56 brrt joined 13:04 MasterDuke joined
Geth MoarVM/new-disp: a247a5f6bb | (Jonathan Worthington)++ | 2 files
Track values used from initial arguments

This is a little tricky. When we have derived captures and inserted and dropped arguments, the indices need to be resolved back to those of the initial argument capture (or discovered to be an inserted argument, in which case we already know the value's source). We make value entries to indicate their usage also (and this is where we shall attach guards).
13:39 MasterDuke left
Geth MoarVM/new-disp: b2d89d0e06 | (Jonathan Worthington)++ | src/disp/program.c
Properly resolve tracked values in insert arg

So that we now set the correct value index.
13:57 MasterDuke joined 14:28 sena_kun joined 14:29 Altai-man_ left
Geth MoarVM/new-disp: 79ec298952 | (Jonathan Worthington)++ | 3 files
Check syscall args and add guards for them

Along with dumping of guarding requirements, so we can see that they are getting guarded as expected.
jnthn Yay, guards.
nwc10 jnthn: previous pushes all passed NQP's tests 14:32
will wait for that SEGV in Rakudo before trying this one
jnthn nwc10: Question: are you on the new-disp branch of NQP? I've just realized that you should be seeing two failures in t/moar/53-dispatch.t
nwc10 yes, I thought that I was 14:33
OK, but am I on today's?
commit d39df6de9b31b819dfe9f14a30b039a702c86910 (HEAD -> new-disp, origin/new-disp) 14:34
or I'm doing something daft
jnthn OK, I need to re-work how we represent outcomes a little bit 14:38
14:38 MasterDuke left
jnthn And then it's back to design work on how we'll represent dispatch programs for actually executing them. 14:38
Then integrating it with spesh 14:40
And by that point, I can have a go at replacing some of the Rakudo spesh plugins with the new dispatch mechanism
timotimo 14:57
[Coke] heh 14:58
Geth MoarVM/new-disp: 1ff7b66e9a | (Jonathan Worthington)++ | 3 files
Properly track outcomes in the recording

So we can understand it in terms of the captures and values in the recording.
jnthn Turns out the way we represented outcomes in general was fine, just that we need a bit of *extra* info in the record phase.
15:58 domidumont left 16:13 brrt left 16:16 Geth left 16:27 Altai-man_ joined 16:28 Geth joined 16:29 sena_kun left 16:48 MasterDuke joined 17:18 domidumont joined
Geth MoarVM/new-disp: 882ac57fa7 | (Jonathan Worthington)++ | 2 files
Sketch out data structure of dispatch program

This is the compiled form that we'll actually interpret, and turn into guard instructions and other bytecode instructions to further optimize in the case of spesh.
jnthn Now I "just" need to turn the recording data structure into this... 17:28
...and write the interpreter...
17:34 zakharyas left
Altai-man_ jnthn++ 17:44
timotimo i have experience writing interpreters for little domain-specific bytecode formats 18:24
jnthn: did you already start, or should i rough out an initial version for you?
18:25 hankache joined 18:28 sena_kun joined 18:30 Altai-man_ left
jnthn timotimo: Didn't start on the interp; feel free to have a go if the format is clear enough. It's not so much bytecode as a (hopefully decently compact) struct 18:39
tellable6 2020-05-28T18:33:05Z #raku <melezhik> jnthn RakuDist test fails for Spreadsheet::XLSX
timotimo if it's a struct it's more like the guard tree we already had in spesh i assume?
jnthn Yeah 18:40
If a guard fails, then we just say "nope"
For now, at least
It's not a tree for now, far more like the spesh plugin linear thing
The input is an MVMArgs
18:51 hankache left, lucasb joined
timotimo i'll have a look soon :) 18:58
19:03 zakharyas joined 19:25 domidumont left 20:21 sena_kun left, sena_kun joined 20:24 brrt joined 20:27 Altai-man_ joined 20:28 konvertex left 20:29 sena_kun left 20:37 zakharyas left 21:07 brrt left 22:28 sena_kun joined 22:29 Altai-man_ left
Geth MoarVM/new-disp: 7583f7f3c4 | (Jonathan Worthington)++ | 4 files
Compile guards into dispatch program
jnthn timotimo: Couple of new ops in there too 22:43
timotimo whee 22:45
i didn't have a look yet actually :o
except the structs, i looked at the structs
.oO( they know what is what but they don't know what is what they just struct )
22:53 sena_kun left
timotimo jnthn: the value_index_constant function would fall through the cases if the value doesn't match, but i think all the comparisons result in the same actual code 22:59
like, comparing a pointer vs comparing a 64bit integer vs a 64bit double etc
you could reuse a double that just so happens to equal an int, but it's probably a bad idea to accept a pointer that the GC may later move as literal value for an integer 23:02
jnthn timotimo: oops, yes 23:09
timotimo if you want i'll commit and push *shrug* :)
jnthn Go ahead :) 23:10
Geth MoarVM/new-disp: 08e2d7fe8f | (Timo Paulssen)++ | src/disp/program.c
Don't fallthrough different types in value_index_constant func
timotimo the programs being created in the one test file in nqp are pretty simple, that's not bad :D 23:13
as long as they're mostly just "check the concreteness of like two parameters" i don't even have to implement a mark function for programs
23:40 lucasb left
timotimo jnthn: the "run program" function would take an MVMArgs, would it literally write to that struct, or return a new MVMArgs object alongside the result somehow? 23:41
src/disp/program.c:831:36: error: stray ‘\257’ in program 23:44
831 | #define GET_ARG MVMRegister val =��args->source[args->map[op->arg_guard.arg_idx]]
Geth MoarVM/new-disp: 5dad1e4774 | (Timo Paulssen)++ | 2 files
rough initial version of "run program against Args object"
timotimo anyway, here's a simple interpreter that you can build upon 23:48
if you want me to, i'll also stub in the ops that aren't yet handled by dump_program (i haven't seen any in the output from dump_program yet)
ah, yes, they aren't "compiled" yet 23:50