[Tux] This is Rakudo version 2017.04.2-13-gce37b31a3 built on MoarVM version 2017.04 06:06
csv-ip5xs 3.053
test 13.086
test-t 5.181 - 5.351
csv-parser 13.294
lizmat Files=1191, Tests=56772, 215 wallclock secs (12.43 usr 4.61 sys + 1254.92 cusr 126.41 csys = 1398.37 CPU) 08:55
jnthn lizmat: Hm, that was 198s yesterday, no? :) 09:20
I remember 'cus I was like "huh, sub-200s, nice" :)
lizmat yeah, could be an artefact of something else going on on my computer at the same time 09:23
still, test-t was rather high as well
I run this always like 5am in the morning when my MBP has been dormant for a few hours 09:24
to give it the benefit of not getting throttled because the CPU is running hot
Geth rakudo/nom: 3b0dec3255 | (Elizabeth Mattijsen)++ | src/core/Exception.pm
Use pointy blocks for exceptions

And initialize at compile time. Should shave a little off of startup.		 09:56
Zoffix . 09:59
yoleaux 08:31Z <samcv> Zoffix: is there anyway we could have `dir :d` or `dir :f` to get all directories or all files etc?
jnthn Isn't there a test parameter for that? 10:00
Zoffix jnthn: lizmat we added more tests. The new locking test file take 20s to run, for example
jnthn Locking test file? 10:01
.say for dir(:test(*.IO.d))
Zoffix samcv: no, I don't want to add an overengineered routine to core, which is exactly what it'll end up being after we implement everything it's meant to do for recursive file search.
jnthn Works :)
samcv ok. you know better than i do
Zoffix jnthn: IO::Handle.lock tests
jnthn Oh, that kind of lock :)
samcv i will defer to your judgment
jnthn It's a little unfortunate the test parameter is passed a string in dir though 10:02
I'd hoped I could just write dir(:test(*.d))
*.IO.d means you need to be really careful if you're not doing the CWD 10:03
(And so maybe have to prepend something to it before .IO-ing)
At which point it'd have been easier to just "next unless .d" :) 10:04
Or .grep(!*.d) I guess :)
uh, just *.d :)
Zoffix ... why does it have :Str param -_- 10:05
jnthn But yeah, I agree with Zoffix++; it's only a few more chars to grep it out
Zoffix: I don't know. Maybe from when IO::Path was costly to construct so you could filter cheaper just on Str?
But...that's not really a good reason :)
lizmat Zoffix: is that test file marked as "slow" ? 10:14
Zoffix samcv: There's depth-first or breadth-first; follow symlinks or not follow them, if you follow them, detect loops or not detect; stop when you find something or keep recursing; stop when you've recursed $n levels deep or keep going forever; stop when you found $X files or keep going, etc. 10:15
samcv: after gdflex submitted his PR I proposed a module be made first. Don't recall anyone ever making one (other than File::Find) 10:16
lizmat: yup
lizmat :-) 10:17
samcv well then. 10:18
a module must surely be made!
by someone! eventually
Geth rakudo/nom: 736be4d40f | (Elizabeth Mattijsen)++ | src/core/List.pm
Make List.AT-POS about 5% faster for common path

