travis-ci Rakudo build passed. Zoffix Znet 'Do not warn in explicit sink of variables 03:56
travis-ci.org/rakudo/rakudo/builds/328406168 github.com/rakudo/rakudo/compare/e...da4a5a6c45
AlexDaniel R#1403 05:41
synopsebot R#1403 [open]: github.com/rakudo/rakudo/issues/1403 Consider removing the :caption key from table POD’s %config hash
AlexDaniel tbrowder: fwiw, if you write it like this ↑, then the bot automatically generates a link :)
reportable6: list 07:02
reportable6 AlexDaniel, gist.github.com/8f23f74d9cac31b023...c88f471012
AlexDaniel reportable6: 2018-01-08T00:00:00Z 2018-01-15T00:00:00Z 07:03
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/e32f56c162a27c4e01...c035964fbc 07:04
travis-ci Rakudo build passed. Zoffix Znet 'Add node info to ±Inf/NaN num constants' 07:42
travis-ci.org/rakudo/rakudo/builds/328415384 github.com/rakudo/rakudo/compare/9...188757dc93
|Tux| Rakudo version 2017.12-222-gd0be53a1e - MoarVM version 2017.12.1-32-g56c03d99c
csv-ip5xs1.089 - 1.103
csv-ip5xs-2012.746 - 13.228
csv-parser12.147 - 12.314
csv-test-xs-200.456 - 0.503
test11.112 - 11.210
test-t2.756 - 2.804
test-t --race1.111 - 1.141
test-t-2048.951 - 49.276
test-t-20 --race16.584 - 16.990
10:25
lizmat Files=1232, Tests=75995, 324 wallclock secs (14.72 usr 5.22 sys + 2250.03 cusr 226.87 csys = 2496.84 CPU) 10:41
jnthn Same but 177s :) 11:01
lizmat how many cores ? 11:05
jnthn 6p, 12v 11:06
timotimo 6 pascal over 12 volts 11:19
lizmat jnthn: I bet that doesn't fit in a notebook 11:33
jnthn Probably not, but a notebook doesn't fit me, so... :) 11:34
jnthn is currently case-analyzing single-whenever react/supply blocks, to hopefully give them a nice performance boost 11:35
pmurias do we have a graph how rakudo performance is changing across (releases/commits)? 11:37
DrForr Tux has been doing a great job on doing benchmarking, though I don't know how much (if any) the recent Meltdown/Spectre bugs have caused an issue... 11:40
|Tux| pmurias, tux.nl/Talks/CSV6/speed4.html - date-based, not commit based 11:42
timotimo [Tux]: could we also get graphs that zoom in on the horizontal axis? 11:43
like, the lowest three graphs starting in 01-Jul, so we get double the horizontal resolution?
AlexDaniel releasable6: next 11:45
releasable6 AlexDaniel, Next release in 5 days and ≈7 hours. No blockers. Unknown changelog format
dogbert2 t/spec/S03-operators/short-circuit.t is still failing for me 12:16
pmurias [Tux]: thank you 12:30
jnthn Looks like a factor of 3-4 improvement through the assumptions we can make about single top-level whenever suppy/react blocks 13:41
travis-ci Rakudo build passed. Zoffix Znet 'Warn on ±Inf/NaN in sink context
travis-ci.org/rakudo/rakudo/builds/328415557 github.com/rakudo/rakudo/compare/0...c9dc469549
lizmat jnthn: not bad :-) 13:42
Geth rakudo/supply-syntax-opts: 13 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/d...4804003acc
13:54
jnthn That's just a rebase on master for easier spectesting
Geth rakudo/supply-syntax-opts: e5f412d696 | (Jonathan Worthington)++ | 3 files
Special-case one top-level whenever supply/react

When the supply or react block ends with a single top-level whenever
  (this is the case in the non-block form, but also the block form when
some setup is done followed by a `whenever`), then we can simply call
  `serialize` on that Supply (which is a no-op in many cases) and that
