|
00:18
brrt joined
02:11
vendethiel joined
02:51
vendethiel joined
05:00
colomon_ joined
07:03
Util joined,
lnx joined
07:04
xiaomiao joined,
japhb joined
07:17
FROGGS joined
|
|||
| FROGGS | m: say 32618.fmt('%#b') | 08:03 | |
| camelia | rakudo-moar 585619: OUTPUT«0b111111101101010» | ||
| FROGGS | m: say 32560.fmt('%#b') | ||
| camelia | rakudo-moar 585619: OUTPUT«0b111111100110000» | ||
| FROGGS | m: say 32736.fmt('%#b') | 08:04 | |
| camelia | rakudo-moar 585619: OUTPUT«0b111111111100000» | ||
| FROGGS | ohh noes | 08:13 | |
| just found a stupid bug | |||
| /o\ | |||
| this adds a field to the C{PP}Struct|CUnion reprs, and does *not* (de)serialize that added field: github.com/MoarVM/MoarVM/commit/e8...24330ccR47 | 08:15 | ||
| jnthn: what do I need to do besides adding that field to the repr datas? Do I need to bump the serialization format? I guess so, but I'd need some pointers I guess | 08:21 | ||
| I guess I need to make it conditional, do not read that field if the ser format is old, read otherwise, and always write the new field | |||
| nwc10 | FROGGS: 7a045725c9daf4ffca6d8f6a08469f8ac4b92e7d is an example of a commit where we've changed this sort of thing | 08:30 | |
| FROGGS | ohh | 08:32 | |
| nwc10++ # thank you | |||
|
09:07
zakharyas joined
09:28
pyrimidi_ joined
|
|||
| jnthn | FROGGS: Yeah, if you're adding a field you need to bump so you know whether to read it or not | 09:39 | |
| dalek | arVM: 38d9a8b | FROGGS++ | src/6model/ (4 files): fix bug for inlined structures in strutures in nativecall code An inlined structure loaded from another precompiled compilation unit errornously reported a wrong alignment, which caused a size increase and probably a field misalignment in the outer structure. This was caused by not serializing and deserializing the alignment information to disk when precompiling a compilation unit. This patch bumps the serialization format version to 17. |
09:46 | |
| jnthn | FROGGS: Looks good | 09:57 | |
| nwc10 | Stage parse : 303.109 | 09:58 | |
| "are we nearly there yet?" | |||
| jnthn | Such slow.. | 09:59 | |
| ASAN? | |||
| nwc10 | aye | ||
| it's like carrying a 20kg rucksac - you get used to it, and then suddenly everything is faster (or "instant diet") when you turn it off/take it off | 10:00 | ||
|
10:12
vendethiel joined
11:41
vendethiel joined
12:24
leont joined
13:30
vendethiel joined
14:20
pyrimidine joined,
vendethiel joined
14:23
donaldh joined
15:19
donaldh joined,
leont joined
|
|||
| timotimo | github.com/nael8r/How-To-Write-An-...ocator.rst - huh, that's curious | 16:24 | |
|
17:45
vendethiel joined
17:57
donaldh joined
18:33
vendethiel joined,
FROGGS joined
|
|||
| FROGGS | o/ | 18:35 | |
| lizmat | FROGGS o/ | 18:36 | |
|
18:48
brrt joined
|
|||
| dalek | arVM: f2ae11b | FROGGS++ | src/6model/reprs/C (2 files): fix structure size calculation when other structures are inlined |
19:32 | |
| jnthn | FROGGS++ | 19:33 | |
|
20:35
cognominal joined
|
|||
| dalek | arVM: 16634eb | jnthn++ | src/6model/serialization.c: Fix missing cleanup in serialization. |
20:56 | |
| jnthn | Whee, I may have got us a clean sheet on `nqp -e "1"` (when Moar is run with --full-cleanup) | 21:05 | |
| Without busting other stuff. | 21:06 | ||
| hoelzro | \o/ | 21:13 | |
| jnthn++ | |||
| dalek | arVM: 263415c | jnthn++ | src/io/syncstream.c: More properly clean up handles on GC. Including standard handles, which we leaked. Simply adding in a close and free led to a SEGV, because the event loop has to be run before it was really save to free the handle. So, this is now done also. It will need some further revision in the future, but is good enough to get us a clean sheet with --full-cleanup on most NQP tests. |
21:19 | |
| jnthn | Now for a daily run of the NQP tests under valgrind leak check | 21:47 | |
|
22:14
colomon joined
|
|||
| jnthn | Not that many leaks left. MVM_proc_shell does leak | 22:38 | |
| FROGGS / hoelzro ^^ one of you might be able to figure that one out :) | |||
| It's the MVM_calloc call at MVM_proc_shell (procops.c:171) | 22:39 | ||
| hoelzro | hmm | 22:40 | |
| could it be that the GC is running before the process exits, so libuv is trying to do something with the handle after it's been free()d? | |||
|
22:41
flaviusb joined
|
|||
| jnthn | hoelzro: It's not a memory *error*, it's a memory *leak*. | 22:43 | |
| We never free the memory allocated by that calloc | |||
| with --full-cleanup the GC does collect everything at process exit. | |||
| hoelzro | sorry, I was confused by your commit message's mention of SEGV | ||
| jnthn | Ah, that was just explaining why the curious-looking uv_run in the patch was there. :) | 22:44 | |
| hoelzro | ah =) | ||
| jnthn | 86-pipes.t is rather leaky also | 22:45 | |
| Only 3 leaks in t/nqp/*.t and all are I/O or process related. :) | 22:46 | ||
| t/hll is clean | 22:47 | ||
| timotimo | .o( haha, the pipes are leaky ) | 23:09 | |
| jnthn | :P | 23:11 | |
| Was going to see if it'd finish valgrinding qregex.t before sleep...but I think sleep may come first | |||
|
23:16
colomon joined
|
|||
| timotimo | is the benchmark run going to happen on its own after that? | 23:21 | |
| jnthn | Well, need to get the script to shove its output somehwere useful and cron job it on the other machine rather than my local one | 23:22 | |
| timotimo | ah, i see | 23:23 | |
| jnthn | But the script seems to work | 23:24 | |
| timotimo | i'm really looking forward to the new grant application getting accepted | ||
| (i expect the chance to get it accepted lies in the 99.9% - 100% range :) ) | |||
| jnthn | Only got one comment so far, but it was at least positive. :) | 23:25 | |
| timotimo | don't forget the moderation on that | ||
| jnthn | ah, right :) | ||
| timotimo | we didn't update moarvm.org yet for 2016.01 | ||
| jnthn | oops | ||
| jnthn will try and remember tomorrow | 23:26 | ||
| Though it'll be 2016.02 time soon... :) | |||
| timotimo | aye | ||
| subtlepatterns.com/?s=dark - moarvm.org could get one of these nice background patterns | 23:29 | ||
| jnthn | :) | 23:30 | |
| OK, qregex results tomorrow...I should be resting | |||
| o/ | |||