Not a lot, but could very well noticeable in some situations.		 10:31
Zoffix Maybe I'm gonna start one. Just make a basic implementation that people are proposing and then open a bunch of Issues every time I think of a usecase it doesn't handle :P 10:41
samcv :) 10:51
Zoffix samcv: it took me until now to realize your weren't asking for recursive dir..... 11:18
samcv nope
not recursive
but that could be cool too i guess. but. i think getting all the files in a folder should be very simple to do 11:20
or all the directories as determined by .d or .f
i'm not expecting anything except the exact same evaluation the .d or .f things already check for 11:21
night o/ Zoffix keep up the good fight 11:28
Zoffix The dir '/foo/bar', :test(none '.', '..', *.IO.d) would be it, but there's a bit of a tweak needed. Even if you give :CWD to dir, it only uses it for making paths and test doesn't use it
Even strangely... the test doesn't use $*CWD set by &indir either :S 11:29
night
dir('/foo/bar').grep(*.d) should work too 11:30
actually cheaper too, since you don't need to make Io::Paths twice 11:31
m: indir '/tmp', { say $*CWD; dir :test{ say $*CWD; exit}} 11:42
camelia "/tmp".IO
"/home/camelia".IO
Zoffix doesn't get how that happens
m: sub dir2 ($test) { gather { $test.ACCEPTS: "foo" } }; indir '/tmp', { say $*CWD; dir2 { say $*CWD; exit} } 12:01
camelia "/tmp".IO
"/home/camelia".IO
Zoffix m: sub dir2 ($test) { gather { $test.ACCEPTS: "foo" } }; indir '/tmp', { say $*CWD; @ = dir2 { say $*CWD; exit} }
camelia "/tmp".IO
"/tmp".IO
Zoffix That's some caveat :S
m: sub dir2 ($test) { gather { temp $*CWD = "/tmp"; $test.ACCEPTS: "foo" } }; indir '/tmp', { say $*CWD; dir2 { say $*CWD; exit} } 12:02
camelia "/tmp".IO
/tmp
Zoffix Luckily fixable..
nine likes composable APIs 12:35
jnthn TimToady: I think rt.perl.org/Ticket/Display.html?id=131187 may be uncurse fallout, if you get chance to take a look 12:46
Geth nqp/master: 6 commits pushed by (Pawel Murias)++ 12:48
nqp: 8700dcc6aa | (Pawel Murias)++ | src/vm/js/nqp-runtime/deserialization.js
[js] Update comment
 12:49
