Zoffix What exactly controls whether last line of a `for` loop gets sunk? I thought I saw something somewhere, but failing to find it now. 03:35
m: say *,129431.uniname.lc,'s',* 03:51
camelia *crickets*
Zoffix ZofBot: do you know?
ZofBot Zoffix, He teased and bullied the other children in a way that is characteristic of the high-grade imbecile
Zoffix nm, I think I was thinking of something else. The sinkage is done by &unwanted 04:23
m: class Foo { method sink { say "sunk" }; method foo { self } }; Foo.foo for ^1 04:40
camelia sunk
Zoffix m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo }; foo for ^1
camelia ( no output )
Zoffix Wonder if there's a reason return value of subs don't get sunk of it's just an oversight
I guess we're in a for a perf drop. 04:49
m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo }; foo 04:52
camelia ( no output )
Zoffix The whole "`for` is a .map" thing needs to go, I think 05:46
m: sub foo { fail }; my &b = { Failure.new }; ^1 .map: &b; my @stuff = ^1 .map: &b 05:47
camelia ( no output )
Zoffix 'cause that ^ makes sense, but... 05:48
hm, maybe there's no but
Zoffix looks more at `&unwanted`
right no but 05:50
but some perf loss 05:51
AlexDaniel reportable6: list 06:12
reportable6 AlexDaniel, gist.github.com/07a5d72ab718643833...b57703154f
AlexDaniel reportable6: 2018-02-19T00:00:00Z 2018-02-26T00:00:00Z 06:13
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel reportable6: 2018-02-19T00:00:00Z 2018-02-26T00:00:00Z 06:14
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/600172f8ed3508eaca...76e19e46ea
AlexDaniel :S 06:15
Zoffix ?
AlexDaniel reportable6: 2018-02-19T00:00:00Z 2018-02-26T00:00:00Z 06:16
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel Zoffix: [new] RT#132911 [SPAM:##] CANADA RESETTLEMENT PROVINCIAL NOMINATION PROGRAMS
synopsebot RT#132911 [new]: rt.perl.org/Ticket/Display.html?id=132911 [SPAM:##] CANADA RESETTLEMENT PROVINCIAL NOMINATION PROGRAMS
AlexDaniel reportable6: 2018-02-19T00:00:00Z 2018-02-26T00:00:00Z
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
Zoffix heh
AlexDaniel also it segfaults every other run :)
reportable6 AlexDaniel, gist.github.com/2138ef220cb045b15f...61cde51016 06:17
AlexDaniel o much better
weekly: reportable: gist.github.com/2138ef220cb045b15f...61cde51016
notable6 AlexDaniel, Noted!
AlexDaniel notable6: weekly 06:18
notable6 AlexDaniel, 2 notes: gist.github.com/17fafa0872c943866b...e5c858dfc9
Zoffix oh god...12% perf loss with `sub foo {my $x}; { for ^14000_000 { foo }; say now - ENTER now }` 06:19
hm, OTOH that's a pretty big number of iterations
man this stuff is really iffy 06:40
m: my @result = gather { for ^2 { my @b = 1 xx 4; take (@b.shift xx 2) xx 2 } }; @result.map(*.eager).eager 06:41
camelia ( no output )
Zoffix One of the tests uses that and with my patch crashes, but....
m: my @result = gather { for ^2 { my @b = 1 xx 4; ((@b.shift xx 2) xx 2).take } }; @result.map(*.eager).eager
camelia The iterator of this Seq is already in use/consumed by another Seq
(you might solve this by adding .cache on usages of the Seq, or
by assigning the Seq into an array)
in block <unit> at <tmp> line 1
Zoffix It crashes the same if the method form of .take is used
the patch being the fix for R#1531 06:45
synopsebot R#1531 [open]: github.com/rakudo/rakudo/issues/1531 Failure to sink `for` when `Z+=` used as last statement
Zoffix m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo }; foo for ^1 # no sinkage 06:46
camelia ( no output )
Zoffix m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo }; Foo.new for ^1 # sinkage
camelia sunk
Zoffix m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo }; Foo for ^1 # wanting about useless value 06:47
camelia WARNINGS for <tmp>:
Useless use of constant value Foo in sink context (use Nil instead to suppress this warning) (line 1)
Zoffix Kinda all over the place
m: for ^1 { ^2 .map: *.say } 06:51
camelia 0
1
Zoffix m: for ^1 { map *.say, ^2 }
camelia ( no output ) 06:52
Zoffix Depending on which style you prefer, you get different results.
Geth roast: a8d6091d73 | (Zoffix Znet)++ | S03-operators/repeat.t
Fix supporting test code

  `take` returns the thing it took, which in this case is the Seq
