Geth MoarVM: 19fc9f0f2b | (Timo Paulssen)++ | src/core/exceptions.c
vsnprintf can return more than the max value given

so truncate the number there.		 00:02
MoarVM: 0f1801655c | (Timo Paulssen)++ | src/spesh/dump.c
vsnprintf already writes a nullbyte at the end

  (and furthermore, the return value might be out-of-range here)		 00:04
timotimo what's the highest number for a "long long int"? 00:07
maybe a 64 byte buffer is enough to hold a number stringified with "%lld" 00:08
okay, i'm off to bed now, i'll look into this last piece after sleep
geekosaur 9223372036854775807
add one if you want to handle negatives :)
timotimo okay, that fits comfortably.
yeah, +1 00:09
01:05 tomboy64 joined 01:48 ilbot3 joined 02:30 TimToady joined 05:22 stmuk_ joined 05:32 domidumont joined 05:41 domidumont joined 05:58 domidumont joined 06:00 brrt joined 07:08 brrt joined
brrt good * #moarvm 08:04
nwc10 good *, brrt 08:16
samcv good *
brrt \o nwc10, samcv 08:19
i was working on basic block 'patching this morning
not very surprisingly, it can become pretty nasty
samcv block patching? 08:30
lizmat good *, #moarvm
lizmat just commented on RT #131134 08:31
basically, I think we need checking for negative indexes at the VM level for native artrays
*arrays
samcv what should we do for negative. throw? 08:32
lizmat that would be the implication, yes
samcv k
lizmat but I'm throwing this in here to see what jnthn has to say on that 08:33
I vaguely recall having this conversation before :-)
m: my int @a = ^10; my $a = 0; dd @a[$a-1]
camelia 9
lizmat m: my @a = ^10; my $a = 0; dd @a[$a-1] 08:34
camelia Failure.new(exception => X::OutOfRange.new(what => "Index", got => -1, range => "0..^Inf", comment => Any), backtrace => Backtrace.new)
lizmat perhaps jnthn considers this a feature: in which case we should probably document the behaviour :-) 08:35
brrt samcv: a sequence of code can be divided into 'basic blocks', i.e. sequences of code that always follow linearly (without branches or labels to enter); I want to find the extents of these blocks during list construction; this is simple enough to do (break the blocks at every branch or label), but then i need to assign the successors to the blocks, which is only known at a later phase 08:50
i'm fairly sure i've seen code to deal with that, yes
samcv interesting 08:52
brrt it's integrated into the tiling process, fwiw 08:53
(tiling is translation between expression-low-level IR to machine-level IR)
samcv yay i got travis to detect latest clang so i think i almost got the coverage build down 08:54
well. at least generating it. then have to set up the ssh, but that shouldn't be too hard since i've already wrestled with that
09:06 synopsebot6 joined 09:08 SourceBaby joined
brrt and the purpose of doing this extra work is so that i can analyze the live ranges within the basic block and find 'holes' in them 09:17
and the purpose of finding the holes is twofold
- if i can prove that a spill would be necessary only for the extent of a hole (e.g arround a CALL) then I don't need to spill at all
samcv sounds very useful 09:18
brrt - if i can prove that i need a register only within the extent of an existing hole, i don't need to spill the larger live range, either
yes, and it neatly solves the 'garbage restoring' problem i mentioned earlier 09:19
although the second variant is probably best only used for very short live rangesā€¦ 09:23
lizmat hmmm... what would be needed to get param_rp_o to spesh/JIT ? 11:58
jnthn spesh typically rewrites those 12:00
Into faster, unchecked, ops
And those are then JITted
So if they are making it to the JIT it means spesh couldn't specialize that case
That most typically happens when the caller is flattening arguments into the callsite
lizmat jnthn: this is the naive int candidate of AT-POS on native arrays 12:01
multi method AT-POS(intarray:D: int $idx) is raw { 12:02
nqp::atposref_i(self, $idx)
}
it doesn't JIT
MVM_JIT_LOG says: BAIL: op <param_rp_o>
jnthn What's calling it? 12:03
(In the case that it doesn't JIT?)
lizmat my int @a = ^10; my int $a = 5; for ^1000000 { @a[$a] }
jnthn OK, so postcircumfix:<[ ]> 12:04
I wonder what that looks like on the inside
(On the path it takes)
I'd be surprised it it were flattening, though
lizmat ah, ok, lemme check
jnthn Which makes it rather odd
Also would be odd if the callsite wasn't interned 12:05
lizmat well, actually, if I take out the postcircumfix, but do: 12:06
my int @a = ^10; my int $a = 5; for ^1000000 { @a.AT-POS($a) }
I get the same BAIL:
BAIL: op <param_rp_o>
but now on AT-POS
jnthn Hmm
What happens if you write `my Int $a = 4` ooc? 12:07
I wonder if it's part of the whole "we didn't teach spesh enough about native refs" thing...
lizmat yeah, I'm afraid it's that
jnthn Yeah, spesh really needs some time spendin gon it
*spending
lizmat same result with $i = 4 12:08
jnthn Hm, OK
Then maybe it's not that
lizmat why would 4 or 5 make a difference?
jnthn oh
lizmat ah, you mean Int :-)
jnthn I typo'd 5 :P
I meant the Int :D
haha
lizmat yeah
emit jump to label -1 12:09
Bytecode size: 3096
that emits fine, even with a check for < 0
Geth MoarVM/better-fsa: 62d0f7e2f0 | (Jonathan Worthington)++ | src/gc/orchestrate.c
Make nursery cleanup non-concurrent, for now.

