| timotimo | no, that's some unrelated process overwriting a piece of an object's header | 00:17 | |
| usually when you write past the end of one object you'll corrupt the header of the next object | |||
| samcv | ah | 01:34 | |
| the weird thing is that in this case it's crashing when it returns early. meaning before it even starts writing any extra data to places | 01:35 | ||
| so i don't know how my code could be messing something up since it returns early and it returns a string made by another function | 01:37 | ||
| MasterDuke | valgrind say anything? | 01:46 | |
| samcv | hmm let me try | 01:50 | |
| it doesn't appear to have any issues when i run the pertinent code section by itself | 02:03 | ||
| "\r" ~ "\n" | |||
| oh forgot valgrind prints out a ton of stderr | 02:04 | ||
| MasterDuke | .tell jnthn clang complains about src/6model/reprs/VMArray.c:307 `if (n < 0)`, that 'comparison of unsigned expression < 0 is always false'. n is an MVMuint64, can the check be tossed? | 02:16 | |
| yoleaux | MasterDuke: I'll pass your message to jnthn. | ||
| samcv | MasterDuke, well all the valgrind stuff is in the gc code it seems | 02:25 | |
| MasterDuke, gist.github.com/samcv/5dc340abfb93...668de84396 | 02:27 | ||
| hmm tho i guess something else could trigger hm | 02:28 | ||
| no clue what. it doesn't make that much sense to me | |||
| i'm gonna turn on strand debug | 02:29 | ||
| same error | |||
| well before (26440 errors from 5 contexts) after (26425 errors from 5 contexts) | 02:34 | ||
| before as in master and after is my branch | |||
| and lost the same number of bytes | |||
| MasterDuke | do you get the same valgrind output on master? | 02:48 | |
| samcv | hmm i do get something | 03:13 | |
| well i get no valgrind output if i run it on the problematic file | |||
| ok yes i do see some new stuff | 03:27 | ||
| gist.github.com/samcv/91c9959d0a6b...84b74c541f seems to malloc and not free | |||
| and conditional jump or move depends on uninitialized values | 03:28 | ||
| MasterDuke | whoops | ||
| samcv | ah i found one memory leak | 03:32 | |
| MasterDuke | "gotta catch'em all!" | 03:34 | |
| samcv | heh | ||
| :) | 03:35 | ||
| MasterDuke | i'm off to bed again, good luck | 03:37 | |
| samcv | no memory leaks with my code anymore but still those jump errors i have no clue what causes them | ||
| yayyyyy | 04:03 | ||
| it's now passing that one :) | 04:04 | ||
| so the only file failing is t/spec/S17-supply/lines.t with 4 tests failing all of them are about handling chunked lines | 04:19 | ||
| oddly all the rest of roast passes perfectly. i'm not sure what is different about the chunked lines that might make it fail magically but pass every other concat test i have | 04:20 | ||
| m: "a\nb\r\nc\rd\n\neeee".lines.perl.say | 04:28 | ||
| camelia | ("a", "b", "c", "d", "", "eeee").Seq | ||
| samcv | huh. that... the test is wrong maybe | ||
| either that or that result is wrong | 04:29 | ||
| the test is looking for ['a','b',"c\rd","", 'eeee'] | |||
| only diference is the string is delivered through a supply which has .lines called on it but i see no reason the result shuold differ | |||
| if it's through a supply or not | 04:30 | ||
| m: "a\n" "b\r\n" "c\rd\n" "\n" "eeee" though i'd also think it should go like this so the test is right? hm | |||
| camelia | ===SORRY!=== Error while compiling <tmp> Two terms in a row at <tmp>:1 ------> "a\n"ā "b\r\n" "c\rd\n" "\n" "eeee" though i'd expecting any of: infix infix stopper statement end statementā¦ |
||
| samcv | but hm | ||
| bisectable6, "a\nb\r\nc\rd\n\neeee".lines.perl.say | 04:31 | ||
| bisectable6 | samcv, On both starting points (old=2015.12 new=8d5f332) the exit code is 0 and the output is identical as well | ||
| samcv, Output on both points: Ā«("a", "b", "c", "d", "", "eeee").SeqĀ» | |||
| samcv | where does that \r go though | ||
| m: "a\nb\r\nc\rd\n\neeee".split(["\r\n", "\n"]).perl.say | 04:32 | ||
| camelia | ("a", "b", "c\rd", "", "eeee").Seq | ||
| samcv | hmm weird though the result i get | 04:42 | |
|
04:50
vendethiel joined
05:51
vendethiel- joined
|
|||
| samcv | ok with enough printf's i think i figured out what is occuring. it's not adjusting one of the graphemes right | 06:03 | |
| i mean. it says it is as it prints it out. but when i dump the final string it has an extra ord | |||
|
06:10
brrt joined
|
|||
| samcv | ok so the issue was i needed to move the strands down one in certain cases. so now i have done that and that test passes. now to run full spectest again :) | 06:43 | |
| brrt | \o/ | 06:51 | |
| good * samcv | |||
| samcv | good * :) | 07:01 | |
| ok only failing 2 tests now | 07:02 | ||
| anddd full spectest pass! | 07:09 | ||
|
07:16
brrt joined
|
|||
| brrt | i can't seem to get the final bits of the 'optimistic store insertions' in place | 07:30 | |
| because of the wrapping stuff | |||
| samcv | wrapping? | 07:34 | |
| brrt | glad you asked :-) | 07:45 | |
| okay, so you maybe know that the 'expression' compiler starts of by converting a basic block into a tree of expressions by means of templates | 07:46 | ||
| most operations map in a straightforward way | 07:47 | ||
| however, some operations are annotated in some way, causing them to have some special significance | |||
| for instance, an operation may represent the start of end of a frame handler, or maybe the start and end of an inline, etc. | 07:48 | ||
| some operations need to invoke a new (possibly interpreted) subroutine | |||
| and some operations may cause an exception to be thrown | 07:49 | ||
| makes sense? | |||
| so when that happens, we may need to wrap labels around the compiled code | 07:50 | ||
| or we may need to wrap special checks to interrupt execution when the code inbetween may have caused an exception to be thrown | 07:53 | ||
|
07:55
domidumont joined
07:56
robertle joined
|
|||
| brrt | now, the legacy JIT has to insert laods and stores for every operation because it can't look at two operations at the same time | 07:57 | |
| the new JIT can, and I want it to not insert stores if not needed | |||
| (when is it 'not needed'? that depends, but mostly when we can prove the value isn't used after, which is easiest if it is overwritten in the same basic block, and there isn't something that would use it in the meantime) | 07:58 | ||
| so, i now have a 'flush' primitive implemented, which is what i want to extend to do this 'lazy' store insertion | 07:59 | ||
| the complexity is mostly arround how that interacts with another mechanism, which is 'rooting' | |||
|
08:01
zakharyas joined
|
|||
| brrt | in which i maintain a series of 'roots' that maintain the order of evaluation / compilation for the tre | 08:01 | |
| so, basically, i maintain a set of currently used values | 08:02 | ||
|
08:02
domidumont joined
|
|||
| brrt | when we need a value (that we'd load from memory), we first check if it has already been computed/loaded, and if it has, we reference that instead | 08:02 | |
| that gets rid of the duplicate loads | |||
| what i want to do is that when a value is computed, we insert a reference to the result of that computation, but we don't issue the STORE just yet | 08:03 | ||
| when we have to flush to memory, we iterate over this set and issue the stores | |||
| adding a STORE means creating a new node that wraps the value (with the store), and replacing the root that refered to the old computation with the node that refers to the store | 08:04 | ||
| samcv reads :)) | 08:06 | ||
| very interesting :) thank you | 08:07 | ||
| brrt | :-) | 08:29 | |
| anyway, wrapping 'guards' also works by replacing the computed node with a GUARD node | 08:30 | ||
| obviously, we can't STORE the GUARD node because it doesn't yield a value | |||
|
08:55
lizmat joined
|
|||
| brrt | it would also be bad, for instance, if we replace the root that refered to the GUARD to one refering to a STORE | 08:58 | |
| Geth_ | MoarVM: b28eb23530 | (Samantha McVey)++ | src/strings/nfg.c Fix memory leak in MVM_nfg_is_concat_stable MVM_unicode_normalizer_cleanup was mistakenly not called before returning. |
09:32 | |
| MoarVM: 03c8034b12 | (Samantha McVey)++ | 2 files Rename relative_ccc to MVM_unicode_relative_ccc Rename so we can use in MVM_nfg_is_concat_stable. |
|||
| MoarVM: 68d9ec4415 | (Samantha McVey)++ | src/strings/nfg.c If both last_a and first_b during concat are non-0 CCC re_nfg Although I haven't been able to trigger a condition which would cause incorrect concatenation |
|||
|
09:57
zakharyas joined
10:09
vendethiel joined
10:55
lizmat joined
11:19
brrt joined
11:29
brrt joined
11:55
lizmat joined
12:54
nebuchadnezzar joined
|
|||
| Geth_ | MoarVM: 4b87b0288f | (Jonathan Worthington)++ | 10 files Add a decodertakecharseof op. A variant of decodertakechars that finishes decoding/normalizing any content in the buffer before taking the chars. |
13:05 | |
|
13:44
lizmat joined
14:14
lizmat joined
15:03
domidumont joined
|
|||
| Geth_ | MoarVM: e5f22faa51 | (Jonathan Worthington)++ | src/strings/decode_stream.c Copy correct length in get_all_in_buffer. We calculated the size to copy, but then ignored it, resulting in sometimes copying off the end of the buffer. |
15:04 | |
| jnthn | That gets rid of the various invalid read/write in github.com/MoarVM/MoarVM/issues/611 | 15:05 | |
| And replaces them with an invalid free :P | |||
| dogbert17 | oh no :) | 15:06 | |
| jnthn | That may well have been there before anyway | ||
| lizmat | .oO( go back to jail, you do not receive 200 US$ ) |
15:07 | |
| jnthn | ah, d'oh | 15:10 | |
|
15:12
brrt joined
|
|||
| jnthn | Turns out we could make an MVMString whose buffer pointed to the middle of some malloc'd memory | 15:17 | |
| lizmat | yikes | 15:18 | |
| jnthn | Spectesting now | ||
| timotimo | whoops, that'd do it :) | 15:22 | |
| Geth_ | MoarVM: 198c72ba1d | (Jonathan Worthington)++ | src/strings/decode_stream.c Don't make string pointing into middle of buffer. This was due to a thinko when introducing an optimization that allows an existing decode buffer to be used directly as the string body. |
15:23 | |
| jnthn | Think the other one goes back much further | 15:24 | |
| Geth_ | MoarVM: eea7fd9328 | (Jonathan Worthington)++ | src/core/interp.c Fix ctxcode op to not leak a NULL. |
15:34 | |
| jnthn | That's github.com/MoarVM/MoarVM/issues/562 | 15:38 | |
| brrt | okay, trying the optimistic store thingy.. | 15:49 | |
| fingers crossed | 15:50 | ||
| jnthn | Feeling optimistic about it? :) | ||
| brrt | well, i did all the hard-and-long thinking one might expect | ||
| Geth_ | MoarVM/even-moar-jit: fb081bc00c | (Bart Wiegmans)++ | 2 files Emit stores optimistically Previously we would always emit a store whether necessary or not. Now we only issue a store when necessary for correctness. To do this the flush_variables mechanism has been extended to replace the roots (that compute the values) with STORE operations (that store them to memory). |
15:56 | |
| brrt | okay, that will be it | ||
|
16:05
robertle joined
|
|||
| Geth_ | MoarVM: lucasbuchala++ created pull request #614: Decoder typos |
16:12 | |
|
16:13
lizmat joined
|
|||
| Geth_ | MoarVM: 1430b5ac69 | (Lucas Buchala)++ | src/6model/reprs/Decoder.c Decoder typos |
16:24 | |
| MoarVM: 146c8fcca1 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/Decoder.c Merge pull request #614 from lucasbuchala/typos1 Decoder typos |
|||
|
16:51
eater joined
17:19
sivoais joined
17:42
brrt joined
17:59
AlexDaniel joined
18:02
stmuk joined
19:21
Ven joined
19:33
stmuk_ joined
19:43
lizmat joined
|
|||
| samcv | good hi | 20:20 | |
| timotimo | eeeeey | ||
|
20:22
Ven joined
20:25
domidumont joined
20:40
Ven_ joined
22:02
Ven joined
|
|||
| Geth_ | MoarVM: 28b1419e51 | (Jonathan Worthington)++ | docs/ChangeLog Update ChangeLog for 2017.07. |
22:10 | |
| jnthn | Will cut the release tomorrow; bit tired for that now. Reviewing changelog is welcome in the meantime :) | ||
| yoleaux | 20:36Z <Zoffix> jnthn: FWIW, I bumped MoarVM then fresh clone and built everything and still getting 37% slower than usual roast runs. | ||
| 20:39Z <Zoffix> jnthn: roast runs == stresstest (not spectest; not sure if that's similarly slower) | |||
| 20:53Z <Zoffix> jnthn: false alarm. Turns out it was the nfc tests | |||
| jnthn | .oO( not fast checking ) |
22:14 | |
|
22:14
Voldenet joined
|
|||
| Geth_ | MoarVM: a5cf3d7759 | (Timo Paulssen)++ | tools/trace_spesh_optimizer.gdb document the trace_spesh_optimize script a little bit |
22:40 | |
| timotimo | ^- this is a good thing to have in the release together with the introduction of this script | 22:41 | |
| timotimo finds many typos in the changelog | 22:44 | ||
| Geth_ | MoarVM: f95c785365 | (Timo Paulssen)++ | docs/ChangeLog minor changelog fixes and tweaks |
22:47 | |
| samcv | timotimo, you can add full unicode 9.0 and emoji v4.0 text segmentation support | 22:52 | |
| :) | |||
| or should i add it | |||
| timotimo | i say you should do it | 22:58 | |
| celebratorily | |||
| samcv | ok :) | 23:01 | |
| timotimo gets ready for the unicode-related high-fives | 23:04 | ||
| will you continue using the unicode "project" on github? last update end of march | 23:12 | ||
| Geth_ | MoarVM: bccdb42344 | (Samantha McVey)++ | docs/ChangeLog ChangeLog reorganization and Unicode announcements |
23:15 | |
| samcv | timotimo, uh UCD? | ||
| timotimo | no i mean the "project" thingie | ||
| samcv | hm | 23:16 | |
| timotimo | with the columns you can put stuff into | ||
| samcv | oh | ||
| yeah i need to check up on that | |||
| i may have done some of the things there | |||
| timotimo | probably | ||
| i'm considering (i think i already mentioned this in the past) making a project for my ideas, too | |||
| samcv | yeah you should | 23:17 | |
| was able to remove two things | 23:19 | ||