[Tux] This is Rakudo version 2016.05-84-g87e91cc built on MoarVM version 2016.05-18-g1339332 07:05
test 18.764
test-t 10.907
csv-parser 22.138
lizmat, this version broke csv_gram.pl - No error message given 07:06
[Tux] => $work 07:07
stmuk_ one of my benchmarks which ran at 13 sec towards the end of last year now runs about 8 secs! 09:54
RabidGravy cool 09:56
DrForr Nice. 09:57
|Tux| stmuk_, thanks for testing too! 10:32
lizmat [Tux]: csv_gram.pl hangs for me at 0% CPU 10:45
|Tux| p6 csv_gram.pl </tmp/hello.csv
it needs input :)
lizmat ah, duh :-) 10:47
works ok, but then I have a much smaller hello.csv 10:48
|Tux| does it report a count?
it should report 50000 (with my hello.csv)
lizmat ah, no, it didn't
|Tux| there you go 10:49
lizmat it ends after 257 iterations 10:50
if I MVM_SPESH_DISABLE=1, it runs to completion 10:53
|Tux| feels like a canary again
lizmat yup
timotimo uh oh 10:56
lizmat This fixes it: 11:01
method getline(){
- return $!ast;
+ $!ast;
}
I was put on this trail when I removed the MAIN around it and just ran it in the mainline of the program
it then started to say "Attempt to return outside of any Routine" 11:02
since this was the only return statement in the whole file, it was easy to check
so it looks to me it loses some stack info after 257 iterations, and then the next return will just return out of the MAIN, and we're silently done 11:03
because returning out of MAIN is a legal thing to do
I wonder how many bugs we've put under the carpet by removing "return" statements 11:04
otoh, I don't think it's wise to pursue this bug at this time, because of jnthn's work
so I'll wait until that's landed 11:05
timotimo that could even have a tiny bit to do with how the count-only broke?
lizmat possibly, yes
somehow it also feels this is GC related, and since frames have become GC collectable recently 11:06
timotimo if that's the case, maybe we can tease it out by putting force_gc in the right (randomly selected) spot? 11:07
lizmat lemme try
nope, forcing a gc inside the loop does not fix it 11:08
timotimo i'm not actually sure if that would help at all 11:09
lizmat huh 11:10
ok, get this: 11:12
removing the "return" from the method "getline" in class CSV_Actions fixes the issue
*HOW* does that get called anyway???
in my stripped down version, the return happens from lines() 11:13
so it looks like it is calling "getline" from the CSV_Actions class, instead of from IO::Handle
oops 11:16
maybe not :-)
ok, if I have a "return outside of any Routine" error, it points to the "for lines()" 11:18
timotimo maximum shrugs
lizmat perhaps that's part of the confusion 11:19
timotimo if it says the return happens outside of any routine, it could just be the thing that has the return got inlined into a block that isn't a routine 11:20
and the handlers weren't fixed up properly/fully
lizmat fwiw, it's not laziness in lines 11:21
putting the lines into an array, same problem
timotimo OK 11:24
lizmat m: class A { has $.foo; method foo { return $!foo } }; my $a = A.new(foo => 42); my $sum = 0; for ^500 { $sum += $a.foo } # golfed 11:26
camelia rakudo-moar 87e91c: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/oLh4prjqJW line 1␤␤»
lizmat m: class A { has $.foo; method foo { return $!foo } }; my $a = A.new(foo => 42); for ^500 { $a.foo } # further golfed
camelia rakudo-moar 87e91c: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/VNXQ9AZcD1 line 1␤␤»
lizmat m: class A { has $.foo; method foo { return $!foo } }; my $a = A.new(foo => 42); for ^158 { $a.foo } # first value it breaks on 158 11:28
camelia rakudo-moar 87e91c: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/9NqzgIZLo_ line 1␤␤»
lizmat m: class A { has $.foo; method foo { return $!foo } }; my $a = A.new(foo => 42); for ^157 { $a.foo } # 157 is ok
camelia ( no output )
lizmat haz a ticket: rt.perl.org/Ticket/Display.html?id=128368 11:34
timotimo ooooh, good golf!
lizmat m: class A { method foo { return 42 } }; my $a = A.new; for ^157 { $a.foo } # still smaller golf, no attributes neede 11:41
camelia ( no output )
lizmat m: class A { method foo { return 42 } }; my $a = A.new; for ^158 { $a.foo } # at 158 it fails
camelia rakudo-moar 87e91c: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/OZc4EqaZLv line 1␤␤»
lizmat can't get it to fail with a sub 11:42
eh 11:43
m: sub foo() { return 42 }; for ^157 { foo } # still smaller golf
camelia ( no output )
lizmat m: sub foo() { return 42 }; for ^158 { foo } # fails at 158
camelia rakudo-moar 87e91c: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at /tmp/tOCcim2lY1 line 1␤␤»
dalek kudo/nom: 9cfcb96 | lizmat++ | src/core/Baggy.pm:
Remove no-sinks from Baggy

And streamline a bit		 12:18
lizmat afk for a few hours& 12:19
psch nine: gist.github.com/peschwa/488d4bc687...654d86c5d9 is the NPE i get when i put mast_frames into $*W 12:56
nine: well, it's a bit of jdb details... :) 12:57
hm, m.qbid is 7 12:58
so we're trying to add one more CodeRef than we have..? 12:59
doesn't that mean that we skip one? 'cause the NPE was because [5] was null afair
as in, we have the correct number of CodeRefs, but bad indexing 13:00
mlist[*] => qb_* is 0 => 3, 1 => 4, 2 => 2, 3 => 1, 4 => 0, 5 => 7, 6 => 6 13:02
well, however it happens, it happens during $*JMETH declarations 17:03
somehow, somewhere, we're skipping qb_5
it's especially confusing considering we preseed %*CUID_TO_QBID 17:08
so we either have the wrong cuid when instantiating the JAST::Method, or... something else? 17:09
b2gills Shouldn't &infix:<eqv>(Match:D $a, Match:D $b) be ｢{ $a =:= $b || [&&] ..... }｣ instead of ｢{ [&&] $a =:= $b, ...... }｣ because the current behavior is the same as just ｢{ $a =:= $b }｣ and I assume the =:= is supposed to be just an optimization 17:34
timotimo oh, that seems very wrong 17:35
spec tests didn't catch that? shameful :(
psch i think there's a half-finished PR for that eqv candidate..?
timotimo no clue :S 17:37
i've lost overview of pretty much everything
lizmat b2gills: please RT it 20:11
dalek kudo/nom: 74d7ac0 | lizmat++ | src/core/List.pm:
Remove no-sink from List.pick

Plus some streamlining		 21:06
kudo/nom: 5b4470b | lizmat++ | src/core/Map.pm:
Remove no-sink from Map.*

Plus some streamlining
b2gills lizmat: I just did a PR on it with a link to the PR that added the &[eqv] candidate, which bears out my suspicion of it being intended as an optimization 22:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!