00:50 kjs_ joined 06:39 lue joined
dalek arVM: dfdef4c | TimToady++ | src/6model/reprs/NFA.c:
replace quicksort with insertion sort

N is generally small, so a simple insertion sort is more appropriate, especially when moved to the point we already have the fates in the cache.
07:21
08:42 lizmat joined 09:54 woolfy joined 11:49 JimmyZ_ joined
jnthn wtf was I thinking in frame.c:555... 12:12
That's rooting osmething that's not even a GC-able thing, it's a register frame array... 12:13
12:14 tadzik joined 12:15 synopsebot joined
JimmyZ_ Oh, How did it work :) 12:19
jnthn By getting hit rarely, I guess... 12:20
lizmat reason for OS X flakiness ? 12:22
JimmyZ_ so only OS X hit it ? ;)
jnthn lizmat: Well, I took a spectest that was sometimes failing, did a bunch of GC setting tweaks, and got same test to explode due to this reason under the debugger.
lizmat: I can confirm that particular issue I found on OSX goes away. I now need a fresh normal build and to do a clean build/spectest. 12:23
lizmat is looking forward to the results 12:24
jnthn If clang ever finishes compiling interp.c, we'll find out... :P 12:25
lizmat brb& 12:26
jnthn Well, further improvement. 12:35
All passed except an explosion in t/spec/S04-statements/terminator.t 12:36
JimmyZ_ That's very nice 12:38
lizmat jnthn++ 12:40
jnthn That failure is, unfortunately, still indicative of a bug somewhere. 12:42
But this is by far the cleanest I've seen OSX since I started looking into the issues. 12:43
lizmat yeah, reason enough for a bump ? 12:50
jnthn lizmat: yes, let's 12:54
It'll give us some more feedback
lizmat ok, will do
timotimo is pleased 12:55
13:40 kjs_ joined 14:32 kjs_ joined 14:36 dalek joined 15:04 brrt joined
brrt \o 15:04
JimmyZ o/ 15:06
timotimo |o 15:13
brrt oh good news... jnthn++ 15:16
15:39 kjs_ joined 15:44 zakharyas joined 16:20 zakharyas joined
lizmat well... the feedback from me so far, is that I still see random testfiles fail during spectest 16:36
TimToady maybe it shoulda been named osx canary 16:42
jnthn lizmat: :/ 16:45
Guess we'll have to see what improvement the [Coke]++ daily runs show up 16:49
stouting & 16:54
17:52 FROGGS_ joined 18:15 woolfy left 18:36 lizmat joined 18:47 ilbot3 joined 19:57 kjs_ joined 19:58 kjs_ joined
hoelzro FROGGS_: have you had a chance to look at that precomp bug? 20:15
FROGGS_ hoelzro: no, $dayjob keeps me busy :o( 20:16
(also right now)
hoelzro ah ha =/
I looked at it a bit, and I *thought* I was on to something, but jnthn assured me that's not the issue 20:17
FROGGS_ ahh, k 20:18
hoelzro I think my problem is that my knowledge of how precomp works is very limited
FROGGS_ I should ask what you were after then before I start getting into it
I know some details but my problem is that my brane is not smart enough to keep all details in memory at the same time :o) 20:19
hoelzro well, I thought it was because GLOBALish isn't passed in here: github.com/rakudo/rakudo/blob/nom/...d.nqp#L361 20:20
but jnthn said that GLOBALish is serialized with all of the correct linkage, so that's not it
that's as far as I got
dalek arVM: c6354db | TimToady++ | src/6model/reprs/NFA.c:
more cleanups; carp on wrong # of fates from nqp
20:21
timotimo jnthn: do you think recording where the code currently was when a GC got triggered would be interesting? 21:54
jnthn: when forcing the GC to run, the profiler output for GC runs is wrong, it shows a green bar all the way to the right, even if the three parts don't add to the same amount 21:57
22:02 lizmat joined
timotimo i'm not sure if i should make the progress bar shorter or add a "wasted" section 22:09
22:36 [Coke] joined
[Coke] finally kicks off today's runs. 22:38
lizmat [Coke]++ 22:44
23:11 colomon joined
timotimo 00062 const_s loc_1_str, 23:48
'CwAAAEAAAAAFAAAAaAAAABwAAAC4AQAAZl4AAHICAACGhQAAGdAAACkAAADx0wAAFQAAAEHVAAAB2wAAAAAAAAUAAAAGAAAAcwAAAHQAAADbAAAA3AAAAN8AAADgAAAAKgEAACsBAAABAAAAAAAAAFAAAAABAAAAUAAAAKAAAAADAAAAoAAAAEQHAAB1AAAARAcAAJ4TAADYAAAAFRQAAEMbAAADAAAAXRsAAB0iAAABAAAAHSIAAG0iAAB1AAAAbSIAALkrAAB1AAAA9CwAAEA2AAB1AAAAezcAAMdAAAB1AAAAAkIAAE5LAAB1AAAAiUwAANVVAAABAAAAEFcAAFhXAAABAAAAWFcAAPpXAAABAAAA+lcAAEJYAAABAAAAQlgAAKhYAAABAAAAqFgAAPBYAAA
BAAAA8FgAAFZZAAABAAAAVlkAAJ5ZAAABAAAAnlkAAARaAAABAAAABFoAAExaAAABAAAATFoAALJaAAABAAAAsloAAPpaAAABAAAA+loAAGBbAAABAAAAYFsAAKhbAAABAAAAqFsAAA5cAAABAAAADlwAAF5cAAABAAAAXlwAAK5cAAAAAAAApAAAAAAAAAAAAAAAAgAAAAAApQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAACmAAAAAAAAAAEAAAACAAAAAACnAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAKgAAAAAAAAACgAAAAI
AAAAAAKkAAAAKAG0AAAAEAAAAAgABAAAAX8EAAAcAAAACAAEAAADCBgAACAAAAAIAAQAAAMoGAAAJAAAAAgABAAAA4gYAAAoAAAACAAEAAADqBgAACwAAAAIAAQAAAPoGAAAMAAAAAgABAAAABAcAAA0AAAACAAEAAAATBw
how come we're still putting serialized blobs in base64?