nine ugexe: my merge last Friday would be a candidate. Unfortunately I don't have Windows, so I can't debug. 06:53
[Tux] jnthn, do you want me to create a new ticket for that utf8-c8 issue with examples? 12:14
timotimo we don't have one yet? 12:15
in any case, i've started looking at it, but i only managed to make it worse, not better :(
[Tux] there was one, but that had a wider issue range
rt.perl.org/Ticket/Display.html?id=127878 that one was the original, but that has been fixed 12:17
rt.perl.org/Ticket/Display.html?id=126756 <= that is the new one 12:18
which has also been marked fixed
timotimo ah, yeah, we don't segv any more
but we do read past the end of the buffer sometimes, and that causes an extra 0 to appear at the end 12:19
i managed to make it duplicate the second-to-last byte and then have the last byte 12:21
and also to drop the last two bytes
[Tux] This is Rakudo version 2016.04-208-ge39ce3d built on MoarVM version 2016.04-134-g9879233 12:22
test 20.691
test-t 13.293
csv-parser 35.050
timotimo :\ 12:23
[Tux] I just filed rt.perl.org/Ticket/Display.html?id=128184 12:32
timotimo pairs are swapped o_O 12:33
teh f ?!?
dalek p: 45e0bfb | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (4 files):
[js] Plugable and serializable container specs.
13:33
p: 9df5217 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Fix bug in NYI message.
13:57
ugexe nine: on my windows dev machine i can't reproduce any significant speed difference between blead vs 2016.04, but on appveyor its about a 33% slow down for every command vs 2016.04. My only (wild) guess is now its hitting an io/mem/cpu limit or something 15:50
on an unrelated note, I always thought "blead" referred to "bleed" as in bleeding edge 15:52
lizmat m: 42.polymod(0) 15:59
camelia rakudo-moar e39ce3: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/HRKsEl47P9 line 1␤␤»
lizmat that feels LTA
m: gather { fail }
camelia rakudo-moar e39ce3: OUTPUT«Failed␤ in block <unit> at /tmp/ZMEILAfFla line 1␤␤»
lizmat hmmm
m: class A { method a() { gather { fail } } }; A.a # golfed the issue 16:12
camelia rakudo-moar e39ce3: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/bdyOdNFdxV line 1␤␤»
jnthn fail is just a kind of return, and yeah, you can't return from a gather 'cus the routine already returned. 16:13
lizmat so that means you can't fail from a gather ? 16:14
m: class A { method a() { gather { Failure.new } } }; A.a # golfed the issue 16:15
camelia rakudo-moar e39ce3: OUTPUT«Failed␤ in block <unit> at /tmp/IS6S256t22 line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/IS6S256t22 line 1␤␤»
jnthn lizmat: Correct, just as you can't from a map if it's being lazily evaluated 16:21
m: sub foo() { (1..5).map({ fail }) }; foo() 16:22
camelia rakudo-moar e39ce3: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/NfVN4VlSp9 line 1␤␤»
jnthn Same situation there.
lizmat hmmm... so that means we'll get LTA error if a module is doing a fail, and it's being used inside a gather ??
jnthn Why'd that be a problem?
fail is a form of return 16:23
So it's all about the lexically enclosing routine
The reason the above ones don't work out is because you're no longer executing foo (or method a) at the point the fail executes 16:24
lizmat yeah, got that now :-) 16:25
jnthn So if I get what you're asking: no, I don't think we'll have too many LTA situations. That error *would* be nicer if it could indicate that the routine was already returned from 16:26
lizmat ack 16:33
[Coke] grep! 16:52
hey all you groovy people, don't forget to stay hydrated and have a good snack. :) 16:56
RabidGravy I'm contemplating beer, does that count? 17:10
geekosaur nope 17:11
[Coke] sounds good to me. :) 17:13
MadcapJake [Coke]: What would you consider to be the most atomic list of rakudobug categories? I'd like to provide templates for each in my issue submitter (that I hope to apply some tuits to) 17:27
[Coke] the categories are all ad hoc. I put the biggest ones I expect people to use in the rakudo README 17:29
lizmat I'm wondering whether "gather" and "fail" should know of each other, and basically have "fail" take the failure, rather than throwing it if called within a gather 17:59
masak lizmat: I thought `fail` was lexical-only, like `return` 19:29