object. Since it's a `for` loop and we do the "sink last statement" thing in them, that Seq ends up being sunk, which causes throwage about already-iterated Seq when we actually try to compare the result.
... (7 more lines)		 07:02
[Tux] Rakudo version 2018.02.1-43-g7c1a6cac7 - MoarVM version 2018.02-6-g1849ae6d6
csv-ip5xs0.821 - 0.824
csv-ip5xs-207.752 - 7.803
csv-parser12.645 - 13.551
csv-test-xs-200.460 - 0.472
test9.387 - 9.911
test-t2.648 - 2.669
test-t --race1.125 - 1.172
test-t-2046.398 - 47.866
test-t-20 --race16.798 - 17.018
 07:36
second double run was even slower:
2.784 - 2.848 07:37
timotimo damn, this "take returns its argument, and that may get sunk" thing doesn't sound like a thing we want 08:52
[Coke] AlexDaniel: when dealing with spam tickets in RT, please hit the "S" button in the upper right hand corner. I am of the impression that this will help track spam so future tickets might not need human intervention (but maybe it just deletes them, I don't know for sure.) 13:00
AlexDaniel [Coke]: I always do
but reportable does not track deletions so I have to delete stuff manually from its memory :(
AlexDaniel also deletes spam on fail.rakudo.party/ 13:01
[Coke] I was looking at rt.perl.org/Ticket/Display.html?id=132911 which still had the S button for me in the original grey state, and shows you as deleting it; I was able to hit the S button and turn it red.
AlexDaniel hmmmmm I did exactly that 13:02
[Coke] refreshing, I see it's still red, but my action isn't in the history. ah well.
AlexDaniel I think it autodeletes the ticket when you press that button
as for why it's not showing red when someone else pressed it – I don't know
[Coke] nevermind me, then. And I'll probably tell you again in 18 months when I've forgotten. :)
AlexDaniel that's ok! Although in 18 months we might need to reassess the status of the RT and how we use it :) 13:04
we have ≈3 new RT tickets every week
(but sometimes none)
and ≈30 new tickets every week on github 13:05
wait what… really?
yes :O 13:06
AlexDaniel looks at github.com/rakudo/rakudo/wiki/Ticket-updates
Zoffix timotimo: it's actually worse 17:04
m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo.new }; say @ = gather { foo.take; foo.take; }
camelia sunk
sunk
[Foo.new Foo.new]
Zoffix The result of the method form of take always gets sunk so my patch to the test suite is rather pointless 17:05
m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo.new }; say @ = gather { take foo; take foo; }
camelia sunk
sunk
[Foo.new Foo.new]
Zoffix e: @ = gather { take run "false"; Nil } 17:06
evalable6 (exit code 1) The spawned command 'false' exited unsuccessfully (exit code: 1)
in block <unit> at /tmp/wZbyqUfDFT line 1
Zoffix I think if we just stick it into my %nosink on Actions:233, it'll do the trick 17:12
This stuff is a house of cards, man. For one, we're just going by routine name, not by whether it's a core routine 17:14
m: sub foo { class { method sink { say "sunk" } }.new }; foo
camelia sunk
Zoffix m: sub foo { class { method sink { say "sunk" } } }; foo
camelia ( no output )
b2gills m: class Foo { method sink { say "sunk" }; method foo { self } }; sub foo { Foo.new }; say @ = gather { my $ = take foo; my $ = take foo; }
camelia [Foo.new Foo.new]
Zoffix m: class Foo { method meow { class { method sink { say "sunk" } } } }; Foo.meow for ^1 17:15
camelia sunk
Zoffix m: class Foo { method push { class { method sink { say "sunk" } } } }; Foo.push for ^1
camelia ( no output )
Zoffix It just assumes that if name is "push", then it's a core .push routine
b2gills That's significantly LTA 17:16
Zoffix [Tux]: looks like your box was just hot. The only commits that went in since your last 2.595 time was a whitespace fix and an addition of a method that's not used in core. 17:22
s/hot/busy/;
|Tux| i'll run with the same build, one^Wa few moments ... 17:23
Zoffix well, if there weren't any real commits, there's probably no reason to 17:27
Geth roast: be73087b9b | (Zoffix Znet)++ | S03-operators/repeat.t
Further fix supporting test code