is sufficient concurrency control. Thanks to the data structures that ... (5 more lines)
jnthn And that's the interesting commit :)
lizmat jnthn: recently you changed some assignments to binding, to reduce the number of scalar allocations 13:56
jnthn Yes
lizmat is there a reason you use assignment here, e.g. in REACT-ONE-WHENEVER ? 13:57
jnthn It's a copy of REACT and I didn't optimize that yet :)
lizmat ok :-)
jnthn It wasn't such a hot path
(I was looking at sources of Scalar allocations and started at the most guilty :))
Zoffix Any easy way to find out if a QAST::Op.new(:op<call>, :name('&infix:<|>')) would call the core op? 13:59
jnthn A week ago, `my $s = supply emit 42; for ^100_000 { react whenever $s { } }` ran in 29.49s. Now it's 5.51s.
Zoffix * Find out from within Actions I mean
lizmat i just browsed the commit :-)
jnthn Yeah, 'tis an easy win though, so will do it :)
lizmat++
Zoffix: As in, will be producing a Slip rather than be turned into a flattening? 14:00
lizmat jnthn: perhaps related: does adding an "is raw" to s sub also help in e.g. sub SUPPLY-ONE-WHENEVER ?
Zoffix jnthn: infix. A Junction call.
jnthn Oh, damn 14:01
No, you can't figure that out in Actions.nqp
Zoffix OK. Thanks.
jnthn Because an infix:<|> might be declared waaay later
Optimizer.nqp is the right place for such things
There's even a way in there to ask if something is the version from the setting 14:02
Zoffix Yeah, I saw that one.
Is there a way to attach a QAST to a Code/Block object? I saw @!comp_stuff in Code, but it seems it's not available early enough
jnthn Not really sure what you mean 14:04
But "probably not" 14:05
Zoffix Basically, I got this patch to gen optimized QAST for `$ where Int|Num|Whatever` signatures. It does it only for fast path binding and for slow binder it uses the old-style code block `where` and the way it does it is it makes an nqp::list with Code and QAST and in post_consraint codegen it grabs the QAST and changes the list to Code to use in the slowpath. BUT, it'll do this even for user's &infix:<|> and 14:07
I want to do this only for core Junction op. And if there's no way to find if it's a core op in Actions, I was thinking of sticking that QAST to the Code and swapping it in Optimizer instead: gist.github.com/zoffixznet/17fb70a...ff180acf5e
jnthn Why can't you do the whole transformation in Optimizer? 14:08
Can always .annotate the post_constraint code that you'd need to fix up to help you robustly find it 14:09
Zoffix OK. I'll give that a go. Thanks. 14:10
jnthn: do you mean gen the optimized where code in Optimizer too? 14:11
The `sub optimized-where-block` in my diff 14:12
jnthn Yes 14:14
Zoffix Cool. I'll give it a go 14:15
dogbert2 Zoffix: do you know why t/spec/S03-operators/short-circuit.t is failing, is it WIP? 14:20
Zoffix dogbert2: it's not failing for me 14:29
dogbert2 Zoffix: test #84 subtest #3: not ok 3 - 4-arg, with all but last args wanted 14:39
# Failed test '4-arg, with all but last args wanted'
perhaps I'm the only one though
Zoffix dogbert2: what's your Perl 6 version? What's the full output of perl6 -e 'uc "foo" xor "bar".uc xor "ber".uc xor "baz"' 14:45
dogbert2 This is Rakudo version 2017.12-222-gd0be53a1e built on MoarVM version 2017.12.1-30-ged7c1234f 14:46
dogbert@dogbert-VirtualBox ~ $ perl6 -e 'uc "foo" xor "bar".uc xor "ber".uc xor "baz"' 14:47
WARNINGS for -e:
Useless use of constant string "baz" in sink context (line 1)
Zoffix: ^^
Zoffix dogbert2: what's the full output of test failure? 14:48
dogbert2 1..3 14:49
ok 1 - 2-arg
ok 2 - 4-arg
not ok 3 - 4-arg, with all but last args wanted
# Failed test '4-arg, with all but last args wanted'
# at /home/dogbert/repos/rakudo/t/spec/packages/Test/Util.pm (Test::Util) line 111
# got err: "WARNINGS for /home/dogbert/repos/rakudo/getout-11177-448646.code:\nUseless use of constant string \"baz\" in sink context (line 1)\n"
# Looks like you failed 1 test of 3
not ok 84 - xor warns when used with bad precedence
Geth roast: 5ac1ebf6b2 | (Zoffix Znet)++ (committed using GitHub Web editor) | S03-operators/short-circuit.t
Use test strings less likely to be part of paths
14:52
Zoffix dogbert2: ^ that should fix it
dogbert2 it does :-) Zoffix++ 14:53
Zoffix k
Geth nqp: 88fbd344d3 | (Zoffix Znet)++ | src/QAST/Node.nqp
Remove trailing whitespace
14:55
nqp: 4e647a70b7 | (Zoffix Znet)++ | src/QAST/Node.nqp
Implement QAST::Node.annotate_self