We can't both have thread-local free lists and have the possibility of a work-stolen thread resuming while another thread that stole its GC work frees its nursery, since they can race on the free list. It is possible in the future to only lose the potential concurrency on threads that were stolen, and let non-stolen ones go their own way as ... (10 more lines)		 12:22
dogbert17 does this latest commit mean that better-fsa is ready for release? 12:24
jnthn It looks good in spectest 12:27
There's still a todo however
(Which doesn't affect most Perl 6 programs, but should be fixed pre-merge)
dogbert17 was thinking of running with small nursery and the like, but I guess that you've already done that 12:28
jnthn Not yet, wanted to get the missing TODO done first :) 12:29
dogbert17 ah, I guess that I'll wait as well then :)
dogbert17 wonders if the new branch might help offset the speed difference (~30%) between harness5 and harness6 12:31
jnthn That is certainly possible
dogbert17 cool 12:32
jnthn Timings welcome :)
dogbert17 I'll do a couple of tests on my system 12:33
dogbert17 should be interesting to hear what kind of results IOninja can get on his 24 core box 12:35
Zoffix Busy. 12:36
The current harness is exactly 2x slower tho
dogbert17 not on my system :) 12:37
Zoffix stresstest are about: 112s on harness5 and 224s on harness6 12:39
12:40 brrt joined
dogbert17 ah, perhaps it differs from the spectest difference 12:42
I'm running on virtualbox with two available cores ... 12:43
lizmat jnthn: do you feel things like atposref_i should have a check for index < 0 in the VM 12:45
or that that should be handled in e.g. AT-POS ?
jnthn Well, if we do it in the VM it's harder to get a typed exception to happen 12:46
otoh the VM has to do it anyway for safety
lizmat at the HLL it would cause a 10% slowdown in the AT-POS
jnthn: in the VM it currently means: from the end 12:47
so it is already checked, I would say
m: my int @a = ^10; say @a.AT-POS(-2)
camelia 8
lizmat m: my int @a = ^10; say @a.AT-POS(-12) 12:48
camelia MVMArray: Index out of bounds
in block <unit> at <tmp> line 1
lizmat aka, it has old P5 semantics
question is: is that a bug or a feature at that level :-)
if it is a feature, we could cponceivably optimize *-1 to -1 for natives :-) 12:49
jnthn Bug, and I dunno why we do those semantics in the VM really
dogbert17 make spectest HARNESS_TYPE=5 TEST_JOBS=4; Files=1176, Tests=56122, 833 wallclock secs ( 9.48 usr 6.89 sys + 1493.20 cusr 103.88 csys = 1613.45 CPU)
Geth MoarVM/better-fsa: 3d7b51c98f | (Jonathan Worthington)++ | src/core/fixedsizealloc.c
Don't leak per-thread FSA freelists.

