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
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
timotimo github.com/nael8r/How-To-Write-An-...ocator.rst - huh, that's curious 16:24
FROGGS o/ 18:35
lizmat FROGGS o/ 18:36
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
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
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?
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
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/

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!