|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:26
lucebac0 joined,
lucebac0 left
00:42
ggoebel_ left
00:48
rootnode joined,
rootnode left
01:09
Kaypie left
01:22
lizmat left
01:33
zakharyas joined
01:34
p6bannerbot sets mode: +v zakharyas
01:38
ggoebel_ joined,
p6bannerbot sets mode: +v ggoebel_
01:57
onnex2 joined,
onnex2 left
02:12
ZzZombo left
02:28
Seju joined,
Seju left
02:47
samulihs8 joined,
samulihs8 left
02:53
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
03:02
tcunha22 joined,
tcunha22 left
03:29
MasterDuke left
04:22
ggoebel_ left
05:07
HisShadow_3 joined,
HisShadow_3 left
06:19
patrickb joined,
p6bannerbot sets mode: +v patrickb
06:27
robertle joined
06:28
p6bannerbot sets mode: +v robertle
06:33
domidumont joined
06:34
p6bannerbot sets mode: +v domidumont
06:40
ggoebel left
06:41
robertle left
06:53
ggoebel joined
06:54
p6bannerbot sets mode: +v ggoebel
07:27
sgallagh15 joined,
sgallagh15 left
07:33
brrt joined
07:34
p6bannerbot sets mode: +v brrt
|
|||
| brrt | \o | 07:35 | |
|
07:39
ZzZombo_ joined,
p6bannerbot sets mode: +v ZzZombo_
|
|||
| brrt | .ask timotimo if the work on the spesh 'comments' ever got anywhere | 07:40 | |
| yoleaux | brrt: I'll pass your message to timotimo. | ||
|
07:41
ZzZombo left,
ZzZombo__ joined,
ZzZombo__ is now known as ZzZombo,
p6bannerbot sets mode: +v ZzZombo
07:44
ZzZombo_ left
|
|||
| brrt | oh, that is in postrelease-opts, I see now | 07:48 | |
|
07:53
lizmat joined
07:54
dogbert17 left,
p6bannerbot sets mode: +v lizmat
|
|||
| masak | is there a good design document on 6model floating around somewhere? or a set of blog posts? | 07:57 | |
| suddenly I have a great thirst for knowing the intricate details about vtables and reprs | |||
| samcv | masak: there's stuff in docs/ there might be something useful there | ||
| maybe some blogs but i don't know any on the top of my head | |||
| masak | samcv: ta, I'll start there | ||
| nine | Note to self: when you look at a hexdump of some MoarVM bytecode and think "ah, of course, it's using the wrong opcode there!" you should probably take a bit of a break... | 08:02 | |
| masak | ah, there's a docs/6model/ directory in the perl6/nqp repo. that looks like a good start. | 08:04 | |
| jnthn | masak: Also read 6model.h, which has the key data structures | 08:14 | |
|
08:23
popey19 joined,
popey19 left
|
|||
| nine | All tests successful. | 08:25 | |
| masak | jnthn: ah, d'oh, yes -- I will. | ||
| nine | NQP's test suite passes with my MoarVM::BytecodeWriter plugged into assemble_and_load :) | ||
| masak | jnthn: ooc, and since you probably know offhand -- has 6model.h gone through any significant change since you designed 6model back in 201*mumble*? | 08:26 | |
| samcv | jnthn: also. so i am now doing what perl 5 does and utf16be and utf16le i pass through a BOM (don't expect one). and on utf16 it removes the BOM if it exists when reading and does encoding detection | 08:27 | |
| but if we *write* to utf16 then we don't get any BOM. but then again writing to a file never actually worked. but also they both use .encode | |||
| so can we change it so that .encode adds a BOM? or what. or only writing to a file(though that would be more work but maybe i could do it?) | 08:28 | ||
| but i don't like how we can write a file on one perl6 machine and then on another of a different endianess it will read wrong if you try and read it... | |||
| jnthn | nine: omg...wow! | 08:35 | |
| masak: Not really; the most significant addition was the parametric extensions. | 08:36 | ||
| samcv: I think we can change it to add the BOM | |||
| samcv: There's slight back-compat concerns but given we were missing the streaming decoder for it even, well, I think usage was probably quite low :) | 08:37 | ||
| What does "pass through a BOM" mean exactly? | |||
| lizmat | jnthn: I think the main need was to be able to read utf16, specifically for Text::CSV like applications | 08:41 | |
|
08:42
brrt left
|
|||
| jnthn | Righty, what was I going to work on next... | 08:42 | |
| ah, the thingy dogbert found... | 08:43 | ||
| uff, that's a big frame... | 08:45 | ||
| samcv | jnthn: well if it has a BOM and you read using utf16le you get zero width no-break space. which is what the standard says and what perl 5 does | 08:51 | |
| though iconv will drop the BOM assuming it's a BOM | |||
| jnthn | Ah, I see | ||
| samcv | also should "foo".encode have a BOM? i want to say no | ||
|
08:51
dogbert2 joined
|
|||
| jnthn | What's the argument for it not having one? | 08:52 | |
| samcv | concatenating strings | ||
| "foo".encode you might not want to write it directly to a file | |||
|
08:52
p6bannerbot sets mode: +v dogbert2
|
|||
| samcv | since .encode isn't working on a file just a string | 08:53 | |
| dogbert2 | o/ | ||
| jnthn | What will .decode do? | ||
| samcv | well probably what it does now. but i guess my point is that .encode is an isolated fragment, while if we write to a file we know that's the start | 08:54 | |
| i mean if you did $fh.write: "hello".encode('utf16') it's gonna have a bom. but i mean we *could* do that. and just have it documented you should probably do 'utf16le' or utf16be if you're doing fragments | 08:55 | ||
| jnthn | Hmm...yeah, that'll be a bit of a trap | ||
|
08:56
brrt joined,
p6bannerbot sets mode: +v brrt
|
|||
| lizmat | .oO( claymore ) |
09:02 | |
| dogbert2 | jnthn: if you get bored with the big frame I can offer a SEGV instead :) | ||
| jnthn | I think the problem with the big frame is that it has multiple `return` instructions and we mis-handle that | 09:10 | |
| (Produce invalid SSA form) | 09:11 | ||
|
09:12
Spritz3 joined,
Spritz3 left
|
|||
| jnthn | Since we just rewrite the return instruction into a set to the invoke register, but...if there's two such rewrites both will write the same location | 09:13 | |
| Well, same version | |||
| And then the DU chain checker is rightly upset | |||
| The only place we code-gen anything of this form is in regexes | 09:14 | ||
| (at the moment) | |||
| dogbert2 | is it fixable? | 09:19 | |
| jnthn | Well, the super-easy fix is just to refuse to inline such things, which is easy | 09:20 | |
| but...means we can't inline such things :) | |||
| dogbert2 | which would be a bit sad :) | ||
| jnthn | A bit, though it's not super common (otherwise we'd know about it :)) | ||
| Or at least, know about it a lot more :) | 09:21 | ||
| brrt | nine++ cool! | ||
| jnthn | The proper way to do it is to generate new versions of the target and then insert a PHI | ||
| dogbert2 | are you leaning towards the latter approach | 09:22 | |
| jnthn | Yeah, think so. It'll only come back as a task to fix a missed opportunity to inline in the future :) | 09:23 | |
| The next question after that is how to factor it. | |||
| I guess a PHI is free (goes away at code-gen time) so we could just always insert it | 09:26 | ||
| Which is cleaner than trying to keep state around for if we already rewrite a return and patch things up afterwards | 09:27 | ||
| dogbert2 | it will be interesting to see how postrelease-opts affects [Tux] csv benchmark | 09:47 | |
|
09:55
ZzZombo left
|
|||
| jnthn tests the fix | 09:57 | ||
| It's kinda more elegant this way, because before if there was more than one return then we just didn't try and propagate facts out of the inlinee, whereas now we just let the normal phi facts merge take care of it | 10:00 | ||
|
10:02
b-jazz4 joined,
b-jazz4 left
|
|||
| jnthn | tests well | 10:03 | |
|
10:09
domidumont left
|
|||
| timotimo | we must not forget that you can also write to/open files at non-0 offsets | 10:09 | |
| yoleaux | 07:40Z <brrt> timotimo: if the work on the spesh 'comments' ever got anywhere | ||
| Geth | MoarVM/postrelease-opts: 8aaf696a32 | (Jonathan Worthington)++ | src/spesh/inline.c Fix SSA handling of inlinees with multiple return Generate new SSA versions for each return point, and then merge then at a PHI placed after the inlinee. This potentially offers better facts for optimization in such cases, since before we propagated no facts out of the routine if there was multiple object returns, whereas now we let PHI fact merging identify commonalities. Further, we now propagate facts from non-object return values too. |
||
| jnthn | dogbert2: And you had a SEGV? | 10:11 | |
|
10:16
brrt left
10:21
brrt joined,
p6bannerbot sets mode: +v brrt
|
|||
| brrt | so. do we think we can merge fork-safety prior to the release, or shall we do it after? | 10:32 | |
| lizmat | I would suggest after | 10:35 | |
| AlexDaniel just did a toast run | 10:36 | ||
| AlexDaniel` | yeah, after | 10:37 | |
| nine | The spectest failures I get seem to be about bytecode validation errors which depend solely on frame size. That's intriguing | 10:38 | |
| brrt | fine, after it is | 10:42 | |
| nine: where (if anywhere) are you hosting your work? I'd like to take a peek :-) | 10:43 | ||
| Geth | MoarVM/nqp-mbc: e5fd915624 | (Stefan Seifert)++ | 9 files Add the buffertocu op |
||
| MoarVM/nqp-mbc: b50afaf7ae | (Stefan Seifert)++ | 6 files First stab at a writedouble op |
|||
| MoarVM/nqp-mbc: 7b5da981f0 | (Stefan Seifert)++ | tools/update_ops.p6 Fix MVM_operand_type_mask in lib/MAST The old mask was not extended when unsigned types were added. |
|||
| nine | brrt: there you go :) same branch in nqp | ||
|
10:45
zakharyas left
|
|||
| brrt | cool :-) | 10:45 | |
| thanks | 10:46 | ||
| dogbert2 | jnthn: yes I have a SEGV | 10:50 | |
| jnthn: try this gist.github.com/dogbert17/23b5e847...c582760963 | 10:51 | ||
| jnthn | oh, that one | 10:52 | |
| Yeah, I'll leave that for now...it's not new, and it's quite a time sink.. | |||
| dogbert2 | aha | ||
| in that case I'm not sure that I have anything else | 10:53 | ||
| heh, suddenly I'm unable to repro the SEGV | 10:55 | ||
| jnthn | You saw it after yesterday's GC fix, I presume? | 10:56 | |
| dogbert2 | yes | 10:57 | |
| but not after your SSA fix | |||
| perhaps I'm doing something wrong :) | 10:58 | ||
| dogbert2 reverts jnthn's latest fix and tries again ... | 10:59 | ||
| nah, can't reproduce it atm :( | 11:19 | ||
|
11:27
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
11:41
Kaiepi joined
11:42
p6bannerbot sets mode: +v Kaiepi
11:51
brrt left
12:15
ggoebel_ joined
12:16
p6bannerbot sets mode: +v ggoebel_
12:48
brrt joined,
p6bannerbot sets mode: +v brrt
|
|||
| [Coke] | What's the plan on merge timelines? | 13:18 | |
| jnthn | 1) Release. 2) Merge all the things. | 13:19 | |
| :P | |||
| nwc10 | Octopus merge! | 13:21 | |
| nine | The bytecode validation errors seem to occur when there are more than 4685 locals in a frame | 13:23 | |
| jnthn | m: say 4685.base(16) | 13:24 | |
| camelia | 124D | ||
|
13:30
patrickb left
|
|||
| [Coke] | cool. | 13:33 | |
| nine | Nah, looks to be more about bytecode size. When I turn the 4685 variables into int typed ones, the bytecode becomes smaller and I can raise the limit. The bytecode size limit is eerily close to 2^16 but it seems to be slightly above that. | 13:50 | |
| LOL and there it is: 'write_uint32_at', method (uint32 $i, uint16 $pos) | 13:52 | ||
|
13:57
andries5 joined,
andries5 left
|
|||
| nine | Aaaaand spectest passes :) | 14:01 | |
| lizmat | whee! | 14:21 | |
| [Coke] | ten! | 14:24 | |
|
14:35
ggoebel_ left
|
|||
| japhb | Awesome, nine++! | 14:49 | |
| Actually, very happy to see *three* very cool branches ready to go in | 14:50 | ||
| brrt | unfortunately all of them add new ops, so merge conflicts abound | 14:58 | |
| we'll manage though :-) | |||
| jnthn | It's easy, just run the update_ops.p6 :) | 15:15 | |
|
15:16
ggoebel_ joined
15:17
p6bannerbot sets mode: +v ggoebel_
15:24
indutny8 joined,
indutny8 left
15:49
fgau25 joined,
fgau25 left
15:56
brrt left
15:57
lizmat left,
domidumont joined
15:58
p6bannerbot sets mode: +v domidumont
16:15
AlexDaniel left
16:19
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
17:01
avar left
17:03
avar joined,
avar left,
avar joined,
p6bannerbot sets mode: +v avar
|
|||
| japhb | jnthn: Does that deal with merge conflicts automatically? | 17:10 | |
| [Coke] | more "ignore them and just redo that file." | 17:16 | |
| diakopter | obviously doesn't work if any branch re-bootstraps | 17:19 | |
|
17:27
brrt joined
17:28
p6bannerbot sets mode: +v brrt
17:31
W6MCN8 joined,
W6MCN8 left
17:35
bisectable6 left,
bisectable6 joined
17:36
p6bannerbot sets mode: +v bisectable6
|
|||
| jnthn | japhb: Well, it means that if you resolve conflicts in oplist (if any) then you just regenerate the rest. It doesn't do any magic like `git add` of the things it generates, though. | 17:36 | |
| nine | The final missing bit for using my bytecode writer in assemble_to_file is writing the serialized data. There doesn't seem to be a way to access it from NQP however | 17:42 | |
|
17:45
bisectable6 left,
bisectable6 joined
17:46
p6bannerbot sets mode: +v bisectable6
17:50
lizmat joined
17:51
p6bannerbot sets mode: +v lizmat
17:57
brrt left
18:03
brrt joined
18:04
p6bannerbot sets mode: +v brrt
|
|||
| nine | Or maybe there is... nqp::serialize seems to return a "string" with the serialized data | 18:12 | |
| But not "when we're in the compiler pipeline". I wonder when it would be called outside the compiler? | 18:14 | ||
|
18:16
avar left
18:22
avar joined,
avar left,
avar joined,
p6bannerbot sets mode: +v avar
19:07
domidumont left
19:13
xificurC joined,
xificurC left
19:16
brrt left
19:33
kierank20 joined
19:34
kierank20 left
19:59
tomreyn17 joined
20:00
tomreyn17 left
20:34
Milt`n0 joined,
Milt`n0 left
21:19
ggoebel_ left
21:40
Ragnor18 joined,
Ragnor18 left
|
|||
| timotimo | you know, we could have an sp_index for when the needle is spesh-time-known and have a little cache for the advance/skip/whatever table | 22:02 | |
| though i think if the needle is short, like for example \", it won't be big at all? | |||
|
22:22
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke,
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
23:56
ggoebel_ joined
23:57
p6bannerbot sets mode: +v ggoebel_
|
|||