github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 |
09:46 | |
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. |
10:46 | |
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:09 | |
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 |
12:52 | |
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:34 | |
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:45 | |
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. |
14:31 | |
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 | ||
yes. | |||
or I'm doing something daft | |||
jnthn | OK, so...now 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 | www.lspace.org/ftp/images/bookcove...ards-1.jpg | 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. |
15:20 | |
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. |
17:27 | |
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 |
22:42 | |
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 | |||
jnthn | .oO( they know what is what but they don't know what is what they just struct ) |
22:47 | |
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 |
23:12 | |
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]] | |||
whoopsie | |||
Geth | MoarVM/new-disp: 5dad1e4774 | (Timo Paulssen)++ | 2 files rough initial version of "run program against Args object" |
23:47 | |
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 |