Same as .annotate but return self instead of the value we're annotating with. Makes it easier to set annotations when you just wanna set them and return the Node; no need to save it into variable.
travis-ci NQP build passed. Zoffix Znet 'Implement QAST::Node.annotate_self 15:13
travis-ci.org/perl6/nqp/builds/329089336 github.com/perl6/nqp/compare/d2057...647a70b7e5
Geth nqp/post-release: e34595c66c | (Zoffix Znet)++ | 2 files
Avoid using variables where we don't need any

Make use of new .annotate_self
15:15
rakudo/post-release: 426a39a6ef | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Avoid using variables where we don't need any

Make use of new .annotate_self
15:46
|Tux| timotimo, scroll to the end of tux.nl/Talks/CSV6/speed4.html 16:26
timotimo oooh i like that 16:28
last 10 days is maybe a bit too far zoomed in, but still: nice!
lizmat moritz: looks like search on irclog is stuk on 18 Dec :-( 16:57
*stuck rather :-)
TimToady jnthn: from your description, your single-whenever optimization sounds kinda like the dual of TCO 17:00
lizmat Total Cost of Ownership ? 17:03
jnthn Tail Call Opt :) 17:04
Hm, didn't think of that :) 17:05
TimToady that's why I said it :)
moritz lizmat: thanks for the pointer; I'm trying to fix it now
|Tux| timotimo, what quadruple would you like better than 10, 30, 90, 180? 17:13
(u roept, wij draiien)
(u roept, wij draaien) 17:14
timotimo i'd just say have three instead of four
Geth rakudo/supply-syntax-opts: 4 commits pushed by (Jonathan Worthington)++ 17:24
rakudo/supply-syntax-opts: 2ac1ceaa1b | (Jonathan Worthington)++ | src/core/Promise.pm
Slightly faster Promise construction
17:53
rakudo/master: 19 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/d...2ac1ceaa1b
17:58
jnthn There's a merge of my supply work
bbl & 18:11
|Tux| timotimo, I prefer 4 because tux.nl/Files/20180115191444.png 18:14
|Tux| now off to badminton 18:15
timotimo ah, good point. if i zoom out more so i get that layout, that's probably fine 18:38
dogbert17 looks sceptically at RT #127587 19:45
synopsebot RT#127587 [open]: rt.perl.org/Ticket/Display.html?id=127587 [OSX] External process return values affecting react blocks
dogbert17 the line 'qq:x[ echo "echo: $phrase" ]' won't output anything unless e.g. say is used one it 19:47
lizmat dogbert17: $cmd.stdout.tap: *.say; ?? 19:51
dogbert17 is looking at the second example 19:52
lizmat if a class has a DESTROY method, and something calls that method *before* the object is actually destroyed
will the reaping of the GC call the DESTROY again when the object is *actually* destroyed ?
timotimo i think calling DESTROY doesn't do anything 20:05
lizmat m: class A { method DESTROY { say "bye" } }; A.DESTROY # looks like an ordinary method to me 20:11
camelia bye
timotimo yup, it's completely ordinary 20:12
i meant to say "it doesn't do anything magical"
lizmat ok 20:13
jnthn lizmat: Yes, you calling DESTROY on an object sooner doesn't affect finalization in any way 20:18
In fact the VM doesn't call DESTROY
lizmat so it would get called twice *if* it gets to that point
no?
jnthn It calls a handler with a list of objects that need finalizing
And just loops over them calling DESTROY
Yes, if you write a call to .DESTROY then you've violated the contract 20:19
lizmat ok, clear
jnthn role DestroyOnce { method DESTROYONCE { ... }; has $.destroyed = False; method DESTROY() { unless cas($!destroyed, False, True) { self.DESTROYONCE } } 20:21
That's a pretty robust way to implement at-most-once 20:22
(Copes with concurrent calls)
lizmat ok, but I don't think I'll need that
jnthn *nod* 20:23
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/01/15/...blue-note/ 20:56
jnthn lizmat++ 21:10
gfldex jnthn: did Cro benefit from your changes? 21:33
jnthn gfldex: Yeah, the branch I merged got ~12% more requests/second 21:34
gfldex nice :) 21:35
Zoffix So I got a WVal with Block: gist.github.com/zoffixznet/891363f...p6-p6-L101 and its guts are here: gist.github.com/zoffixznet/891363f...p6-L66-L85 22:09
Is there a trick to getting its guts when I'm at that WVal or do I need to annotate WVal with the guts? 22:10
Ah, it might be @compstuff[0] 22:16
Took me long enough to dump it, but yeah, Code's @!compstuff[0] attr containts the QAST for the block. 23:11