AlexDaniel yes, if I recall correctly these 20 unbuildable commits are due to uncurse merge 13:19
nine m: Lock.new.protect: 1 13:25
camelia Attempt to unlock mutex by thread not holding it
in block <unit> at <tmp> line 1
nine Now that's an odd error, considering that protect has a signature of rotect(Lock:D: &code) 13:26
Zoffix m: Lock.new.^lookup('protect').candidates».signature.say 13:28
camelia ((Lock:D $: &code, *%_))
Zoffix m: with Lock.new { .protect: 42 }
camelia Attempt to unlock mutex by thread not holding it
in block <unit> at <tmp> line 1
jnthn m: class C { method m(&foo) { LEAVE say 'lol' } }; C.m(1) 13:29
camelia lol
Type check failed in binding to parameter '&foo'; expected Callable but got Int (1)
in method m at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn That's why :)
nine In case anyone wonders: discovered this by commenting out the code in the block when debugging. Turning the block into an empty hash. 13:30
Zoffix oh wow 13:32
jnthn: is that considered a bug? 13:33
ZOFVM: Files=1241, Tests=133747, 110 wallclock secs (21.48 usr 3.07 sys + 2283.75 cusr 133.53 csys = 2441.83 CPU)
jnthn I don't think so
I mean
sub foo($handle = open('foo', :r)) { LEAVE $handle.?close; blah } 13:34
Zoffix Ah right :)
jnthn Wouldn't work and could be also reported as a bug if we did things the other way :)
nine m: class C { multi method m(&foo) { LEAVE say 'lol' } }; C.m(1) 13:36
camelia Cannot resolve caller m(C: Int); none of these signatures match:
(C $: &foo, *%_)
in block <unit> at <tmp> line 1
nine An easy workaround ;)
Zoffix heh
jnthn heh, yes :) 13:37
I think the LEAVE behavior is OK, but Lock.protect wants hardening 13:38
nine Would be a lovely example for some advanced Perl 6 class, I guess.
jnthn It'd at present also try to release it if we somehow got an exception when trying to acquire it
AlexDaniel c: 2016.10,2016.11 Lock.new.protect: 1
committable6 AlexDaniel, gist.github.com/a799a3f15ddb370497...36987c7cae
AlexDaniel fwiw github.com/rakudo/rakudo/commit/48...8fe593eaca 13:40
nine Ah, used to be a CATCH block but now uses LEAVE
jnthn Yes
That fixed a nasty bug :)
Where a control exception causing an unwind wouldn't unlock things 13:41
nine m: class C { method m(&foo) { { LEAVE say "lol" } } }; C.m(1)
camelia Type check failed in binding to parameter '&foo'; expected Callable but got Int (1)
in method m at <tmp> line 1
in block <unit> at <tmp> line 1
nine Another very simple workaround
Also easy to find, once you accept that argument checking is really just part of the method body.
jnthn: anything against committing that block workaround? 13:42
jnthn It doesn't solve the second thing I mentioned :)
I was going to have a my int $acquired; npq::lock(...); $acquired = 1; LEAVE $acquired && nqp::unlock(...)
nine Ah, just now read that
I guess that's also far more self documenting :) 13:43
nine is back to fixing that precomp unit cache invalidation issue
jnthn has been hunting down why SSH::LibSSH just effectively hangs on connection errors 13:44
Zoffix oh boy 13:59
IO::Path.dir has an annoying bug it
in it
$ perl6 -e 'my @a = (item (dir "/tmp")) xx 2000; put @a».[2]'
Failed to get the directory contents of '/tmp': Failed to open dir: 24
If you don't exhaust the iterator, it never closes the open dir. And looks like you can open at most 1024 dirs or something 14:00
dogbert17_ you're using up your process file handles
Zoffix No, Perl 6 does. I'm not dealing with any handles 14:01
Zoffix contemplates :$limit argument 14:04
dogbert17_ how will Zoffix get a handle on this problem :) 14:11
Zoffix And the recursive &dir PR also has this issue. Would crash on trees with lots of dirs: github.com/rakudo/rakudo/pull/1045 14:13
Zoffix doesn't feel bad about rejecting it
dogbert17_ incidentally, spectest with harness6 and the default TEST_JOBS=1 also suffers from this, one handle per test file is used up so if your limit is 1024 you're out of luck
Zoffix uhh
dogbert17_: I don't get why TEST_JOBS would affect it 14:14
Or why that problem is there. Sounds like someone's forgetting to close the handles
dogbert17_ test
TEST_JOBS=1 and TEST_JOBS=1+ have different code paths
to be more specific, the problem is in TAP.pm6 14:16
Zoffix yeah 14:17
Zoffix gives up trying to find where it opens files
Wonder if it's just me. TAP.pm is a bowl of spaghetti
dogbert17_ agrees with Zoffix 14:18
Geth rakudo/nom: b2a64a1383 | (Zoffix Znet)++ | src/core/IO/Path.pm
[io grant] Fix $*CWD inside IO::Path.dir's :test Callable

Fixes two issues: 1) When user passes :CWD arg, the expectation would be that
   :CWD is available as $*CWD inside :test
2) Because we use `gather` by the time we get to run the :test
   Callable, we might already be outside even a user-set $*CWD,
... (7 more lines)		 14:19
roast: 41b7f9f6aa | (Zoffix Znet)++ | S32-io/dir.t
[io grant] Test $*CWD in IO::Path.dir(:test) Callable

