03:14 JRaspass left 03:26 Xliff left 04:53 nativecallable6 left, benchable6 left, unicodable6 left, committable6 left, greppable6 left, linkable6 left, notable6 left, bloatable6 left, releasable6 left, statisfiable6 left, evalable6 left, tellable6 left, bisectable6 left, quotable6 left, squashable6 left, shareable6 left, coverable6 left, sourceable6 left 04:54 benchable6 joined, coverable6 joined, greppable6 joined, sourceable6 joined, linkable6 joined, evalable6 joined 04:55 shareable6 joined, bisectable6 joined, squashable6 joined, nativecallable6 joined, unicodable6 joined, quotable6 joined 04:56 bloatable6 joined, statisfiable6 joined, notable6 joined, tellable6 joined 04:57 committable6 joined, releasable6 joined 05:52 sortiz left 06:40 kevin1 joined 06:41 kevin1 left 06:42 kjp joined 07:24 frost-lab joined 07:34 sena_kun joined 07:54 domidumont joined 08:31 MasterDuke joined 09:11 JRaspass joined 09:41 Altai-man joined 09:44 sena_kun left 11:04 linkable6 left, evalable6 left 11:06 evalable6 joined, linkable6 joined 12:31 MasterDuke left 13:25 MasterDuke joined 13:42 sena_kun joined 13:43 Altai-man left 14:05 frost-lab left 14:37 domidumont1 joined 14:40 domidumont left
gfldex should wrap on an individual method wrap on that method or the proto? 15:50
15:54 [Coke] joined, [Coke] left, [Coke] joined
lizmat I would say on that candidate ? 15:55
if it doesn't... well, that would feel weird to me
otoh, maybe that's intentional, because of callsame and friends handling 15:56
jnthn might know
gfldex It wraps the proto. Not hard to handle that case but it's still an ENODOC. 15:59
gfldex is blogging
16:32 melezhik joined
melezhik vrurg did you manage to read my sparrow links, do you have any more questions about the topic? 16:37
17:41 Altai-man joined 17:44 sena_kun left 17:45 squashable6 left 17:48 squashable6 joined 17:49 melezhik left 17:58 patrickb joined 18:28 JRaspass left 19:09 sortiz joined 19:15 domidumont1 left
gfldex lizmat: if I understand the comments in S06-advanced/dispatching.t correctly, wrapping multi candidates is NYI 20:10
20:56 Altai-man left
patrickb I just did a `make spectest` in a rakudo branch and got some errors all semingly unrelated and a load of passed todos. Is that expected? 21:07
This is the result of the run: gist.github.com/patrickbkr/a1714fb...ae936eb7c5 21:12
Yeah, that run took nearly 40 minutes :-/
[Coke] patrickb: what OS? 21:17
patrickb linux
[Coke] I am not sure if practically that's expected, but theoretically, I would think linux would have a pretty strict everything should be passing and anything passing shouldn't be TODO'd (but other oses might lag one way or the other) 21:18
.. do we have something jenkins like keeping track of these as we update roast/release rakudo?
patrickb I don't think so. Our CIs don't currently do roast... 21:20
gfldex I wonder if :batch in hyper/race should depend on .elems. Pretty much every time I hyper I use :1000batch. 21:26
21:55 maggotbrain joined 22:00 JRaspass joined
patrickb I think I solved my spectest mystery. I had it checked out at a custom branch which broke auto update of the spec repo during `make spectest`. 22:08
22:11 kjpye joined
patrickb I'd value a set of eyes on github.com/rakudo/rakudo/pull/4154 22:56
23:13 patrickb left 23:59 [Tux] joined