At thread termination, contribute the freelist entries back to the global freelist.		 12:53
jnthn OK, I think it's ready for fuller testing/merge 12:56
12:58 brrt joined
[Coke] fsa: financial savings account! 13:07
dogbert17 make spectest HARNESS_TYPE=6 TEST_JOBS=4; Files=1176, Tests=56122, 968 wallclock secs
Zoffix Is there mp_uint? 13:08
dogbert17 will now try with 'better-fsa'
Zoffix m: class { has uint $.x }.new: :x(2**64-1)
camelia Cannot unbox 64 bit wide bigint into native integer
in block <unit> at <tmp> line 1
Zoffix This used to work in last release. And in this commit, we're calling count bits function on an mp_int, so it blows up: github.com/MoarVM/MoarVM/commit/66...78553a8R38 13:09
.tell MasterDuke any idea for rt.perl.org/Ticket/Display.html?id=131149 seems like it can be fixed by just changing the bits check to check for 65 or something; is there a mp_uint? 13:23
yoleaux Zoffix: I'll pass your message to MasterDuke.
Zoffix m: class { has uint $.x }.new(:x(-2**30)).x.say
camelia -1073741824
Zoffix Seems that routine is the same place ^ that can be fixed in 13:24
dogbert17 with better-fsa; make spectest HARNESS_TYPE=5 TEST_JOBS=4; Files=1176, Tests=56122, 816 wallclock secs ( 9.08 usr 6.88 sys + 1458.77 cusr 103.15 csys = 1577.88 CPU) 13:30
lizmat dogbert17: that's a nice improvement 13:33
MasterDuke committable6: 2017.03,HEAD class { has uint $.x }.new(:x(2**64-1)).x.say 13:40
yoleaux 13:23Z <Zoffix> MasterDuke: any idea for rt.perl.org/Ticket/Display.html?id=131149 seems like it can be fixed by just changing the bits check to check for 65 or something; is there a mp_uint?
committable6 MasterDuke, Ā¦2017.03: Ā«-1Ā» Ā¦HEAD(fbc6697): Ā«Cannot unbox 64 bit wide bigint into native integerā¤ in block <unit> at /tmp/YsLW_nurSL line 1ā¤ Ā«exit code = 1Ā»Ā»
jnthn dogbert17: Wait, that's faster than with harness5? o.O
MasterDuke Zoffix: it was broken before (as you pointed out), uint was acting exactly the same as int 13:41
jnthn: i think he re-ran harness5 with the better-fsa branch? 13:42
jnthn Ohhh...right
d'oh
I thought it was the harness 6 number with better-fsa :)
Zoffix MasterDuke: the negative was, but not the failure to accept 2**64-1 as a value
c: 2017.03 class { has uint $.x }.new(:x(2**64-1)).x.say 13:44
committable6 Zoffix, Ā¦2017.03: Ā«-1Ā»
Zoffix Hmm
I see
Alright 13:45
MasterDuke Zoffix: i've been working on actually getting uint attributes to work correctly, with timotimo++'s help, but it's not quite as easy as a simple fix in mp_get_uint64
Zoffix MasterDuke: is the ticket I opened a dupe then?
MasterDuke i believe it's going to require patches in MoarVM, NQP, and Rakudo all coordinated to work
Zoffix Or rather: is there a ticket for "uint is really int"?
dogbert17 with better-fsa; make spectest HARNESS_TYPE=6 TEST_JOBS=4; Files=1176, Tests=56122, 956 wallclock secs 13:47
MasterDuke not sure
dogbert17 yeah, with my highly unscientific tests it seems if the harness5 tests gain a bit more than harness6, OTOH maybe it's in the margin of error 13:48
would be nice if someone with more than two cores could give it a run or two 13:49
jnthn :)
jnthn bbiab
dogbert17 will now do a herness6 run with 192k Nursersy, gc-debug and fsa-debug ... 13:51
jnthn dogbert17: Uh, if you do fsa-debug you'll completely bypass all the new code I added of any significance :) 13:52
14:05 brrt joined
brrt fixed size allocator :-P 14:05
14:05 brrt left, brrt joined
brrt .tell lizmat: one of the things to make param_rp_o and friends JIT is to refactor the arg handling into something more jit friendly 14:09
yoleaux brrt: What kind of a name is "lizmat:"?!
brrt .tell lizmat one of the things to make param_rp_o and friends JIT is to refactor the arg handling into something more jit friendly
yoleaux brrt: I'll pass your message to lizmat.
brrt also, ffs, yoleaux, how hard is it to strip a colon
Zoffix What kind of arg handling is jit friendly? 14:10
$ ./perl6 -e '$*VM.version.say' 14:14
Segmentation fault
:) 14:15
brrt currently it returns a small struct. not sure again what it was
i have it written down somewhere
:-)
Zoffix Hm, actually everything is segmentation fault 14:16
dogbert17: how do I get the better-fsa thing?
I did cd nqp/MoarVM; git checkout better-fsa; perl Configure.pl --prefix=../../install; make -j30; make install; and now any code just segfaults 14:17
Zoffix tries running `build-rakudo` 14:18
fixed it 14:24
Box: 24-cores, 21.75GB RAM, TEST_JOBS=30 14:33
c9ab59c, harness5: Files=1238, Tests=133653, 111 wallclock secs (20.90 usr 2.94 sys + 2322.17 cusr 124.95 csys = 2470.96 CPU)
c9ab59c, harness6: Files=1238, Tests=133653, 223 wallclock secs
better-fsa, harness5: Files=1238, Tests=133653, 108 wallclock secs (21.42 usr 2.87 sys + 2225.60 cusr 129.92 csys = 2379.81 CPU)
better-fsa, harness6: Files=1238, Tests=133653, 200 wallclock secs
jnthn: dogbert17 ^
Pretty good improvement in harness6
MasterDuke ~10% 14:34
it's interesting to look at the difference between your harness5 and harness6 and dogbert17's. it's twice as slow for you, but only ~15% slower for him 14:36
suggests there's some constant overhead 14:37
Zoffix overhead of opening and reading files, I'd guess 14:39
dogbert17 Zoffix: nice improvement 14:43
dogbert17 the comment from jnthn forces me to rerun my debug test after a quick change, will settle for small nursery and cgdebug 14:44
timotimo i wonder if we should grab all the free lists and sort items by memory address and chop them up to the threads again 14:54
dogbert17 slow going, so far I see 't/spec/S17-promise/in.t ........................................... Dubious, test returned 1' 14:57
is that a known flapper?
timotimo i don't think i've seen it fail 15:01
it could theoretically be sensitive to timing, but i thought we had "virtual time" for those kinds of test
oh, except if you want to test the mechanism itself, you can't replace it with another before testing 15:02
15:05 AlexDaniel joined
timotimo it has to have some cut-off for saying "yup, i told the promise to be kept in 1s, but now it's 3s later and i'm considering this a failure" 15:06
dogbert17 so it might have to do with me running on a 192k nursery then :) 15:08
jnthn Yeah, pretty sure that file would be vulnerable to such timing effects
dogbert17 and 't/spec/S17-promise/nonblocking-await.t ............................ Dubious, test returned 255' contains a nasty bug no? 15:09
jnthn I think that one's been known to explode on master of MoarVM too, yeah 15:10
dogbert17 then it looks really promising, the spectest is at S32 now 15:11
done, only the two files mentioned above failed, run was with '#define MVM_NURSERY_SIZE (32768 * 6)' and '#define MVM_GC_DEBUG 2' 15:16
15:23 brrt joined
jnthn Alright, guess taht means we can merge it :) 15:41
Geth MoarVM/master: 6 commits pushed by (Jonathan Worthington)++ 15:43
brrt \o/ 15:44
jnthn Thanks for the testing :) 15:46
timotimo cool. 15:47
Geth MoarVM/even-moar-jit: b14298108f | (Bart Wiegmans)++ | src/jit/tile.c
Propagate block numbers upwards