Rakudo fix: github.com/rakudo/rakudo/commit/b2a64a1383		 14:21
Zoffix dogbert17_: does it crash right away or do I need to wait for it to do 1000+ test files? 14:22
which is basically the whole test suite... and is about 40m run, I'm guessing
dogbert17_ Zoffix: you'll have to wait :(
Zoffix OK. Plan B: make 2000 small test files and use them 14:23
dogbert17_ a nifty trick
even if you do it the slow way, the problem is easy to observe by means of peeking into /proc/<main perl6 pid>/fd 14:24
Zoffix hmm, it isn't much faster with small files :o 14:26
only 10 files per second or so
dogbert17_ so two minutes then :) 14:28
Zoffix cheats with ulimit -n 50 14:29
dogbert17_ :)
Zoffix Well, just says "Aborted" I was hoping --ll-exception would give me the line with open call 14:30
dogbert17_ perhaps it's libuv which does the aborting 14:31
nine break on abort() in gdb and then do call MVM_dump_backtrace(tc) 14:32
Zoffix doesn't seem to be working with perl6-gdb-m just stops right away with "[Inferior 1 (process 18237) exited normally]" 14:34
nine set follow-fork-mode child 14:35
Zoffix no effect
MasterDuke_ anyone know the history behind "Inferior 1"? does gdb just have a really high opinion of itself? what does it say if you try to run gdb inside gdb? 14:37
Zoffix dogbert17_: has this problem existed 2 months ago? 14:40
dogbert17_ Zoffix: what happens if you type 'q' followed by enter after you receive the Inferior message
Zoffix: yes 14:41
dogbert17_ I think
lizmat Zoffix: TAP.pm was someone's first attempt at writing idiomatic Perl 6 code, afaik 14:42
and I, for one, am glad he did that
Zoffix dogbert17_: seems to be running, but glacial pace 14:43
lizmat: I'd be gladder if it at least came with docs :|
lizmat: I'm just thinking.. is all of this stuff necessary? We're just running a bunch of tests. leont made p5's harness didn't he? So I guess he knows better, but this code is really hard to follow 14:44
dogbert17_: well, it ran one file and isn't doing anything else it seems 14:45
Just stuck
MasterDuke_ lizmat: did you see my comment on your Exceptions.pm commit? 14:46
nine: you said you were interested in seeing which routines called a specific other routine in a profile? i think i have it, but do you a use case or something i could test with? 14:47
Zoffix I only see 2 slurps and no opens() in TAP... Wonder
dogbert17_ multi get_runner(Source::File $file; TAP::Entry::Handler @handlers) ... 14:48
nine MasterDuke_: Inline::Perl5 spends most of its time in NativeCall code, so CALL is usually on the top of the list. But there's plenty of places which call into NativeCall. 14:49
Zoffix dogbert17_: is that were it crashes at? 14:50
MasterDuke_ nine: so i could just do some random stuff with Inline::Perl5, profile it, and see if i can tell where CALL is called? 14:51
nine yep 14:52
lizmat Zoffix: re doc, most of internals suffers from not enough doc :-(
Zoffix: re leont, last time I spoke to him, he said he wanted to spend more time on it again, perhaps doccing could be an attention point :-) 14:53
Zoffix \o/
lizmat the last time I looked at TAP.pm, it wasn't easy to get into 14:54
Zoffix dogbert17_: hm, when I set TEST_JOBS=2, and strace it, it crashes with write(12, "Could not create a new Thread: t"..., 50Could not create a new Thread: too many open files) = 50
lizmat but then, HARNESS_TYPE=6 didn't work very well either because of many race issues
so I didn't pursue at the time
Zoffix This crashes with too many open files: my @procs = ^2000 .map: {Proc::Async.new("cal").start}; sleep 10 14:56
dogbert17_: so maybe the crash in TEST_JOBS=1 is due to that and when you use more JOBS you don't hit the limit, because they finish off faster. 14:57
dogbert17_: but I do get the crassh with TEST_JOBS=1+ when I ulimit -n 50
lizmat Zoffix: is lib/TAP.pm6 still tracked in the rakudo repo ? 15:04
MasterDuke_ nine: do i need to install Inline::Perl5? or should just `-I <path/to/>/Inline-Perl5/lib/ -e 'use Inline::Perl5; use List::Util:from<Perl5>' work? 15:05
nine Both should be fine 15:06
Even perl6 -I <path/to/>/Inline-Perl5/lib/ -e 'use List::Util:from<Perl5>'
MasterDuke_ ooh, do i need perl5-dev (i'm on ubuntu) or something like that installed? 15:07
nine yes
If the README is missing some part about installation, please tell me :)
Geth rakudo/nom: ca0a74398b | (Stefan Seifert)++ | 3 files
Replace error-prone file timestamp check by checksum when loading deps

File modification timestamps are unreliable as file systems may have a granularity of 2 seconds. In addition, packagers may limit time stamps to certain ranges for making build results reproducible.
We've already used checksums instead of timestamps for precompilation units themselves. Now we also use checksums for checking a precompilation unit's source file.
ilmari MasterDuke_: libperl-dev
rakudo/nom: 89f2ae4f14 | (Stefan Seifert)++ | src/core/CompUnit/PrecompilationRepository.pm
Simplify code for loading a precomp unit's dependencies

We're not supposed to know that the precompilation store deals with files and anyway, load-unit will just return Nil if the store doesn't contain the unit. So instead of looking for a store that has an existing file for the dependency and then loading the unit from that store, just take the first unit any of our stores gives us.
MasterDuke_ ilmari: thanks
Zoffix dogbert17_: without messign with you limit, I ran TEST_JOBS=1 with 2000 `ok 1` test files without trouble 15:09
MasterDuke_ nine: i just checked and i do have libperl-dev installed, but i'm getting an error trying to use I::P5 15:10
nine what error?
MasterDuke_ gist.github.com/MasterDuke17/ab04d...3f63fb3637
nine MasterDuke_: you don't have to install it, but at least build it: perl6 configure.pl6 && make 15:11
MasterDuke_ ah, good to go now, thanks 15:12
and that is in the Building section of the readme, i didn't read far enough 15:13
nine Maybe I really should move that section up. But OTOH I've always hated READMEs that tell me how to install first, because usually I have the software installed already (from a distro package or CPAN) 15:14
MasterDuke_ maybe just a link at the top down to that section? 15:15
"if installing manually, instructions <here>" 15:16
and yeah, last time i used Inline::Perl5 it had been installed from a distro package, so i had never seen that error before
star: use Inline::Perl5; use List::Util:from<Perl5> <shuffle>; my @a = shuffle ^10; dd @a 15:21
camelia ===SORRY!===
Could not find Inline::Perl5 at line 1 in:
/home/camelia/.perl6
/home/camelia/star-2016.10/share/perl6/site
/home/camelia/star-2016.10/share/perl6/vendor
/home/camelia/star-2016.10/share/perl6
CompUnit::Repository…
MasterDuke_ nine: should ^^^ shuffle the array? it doesn't locally 15:22
oh, i have to slip it 15:24
nine: CALL-ME? 15:37
nine ah, yes 15:39
Zoffix ZofBot: but here's my object, so CALL-ME maybe 15:40
ZofBot Zoffix, ) It's also possible to explicitly specify a normal autoextending array: my @vices[*]; # Length is: "whatever" # Valid indices are 0
nine It's been a while since I have looked at performance :) Looks like I've still a comfortabl 2 second lead ;)
Scary: we're actually rather close to being able to ship binary packages for modules... 15:55
Zoffix lizmat: I missed the question. Currently yes, but I'm hoping to remove it this weekend and make `make` pull the version from github.com/perl6/tap-harness6 15:56
lizmat Zoffix: ok, just wanted to make sure I hadn't missed anything in that respect
no hurry from my side :-)
nine Zoffix: please don't! 15:57
Zoffix: building rakudo should not do any network access. That won't fly with distro build services
lizmat nine: but roast is also fetched over the network 15:59
so ?
nine lizmat: not as part of a plain build.
lizmat TAP.pm6 is only needed for testing
not as part of the build, afaik
nine For make test?
lizmat but for make test we don't need TAP.pm6 do qwe ? 16:00
nine If only make spectest pulls tap-harness6, I'm of course completely fine with it :) 16:02
Zoffix Yeah, only spectest 16:03
I'm guessing we could even shove the pulling it into t/harness6 itself
rather than make
nine But....TAP is currently part of the CORE dist
Zoffix Yeah, it'll be removed
lizmat dinner&
Zoffix Unless we plan for Rakudo's `make test` to use Perl 6 harness too? 16:09
MasterDuke_ nine: i profiled this `use Inline::Perl5; use List::Util:from<Perl5> <shuffle>; use List::MoreUtils:from<Perl5> <minmax>; my @a = shuffle |(^10); my @b = minmax |@a; dd @b;`, and found CALL-ME was only called here github.com/rakudo/rakudo/blob/nom/....nqp#L2992 16:16
does that seem right? 16:17
nine This CALL-ME? github.com/rakudo/rakudo/blob/nom/...l.pm6#L327 16:25
MasterDuke_ yep 16:40
TimToady jnthn: yes, that's almost certainly uncurse related; unifying $!to with $!pos was a slight overreach 17:24
I've been thinking about disunifying those anyway to save allocation of a bunch of position-only cursors for trailing ws 17:25
and <( )> can probably use the same distinction between $!to and $!pos
it's one more attribute but a bunch fewer cursors 17:26
which is probably a win
but I'll probably just add in the $!to first on the first-make-it-work-right principle 17:27
Geth roast: a8f1b96dd5 | (Stefan Seifert)++ | S10-packages/precompilation.t
We no longer depend on time stamps when checking dependencies
 17:29
nine MasterDuke_: do you get different callers for that BOOTSTRAP code? I've never looked closely at what's between Inline::Perl5 and that CALL-ME. 17:30
MasterDuke_ call-args on line 757, p6_to_p5 on line 279, Array on line 545, p5_to_p6 on line 621, and some anonymous block on line 626 (all from Inline-Perl5/lib/Inline/Perl5.pm6) 17:43
jnthn TimToady: Ah, that would explain it, yes. 18:05
MasterDuke_ timotimo: if you see my conversation with nine earlier, i think i can now find the routines that call a specific routine in a profile. can you give me a use case to test with? 18:50
Geth nqp: a5337ff305 | TimToady++ | 3 files
separate the $!to concept back out from $!pos

This will allow )> to work correctly again. It may also give us the opportunity to optimize away <.ws> cursor creation by just tacking it onto the previous capture cursor as a $!pos update that doesn't affect $!to. This in turn will cut down on $!cstack usage and scanning overhead. In some cases it may allow us to steal the cstack directly for a match list, without having to grep out the non-capture cursors.
Also did some Num suppression on subtractions that might not know their operand types and default to Num.		 19:25
rakudo/nom: 5d68f1ff1a | TimToady++ | 2 files
fix )> to work again whenever .MATCH is called

The unification of $!to and $!pos in the uncurse branch caused the )> construct to malfunction if .MATCH was not called at the right time. This version uses the newly patched nqp that distinguishes $!to from $!pos again.
  (Note that all internal access to $!to should be through the .to method,
since it might or might not defer to $!pos.)
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-ga5337ff
3cff74cf5a | TimToady++ | tools/build/NQP_REVISION

fixes #131187
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131187
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-ga5337ff
9962d2b652 | (Elizabeth Mattijsen)++ | src/core/Setty.pm
TimToady dunno if that merits a point release or not...
certainly worth getting into Star though 19:27
lizmat which would imply a point release
feels to me anyway
TimToady nod
TimToady wonders which modules that fixes... 19:30
MasterDuke_ lizmat: did you see my earlier question about your Exception.pm commit?
lizmat MasterDuke_: no, I haven't 19:31
MasterDuke_ ok, was wondering if there was a reason you didn't make the same change to the exception i added? 19:32
TimToady fixes File::Ignore anyway...
lizmat MasterDuke_: no reason, I just git stash popped something that was from before you added that one
and I didn't notice 19:33
will do so now
MasterDuke_ ah ha, i suspected that exact cause
TimToady
.oO(SETI has found infinite Setties on Alpha Settari!)
 19:37
Geth rakudo/nom: 9ed89d9472 | (Elizabeth Mattijsen)++ | src/core/Exception.pm
Oops, forgot X::Trait::Invalid

  MasterDuke++ for pointing out		 19:42
[Coke] is super concerned about the fact that we had not one but multiple point releases and are continually talking bout more. 19:45
might be time to think about moving to a more structure branch and release strategy.
Zoffix [Coke]: sounds good. How about adding a 1-month delay for released stuff? So, if we start now, make a release branch and nothing gets into it for a month. Beta testers are encouraged to use the release branch (would be nice to make rakudobrew to default to it). Then, on next release, we release from release branch the stuff that marinated and seen some use for a month to weed out all issues. In addition, 20:15
we add a bot that stresstest and tries rakudo HEAD on a bunch of trusted modules daily. This way we'll find any ecosystem fallout. The release requirement will also be to test modules installation as well as multi-OS testing (this can ne automated by making NeuralAnomaly spin up a bunch of VMs with different OSes on release)
And we only fix breaking stuff in release branch. All other features and bug fixes go to HEAD 20:16
and by HEAD I mean HEAD of nom branch
lizmat FWIW, I think the current release's breakage would have been covered had we had a cpan-testers like thing for the ecosystem 20:19
timotimo oof, #perl6-dev is the slower of the two and it's still too much for me to backlog over comfortably >_< 20:20
nine I'm with lizmat. Noone tests release branches. 20:21
Linux distributions are learning that lesson, too. openSUSE is moving towards their rolling release distro which helped greatly by their openQA automated integration testing. 20:22
timotimo MasterDuke_: you see, while "repairing" rc-forest-fire off of rosettacode's Forest Fire page, i stumbled upon "bind" being called a crapton. let me see what it was before i changed stuff around
nine So we should at least include emmentaler in the release process but much better would be fully automated testing of every single commit. 20:23
timotimo "for @!coords -> ($i, $j) {"
this one asploded it
nine That could be a good topic for the Perl Toolchain Summit
timotimo so i changed @!coords to have a "flat" in front when it was generated, and then removed the ( ) around $i, $j 20:24
and that made it a crapton better
lizmat nine: agree
Zoffix lizmat, the Repl bug would't as neither we nor linenoise had tests covering it. The left over debug print... hard to test, again this would rely on test coverage; do any tests test for extraneous output during program run; especially in a somewhat uncommon usecase 20:26
And I don't know if latest uncurse bug was found by tests 20:27
japhb timotimo: Is your rc-forest-fire change a correctness problem or a performance bug?
*to fix a
Zoffix nine, even with zero user testing of release branch we wouldn't have had any point releases this month as all the bugs would be found by users testing nom 20:28
as well as devs have a chance to realise there's a bug or LTAness in their recent commit and fix it 20:29
And I know some devs stop committing a few days before release; with a release branch they wouldn't need to 20:30
timotimo japhb: errrr, i'm not sure any more. but i did get it blazing fast by the end 20:31
Zoffix hell, it don't have to be a month wait. freeze release branch 1-2 weeks before release.
timotimo japhb: it turned out at some point Enum ~~ Enum got mangled so it went via Num ~~ Num, which had not only two blocks inside it, but also had to isinfornan self before going on 20:32
the Enum ~~ Enum candidate i created for this reason is in the recent releases iirc, and the improved Num ~~ Num candidate, too
japhb wonders what "blazing fast" actually means in this case .... 20:33
timotimo hm
japhb I have high standards on that one. ;-)
timotimo 21.62user 0.19system 0:21.91elapsed 99%CPU (0avgtext+0avgdata 111900maxresident)k - this is a 40x40 field at 1_000 iterations 20:34
not shabby.
japhb So about 50 fps at 40x40? Yeah, that's a decent start. 20:36
timotimo now that our profiler output is fixed ... 20:37
it's a good sign when the first four routines are all green :) 20:38
japhb :-)
timotimo i should be fixing the random seed 20:42
wow, we have a frame <anon> in file <unknown> at line <unknown> that's creating a crapton of Int objects 20:43
oh my. the ratios for whether a tree should be made or a tree should catch fire are Rat objects, we're comparing a whole lot of Num objects generated by rand against them 20:44
turning these into Num cut off like half a second only, though 20:45
not such a huge impact either way. 20:46
the step function takes 70% of time, show 30% 20:48
hello, 16.7s 20:52
@foo[$i;$j] is a bit more expensive than @foo.AT-POS($i).AT-POS($j)
Zoffix Another problem with releases we have: think of all the features we added since Dec 2015. None of them are "official" Perl 6. Policy-wise, we could nix parse-base and parse-names and anything else we added. Yet all this stuff is both documented and in use. In 6.d we should try to do more point releases of language or something. Non-breaking changes that declare that feature XYZ can officially be used
[Coke] Agreed, that can be part of the 6.d plan (and release announcement about how we're tightening the policy a bit) 20:53
timotimo the innermost block, which is four "when" inside a "given", spends 27.67% of its time in "succeed"
ugh, all succeed does is call THROW, but only 73% of its time is spent inside THROW 20:55
Zoffix [Coke]: xtest... yeah. I'll be doing more grant work this weekend and will ensure to run xtest by end of Monday 20:59
And will run one today, when I get home
timotimo oh hello 14 seconds (turned the whens into an if/elsif
[Coke] danke. just getting p6doc building on my new mactop.
timotimo aha, it doesn't matter to put a --> Nil on the block we're for-ing if it has two arguments because we only specialcase for one argument when "not slippy" 21:14
though actually the problem isn't that. i's going through sink-all already 21:15
i guess i was hoping the return value of Nil would cause it to sink without calling .sink on anything
succeed tries to sink the return value of THROW-NIL, which is defined to be Nil :( 21:18
actually, the throw isn't supposed to return at all 21:19
so where does the overhead come from ...
oh, i didn't realize it was calling succeed($x) all this time 21:20
jnthn TimToady: Thanks for the fix; did I miss a test going in, or shall I add my golfed example to roast? 21:43
TimToady I did not add a test
jnthn k, will do, so we've got it covered in roast as well as a module :) 21:44
timotimo Zoffix: i think the multiple dispatch explodes when it's trying to invoke the here clause
maybe we have to put Any:D in front so it'll refuse to try to run the where clause
i'll ask robertle to try that locally
Zoffix: thanks for giving that tool the much-needed cleanup! 21:45
i'm not sure if i Zoffix++ when you did
Zoffix Ah, right. 21:49
m: sub (Str $x where try .IO.e) {}(Str)
camelia Constraint type check failed in binding to parameter '$x'; expected anonymous constraint to be met but got Str (Str)
in sub at <tmp> line 1
in block <unit> at <tmp> line 1
Zoffix m: multi foo (Str $x where try .IO.e) { say "here"}; multi foo ($) { say "there" }; foo Str 21:50
camelia there
Zoffix m: multi foo (Str $x where try .IO.e) { say "here"}; multi foo ($) { say "there" }; foo "/tmp"
camelia there
timotimo anyway, i committed a little patch for it 21:51
oh, you PR'd it, too
sorry
Zoffix I liked your fix better 21:52
timotimo oh
it ended up with a combination of both, it seems like? 21:53
i.e. the :D and the try
Zoffix timotimo: 'cause I used online editor and didn't realize you commited a fix
Geth roast: 09d099bae3 | (Jonathan Worthington)++ | S05-metasyntax/angle-brackets.t
Test to cover RT #131187.
 21:54
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131187
ugexe $ perl6 -e '\
say 1;\
'
why doesn't that work? (same with perl 5)
Zoffix Some shell escaping stuff? Works fine without those slashes 21:55
ugexe its the same in the repl 21:57
Zoffix How do you make it in the repl?
ugexe just say 1;\ return
Zoffix I get {}
ugexe yeah
Zoffix Dunno 21:58
$ perl6 --target=parse 21:59
===SORRY!===
Too many positionals passed; expected 1 argument but got 3
There's this ticket that feels to be somewhat in similar vein: rt.perl.org/Ticket/Display.html?id...et-history 22:00
timotimo Zoffix: i put the greps for SETTING:: (well, what it was before the names changed) in there mostly because i didn't want to see coverage of the .t files from the test suite. maybe the greps are unnecessary in total because you can just preprocess the coverage reports? 22:01
Zoffix dunno 22:02
timotimo you think a --usermode switch would be a good idea?
Zoffix ¯\_(ツ)_/¯ 22:04
Maybe --coremode?
and usermode be default
Zoffix & 22:05
timotimo that's sensible, as we core haxors know What We Are Doing (and we know What We Are Doing Is Kinda Bad) 22:07

Powered by Cro and the Raku® Programming Language.

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

Thank you!