gfldex should wrap on an individual method wrap on that method or the proto? 15:50
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
melezhik vrurg did you manage to read my sparrow links, do you have any more questions about the topic? 16:37
gfldex lizmat: if I understand the comments in S06-advanced/dispatching.t correctly, wrapping multi candidates is NYI 20:10
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
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
patrickb I'd value a set of eyes on github.com/rakudo/rakudo/pull/4154 22:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!