In a number of cases, the label and branch structure of a child node is the same as the containing conditional structure, e.g. an ALL node
  'flows' into its consequent block because it works by branching to the
alternative on any failed test. No basic block is started for them. However, the block numbers are also required for correct assignment of successors, and without uppropagation we might need to dig arbitrarily deep to find them.		 15:54
MoarVM/even-moar-jit: be591ff274 | (Bart Wiegmans)++ | src/jit/tile.c
Patch basic block successors associated with nodes

Because conditonals can be nested (what a novel idea), we can only know the exact basic block structure of a block after tiling it, so we have to 'patch' the successors back into the blocks.
brrt so, the above will allow me to start doing data flow analysis 15:56
specifically, it will allow me to discover lifetime holes
that said, i would like to test the created tructure for a bit 15:57
*structure
because I don't really trust it as is
anyway, decommute & 15:58
dogbert17 jnthn++, very cool
TimToady jnthn: I have a weird one; in Perl6/World it calls @components.push(~$name<identifier>); which works until I use --rxtrace, and then ~ gets 'cannot stringify this', but if I change to use .Str, it finds the one from NQP and works 16:03
but nqp::stringify just looks for .Str in the cache, so somehow .Str isn't in the cache such that nqp::stringify can find it, but calling it directly can
the mro is Perl6::Grammar HLL::Grammar NQPMatch NQPCapture NQPMu 16:05
and NQPMatch is supplying 'method Str()'
(this, by the way, is from the last failing .t file for the uncurse branch to pass spectests) 16:06
the method is actually from NQPMatchRole, which NQPMatch does, but moving the method from the role to the class makes no difference 16:07
I suppose --rxtrace must be rewriting method calls, and flubbing somehow... 16:08
jnthn That's...odd 16:10
(The failure itself)
rxtrace iirc hooks find_method
I wonder if nqp::stringify uses the smart stringify thing 16:11
Which doesn't know how to do fallback lookups
TimToady yes, but that only uses the cache
jnthn Yeah
So...why's it not in the cache... :S
TimToady I tried using nqp::can to preload the cache, but no go 16:12
maybe that doesn't
jnthn No, caches are authoritative 16:13
In general, at least
And are pre-populated at composition time
Oh 16:15
Do we ever late-bound add_method on it?
TimToady not that I know of
jnthn 'cus that clears the cache out
TimToady does --rxtrace call add_method? 16:16
jnthn Don't think so
What branches do I need to reproduce this?
TimToady nqp uncurse and rakudo uncurse, but let me push what I have 16:19
jnthn OK
And also which test :)
jnthn wonders if match/cursor unification will give us a decent memory use reduction already 16:20
TimToady the test is t/spec/S19-command-line-options/06-dash-rxtrace.t but it suffices to run perl6 --rxtrace -e 'say "hello world"'
jnthn huh, rxtrace is in spectest?! 16:21
TimToady all it does it test to see that it doesn't blow up
(which it does :)
jnthn :)
Building uncurse branches
TimToady I don't think it'll save memory just yet, since I haven't quite carved away the old match object entirely 16:22
just got it down to a stub class with a Bool method, but eventually $!match will becomee bool itself or go away entirely in favor of looking for a %!hash or so 16:23
timotimo the worst thing is that --rxtrace doesn't even give interesting output either way 16:25
TimToady is also possible we can do sharing tricks in the time domain like Perl 5 does, but that's kind of a last resort optimization
timotimo or did that get improved recently?
TimToady just says which methods are called
timotimo huh, apparently it works now
it used to give like 10 lines that were always the same no matter the code you're parsing
jnthn hhh 16:26
*ohh
Turning on tracing trashes the method cache
So that's why 16:27
TimToady that seems...incompatible...with relying on an authoritative cache... 16:28
jnthn Indeed
Well, it was a quick debugging hack rather :)
*rather than a carefully considered feature/implementation :) 16:29
TimToady I started changing some ~ to .Str to see how far it goes, but of course we use ~ *everywhere*
so I came whining to you instead :)
jnthn :) 16:31
Yeah.
I guess maybe the easiest thing for me to do is re-write the tracer to just build a cache of tracing things :)
TimToady what, you don't wanna implement a recache-all-the-things thingie? 16:32
jnthn Pushed a fix that seems to do it 16:41
I want to re-work how we do method caching stuff in general at some point :)
But this should get us over this bump in the road for the moment :) 16:42
TimToady yays 16:44
16:55 domidumont joined
jnthn :) 16:56
TimToady I guess it could give a little memory saving already due to not keeping redundant from/to/orig 17:02
timotimo three pointers per, eh? 17:06
er, no
two 64bit ints, one 64bit or 32bit pointer
we might at some point want to have a tool like pahole that tells us where in our P6opaque classes we can save space
save space by rearranging 17:07
Geth MoarVM/even-moar-jit: abcbf000f8 | (Bart Wiegmans)++ | src/jit/expr_ops.h
Silence a GCC warning