The problem that original fix[^1] was trying to defensively account for actually already exists in `&take` calls that aren't a last statement of a `for` loop and the Seq gets sunk, exploding the test.
  [1] github.com/perl6/roast/commit/a8d6...3399f79a10		 17:31
Zoffix And if stresstest is clean, I will have a commit that degrades performance.
timotimo ;( 17:32
|Tux| Rakudo version 2018.02.1-43-g7c1a6cac7 - MoarVM version 2018.02-6-g1849ae6d6
csv-ip5xs0.800 - 0.821
csv-ip5xs-207.374 - 7.480
csv-parser11.969 - 12.268
csv-test-xs-200.469 - 0.503
test8.948 - 9.124
test-t2.547 - 2.585
test-t --race1.081 - 1.099
test-t-2046.263 - 46.886
test-t-20 --race16.297 - 16.416
 17:34
Zoffix By about 8%, when measured with `sub foo {my $x}; { for ^14000_000 { foo }; say now - ENTER now }` 17:35
timotimo this is about sinking in for loops? 17:36
Zoffix Yeah
m: sub foo { fail }; for ^1 { foo }
camelia ( no output )
timotimo i have a sinking feeling
Zoffix m: my $a; for ^1 { $a Z+= 1 }; say $a
camelia (Any)
Zoffix my patch fixes both of those.
ZOFVM: Files=1290, Tests=153242, 167 wallclock secs (23.63 usr 3.32 sys + 3600.45 cusr 184.90 csys = 3812.30 CPU) 17:37
man, I don't wanna push it :)
m: say 167/154
camelia 1.084416
Zoffix yeah, that's my 8% sheesh
So we can save 8% of performance by training our users not to have statements that have to be sunk as last statement of `for` loops. 17:39
I mean, that's exactly how you'd expect it to behave if it were the last statement of a .map's block.
I'll PR it instead.
Geth rakudo/fix-for-sink: 4c5b81fedb | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Fix failure to sink last statements of `for` loops

Fixes R#1531 github.com/rakudo/rakudo/issues/1531 Also fixes lack of explosion in `sub foo {fail}; foo for ^1`
In `for` loops, users would tend to expect last statement to get sunk, but because our for loops are basically `.map` calls, they ... (13 more lines)		 17:45
rakudo: zoffixznet++ created pull request #1570:
Fix failure to sink last statements of `for` loops		 17:46
Zoffix ZOFVM: Files=1290, Tests=153251, 157 wallclock secs (22.02 usr 3.30 sys + 3383.51 cusr 167.23 csys = 3576.06 CPU) 17:53
that's second stresstest on the same build
timotimo that's a bunch faster 17:55
Zoffix Yeah, it's not a good performance measurer because I think it's the time is of just one long test file 17:57
and it's taking random amounts of time too
m: sub wone { fail }; sub two { my $x = wone; return $x }(); say "all good"
camelia all good
Zoffix Looks like ^ there's more similar failure-to-sink issues 17:58
159 on master. 18:02
well, bug fix > perf
Zoffix merges
Geth rakudo: 4c5b81fedb | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Fix failure to sink last statements of `for` loops

Fixes R#1531 github.com/rakudo/rakudo/issues/1531 Also fixes lack of explosion in `sub foo {fail}; foo for ^1`
In `for` loops, users would tend to expect last statement to get sunk, but because our for loops are basically `.map` calls, they ... (13 more lines)		 18:04
synopsebot R#1531 [open]: github.com/rakudo/rakudo/issues/1531 Failure to sink `for` when `Z+=` used as last statement
rakudo: 8a10fc17a3 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp
Merge pull request #1570 from rakudo/fix-for-sink

Fix failure to sink last statements of `for` loops
Zoffix ZofBot: YOLO
ZofBot Zoffix, ) · · · · &
Zoffix might have some ecosystem fallout, with the previously-unsank stuff now sinking 18:05
156s run :) 18:17
Geth roast: 01b59fba66 | (Zoffix Znet)++ | S04-statements/sink.t
Test sunk for sinks last statement sub calls