The file ended with an escaped newline, and GCC rightly complained about that.		 17:20
18:15 domidumont joined 18:59 stmuk joined
samcv good * 19:43
timotimo oh hey
samcv woo. ok think it's building the html coverage on travis now. stage 2 begin! getting the ssh key working and copying to gh-pages branch 22:02
Geth MoarVM/coverage: 4f3798310c | (Jonathan Worthington)++ (committed by Samantha McVey) | src/io/io.c
Remove arbitrary and small length range check.

This meant we could not slurp a file over 100MB in binary mode without getting an error. Removing this, such a file is very easily slurped.		 22:06
MoarVM/coverage: f6b3ac1274 | (Samantha McVey)++ | 4 files
Commit coverage report related files
samcv weird. uh
oh well
looks like my rebase modified the previous commit. oh well. no matter 22:07
can't test any further on my branch because the ssh key is locked to travis ci on MoarVM/MoarVM 22:08
woo. key decrypted successfully. i'm so excited. for continuous coverage reports 22:09
brb 22:10
Geth MoarVM/coverage: b049e7114f | (Samantha McVey)++ | tools/update-gh-pages.sh
fix
 22:26
MoarVM/gh-pages: 106a558f23 | (Travis CI)++ | 240 files
Travis build 1960 pushed to gh-pages
 22:32
jnthn samcv: What does it run to get coverage data? 22:37
(As in, just building Rakudo, make test, make spectest?) 22:38
samcv nqp
make test in nqp 22:39
jnthn Ah
OK, that explains a lot :)
(Like, why none of the concurrency stuff is covered... :))
samcv moarvm.github.io/MoarVM/libmoar/ did you see
ah
yeah
it worked :) 22:40
jnthn Yeah, that's what I'm looking at :)
samcv++
samcv now i only need to re-enable the noncoverage builds on the coverage branch to make sure i didn't break the other things in the matrix 22:42
i can get roast tests too since people will like that 22:43
as long as travis doesn't cry from it taking too long 22:44
Geth MoarVM/coverage: c309939841 | (Samantha McVey)++ | .travis.yml
Try readding the noncoverage builds
 22:45
jnthn Yeah, depends how much of a slowdown running coverage is, I guess 22:46
samcv well it doesn't take more time than a normal run really 22:48
maybe like 10 seconds max
if i take out it building nqp without coverage the 1st time
atm it runs the normal mvm tests, and then afterward it will run the coverage (same nqp tests, but using nqp-profile script which sets the right env vars and such to save the coverage) 22:49
Geth MoarVM/coverage: 03d13be72b | (Samantha McVey)++ | .travis.yml
Re-add the MacOS builds too
MoarVM/gh-pages: 4ba4c88d6b | (Travis CI)++ | 237 files
Travis build 1961 pushed to gh-pages
 23:00
jnthn I...assume that the push of the updated coverage data doesn't trigger a Travis build? :D 23:01
timotimo if it does, we can blacklist gh-pages 23:02
but it'd be reasonable if travis already knew about gh-pages
jnthn I guess the other question is if all the coverage data we're pushing will affect clone times, but I guess it compresses super well 23:04
If either of those is an issue, I guess we just make a special MoarVM/coverage repo to push to 23:05
timotimo sure
samcv no it doesn't 23:10
since it has no .travis.yml
timotimo ah, that makes sense 23:11
Geth MoarVM/gh-pages: bbc7b1e031 | (Travis CI)++ | 237 files
Travis build 1962 pushed to gh-pages
 23:14
timotimo samcv: you see these little graphs? irclog.perlgeek.de/
it'd be pretty cool if we could have history graphs for each cell in the overview
samcv that would be nice 23:15
somebody should do that who is not me :)
timotimo :D
i don't know how we'd properly get at data from previous commits
don't want to parse a hundred html files for each new report :D
samcv yeah no. we would not do that
we'd generate a more parsable thing with `report` instead of the html coverage line by line 23:16
timotimo we could build both the html and the text-only ... yeah
samcv yea
timotimo the text-format report will also give prettier "git diff" output
though it's kind of likely that it'll very often give us "all these lines changed!" and you can't actually see anything 23:17
Geth MoarVM/coverage: 79a259c5b8 | (Samantha McVey)++ | .travis.yml
Try and get os x excluding items in travis again
samcv oh you want lines? not files?
timotimo oh
samcv :O
timotimo no lines in the report file i mean
when you use git log on a text-based report five 23:18
samcv oh number of lines covered
timotimo git log on the html reports is definitely going to be worthless, as the complete html gets put into just a single line
samcv yeah
but would be better if it were processed and extracted as a percentage of the file or something idk
timotimo i'm not sure if i understand how you mean that?
samcv uh 23:19
this cry.nu/coverage/report-libmoar.html
is what we'd extract data from. but with no color of course. and not as html just a plain text file
timotimo ugh, that's *really* wide and my browser's line-wrapping it 23:20
but yeah, i imagined it like that
samcv yep
it is super wide. since they added more columns in llvm 5
timotimo mhm
23:22 geekosaur joined
jnthn 'night o/ 23:26
Zoffix night
timotimo nite jnthn 23:27
Geth MoarVM/gh-pages: d2bc415c90 | (Travis CI)++ | 237 files
Travis build 1963 pushed to gh-pages
 23:34

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!