Closes github.com/rakudo/rakudo/issues/1531 R#1531 Rakudo fix: github.com/rakudo/rakudo/commit/4c...db7434b235		 18:21
synopsebot R#1531 [open]: github.com/rakudo/rakudo/issues/1531 Failure to sink `for` when `Z+=` used as last statement
Zoffix Damn, it's still broken 18:27
m: say sub { sub foo {fail}; foo for ^1 }()
camelia Nil
Zoffix the `for` isn't marked as unwanted so the sink never gets put into place
Does QAST::Want as last statement of a QAST::Block ever use more than one alternative? Like, is it able to choose which alternative to use depending on where that block is called? 18:35
dogbert17 m: sub mv { for 1 { +"x" }; 42 }() 18:59
camelia WARNINGS for <tmp>:
Useless use of "+" in expression "+\"x\"" in sink context (line 1)
Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3⏏5x' (indicated by ⏏)
in sub mv at <tmp> line 1
in block…
dogbert17 Zoffix: did your latest changes manage to fix RT #131622 ? 19:00
synopsebot RT#131622 [new]: rt.perl.org/Ticket/Display.html?id=131622 [BUG] Failures don't get sunk when last in for loop
Zoffix yeah 19:01
dogbert17 cool 19:03
what about RT #132511 ? 19:04
synopsebot RT#132511 [open]: rt.perl.org/Ticket/Display.html?id=132511 Binary assignment Z+= fails if it's the last thing in for loop
Zoffix That references the same SO question my fix was for 19:05
dogbert17 Zoffix++ bug squashing 19:06
Zoffix Filed R#1571 ... I think it'd be good to take a harder stare at our wanted/unwanted system. 19:12
synopsebot R#1571 [open]: github.com/rakudo/rakudo/issues/1571 Flaws in implied sinkage / `&unwanted` helper
dogbert17 m: sub postfix:<F> (Rat $r --> FatRat) is tighter(&infix:<==>) { FatRat.new: .numerator, .denominator }; say <0/0>F == <1/0>F 19:21
camelia ===SORRY!===
Unknown QAST node type NQPMu
Zoffix dogbert17: is there a ticket for that last one? 19:26
dogbert17 yes 19:27
sec 19:28
RT #130462
synopsebot RT#130462 [new]: rt.perl.org/Ticket/Display.html?id=130462 [BUG] Unknown QAST node type NQPMu error when using `is tighter`
Zoffix Ohhhh. It's the same EXPR can of worms as the other `is ...` bugs that mod ops. :( 19:29
Zoffix was hoping for a fun QAST bug
dogbert17 I have alternatives
RT #130389
synopsebot RT#130389 [new]: rt.perl.org/Ticket/Display.html?id=130389 [BUG] constant with BEGIN block triggers QAST::Block with cuid 4 has not appeared
dogbert17 m: my @foo; say "abcxyd" ~~ m/@foo=(.)/; say @foo 19:30
camelia ===SORRY!===
QAST::Block with cuid 1 has not appeared
Zoffix ZOFFLOP: t/spec/S11-modules/require.t 19:35
Geth rakudo: eb06492213 | (Zoffix Znet)++ | src/core/IO/CatHandle.pm
Reword IO::CatHandles.handles to workaround JVM bug

  github.com/rakudo/rakudo/commit/d5...t-27783688
Zoffix On second though... I rather take a nap 19:37
:)
dogbert17 powernaps are underrated 19:39
Geth rakudo: 838782b7d7 | (Elizabeth Mattijsen)++ | src/core/List.pm
Make sub list/cache a multi
 20:13
lizmat notable6: weekly 20:37
notable6 lizmat, 2 notes: gist.github.com/dcce2ea14513078732...298c31955e
lizmat notable6: weekly clear 20:44
notable6 lizmat, Noted!
lizmat notable6: weekly 20:45
notable6 lizmat, 3 notes: gist.github.com/ab46ac27d2bc9e4649...30594403b0
lizmat notable6: help
notable6 lizmat, Like this: notable6: weekly rakudo is now 10x faster # See wiki for more examples: github.com/perl6/whateverable/wiki/Notable
lizmat notable6: clear weekly
notable6 lizmat, Moved existing notes to “weekly_2018-02-26T20:45:39Z”
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/02/26/...-cheese-d/ 21:50
jnthn lizmat++ 21:54
jnthn has, for once, prepared his talks multiple days before he gives them 21:55
lizmat :-) 21:56
[Coke] O_o . o O (NO WAY!) 22:10
Zoffix lizmat++ # good weekly 22:19
timotimo: RE www.nntp.perl.org/group/perl.perl6...g4677.html a few days ago I mentioned that it's a bug (and wanted to fix it, but was sidetracked). `say` is meant to call .gist and Junction.gist does return the `all(...)` string. Also `say` is often used to dump iffy stuff (like type objects) that don't quite stringify and having `say all()` produce absolutely no output kinda 22:22
violates its behaviour of producing a "gist" of a thing. So the change to `say` should be reverted and only .put/.print/.printf should thread them
And there are proptests that need to be changed too 22:23
c: HEAD~1000 print 1|2 22:25
committable6 Zoffix, ¦HEAD~1000: «This type cannot unbox to a native string: P6opaque, Junction␤ in block <unit> at /tmp/ud6AM6FR2y line 1␤␤ «exit code = 1»»
Zoffix 'cause this is what we were actually trying to fix at the time
lizmat well, but will that fix something like: 22:32
m: say "a" ~ "b"|"c"
camelia ab
c
lizmat m: say "a" ~ ("b"|"c")
camelia ab
ac
lizmat m: say ("a" ~ ("b"|"c")).perl
camelia any("ab", "ac")
lizmat perhaps Junction.gist should just be the same as Junction.perl ? 22:33
Zoffix m: say ("a" ~ ("b"|"c")).gist
camelia any(ab, ac)
Zoffix Right now say(Junction) doesn't use Junction.gist
m: dd "a" ~ ("b"|"c") 22:34
camelia any("ab", "ac")
lizmat aah
ok
still I think this is a bad idea 22:35
Zoffix lizmat: why?
lizmat m: my $j = any(<a b c>); say "foo$j" # you want this to thread 22:36
camelia fooa
foob
fooc
lizmat with your proposal, it would say "any("fooa", "foob", "fooc")"
Zoffix lizmat: why do I want that to thread? I want the .gist of an object, which in this case is a Junction. If I want to thread and print three strings, I'll use `put` 22:37
lizmat it feels to me that it is magic that saying a Junction won't thread 22:38
a bit of a WAT
and not a DWIM
it makes the use of Junctions inconsistent, is my feeling 22:39
(gut feeling)
if you *know* it's going to be a Junction and you're using "say" for debugging, use dd
Zoffix The DWIM here is to print the .gist. In fact, the magic here is that Junction threads, since it shouldn't as there is a Mu candidate for say. 22:40
lizmat m: my $j = any(<a b c>); dd "foo$j"
camelia any("fooa", "foob", "fooc")
Zoffix lizmat: but say "prints the gist". In this case it doesn't
lizmat is there a Mu candidate for say ? 22:41
Zoffix It only benefits the people who abuse `say` and use it instead of using `put`.
m: say Mu
camelia (Mu)
Zoffix m: [any(),any(),any(),any(),].say
camelia [any() any() any() any()]
Zoffix ^ those are actual .gist's of Junction.
m: [any(),any(),any(),any(),]».say
camelia ( no output )
Zoffix But ^ if you try to say them individually, you get no output at all, not even newlines. That's a deviation for .say's behaviour. 22:42
And I can counter-argue the "you're using "say" for debugging, use dd" with: if you want to thread and print strings, use the string-printing routines, not the .gist printing routine 22:43
lizmat well, let me put it this way: what's the difference between say / put / note ?
say / note output .gist, on stdout / stderr respectivly
put outputs .Str on stdout 22:44
Zoffix right
lizmat that's easy to explain
Zoffix Indeed. But that's not the current behaviour.
lizmat now, we're only going to special case 'say' wrt to threading, and not "note" and "put" ?
Zoffix No, we're only going to special-case `put` wrt to threading and make it thread, despite having Mu candidate. For `say` and `note` we'll remove the Junction special-case and let them output .gist of Junctions. Exactly how you described the behaviour above 22:45
and print 22:46
lizmat is that @Larry's opinion ? 22:47
Zoffix "<lizmat> say / note output .gist" <-- they don't right now. If I do $junction-object := 1|2; say $junction-object. I'm NOT going to get `put $junction-object.gist`
No one replied when I mentioned this a few days ago. So far the only opinions I heard are mine and yours
lizmat Zoffix: well, my coverage of the channel is sketchy at best at the moment 22:51
Zoffix m: dd any(42e0).Str; dd any(42e0).gist 22:52
camelia any("42")
"any(42)"
lizmat m: dd any(42e0).Str.^name 22:53
Zoffix And it makes sense if thought this ^ way. Junction.Str (used by `put`) returns a Junction of strings, so if you print them they thread, but Junction.gist (supposed to be used by `say`) returns a single string, so there's no threading in output
camelia "Junction"
lizmat ok, let me sleep on that a bit
:-) 22:54
we have some days for the next release, right ?
Zoffix Plenty
releasable6: next
releasable6 Zoffix, Next release in 18 days and ≈20 hours. Blockers: github.com/rakudo/rakudo/issues?q=...%9A%A0%22. Changelog for this release was not started yet
lizmat ok, then I'm calling it a day now
Zoffix \o
lizmat good night, #perl6-dev!
timotimo Zoffix: OK, should i point that out on that thread? 23:04
Zoffix timotimo: yeah, maybe a good idea to say that this is something that ain't part of 6.c spec and we're still trying to figure out what the actual behaviour should be. Using `put $junction.perl` should give the result they want before and after the changes (put $junction.gist would work right now too; dunno what are the chances of that changing) 23:12
AlexDaniel heh, re twitter.com/andrewshitov/status/96...8049416192 – there was an idea of making a compiler that does nothing useful except passing roast 23:16
Zoffix Would be nice to have one to see how well roast defines a useful compiler :) 23:26
timotimo agreed 23:30
Zoffix OTOH you can just make a compiler that ignores files and prints "1..1\n1 ok" :)
timotimo implement it in asm and it'll be blazing fast 23:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!