Geth rakudo: de2d829671 | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Fix LTA error with adverb on Whatever closure with +

Phixes github.com/rakudo/rakudo/issues/1476
Just 'cause we CAN have a name, doesn't mean we got one. Test the name has length before using the path that uses it.		 00:20
roast: 9da3bd0eaa | (Zoffix Znet)++ | S32-exceptions/misc.t
Test whateverclosure adverb says what can't be adverbed

Closes github.com/rakudo/rakudo/issues/1476 Rakudo fix: github.com/rakudo/rakudo/commit/de2d829671		 00:21
travis-ci Rakudo build passed. Zoffix Znet 'Fix fake-infix adverb args with new .= opt 00:39
travis-ci.org/rakudo/rakudo/builds/338769306 github.com/rakudo/rakudo/compare/1...a57657d1ed
Rakudo build passed. Zoffix Znet 'Fix LTA error with adverb on Whatever closure with + 01:19
travis-ci.org/rakudo/rakudo/builds/338776886 github.com/rakudo/rakudo/compare/7...2d829671a4
MasterDuke Zoffix: did you run a spectest after removing Mu.sink? 03:36
Zoffix MasterDuke: no, even `make install` didn't finish. It crashed at some point with "no sink on Bool" 03:43
Didn't bother with spectest
MasterDuke ah 03:44
Geth roast: 50c8b4543d | (Zoffix Znet)++ | S32-exceptions/misc.t
Bump plan

Bump was missed in
  github.com/perl6/roast/commit/9da3...d942e4c59f		 06:14
rakudo: 460606e324 | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Generalize fake infix adverb ann

Instead of making the adverber rake for the target of where to put the named args, have the code that adds the annotation simply shove the target into the annotation.
This will let us use the annotation in other constructs that need fake infix adverbs pushed into them.		 07:16
rakudo: 8ba3c86e7d | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Implement support for .= to init sigilless vars

Phixes github.com/rakudo/rakudo/issues/1461		 07:17
roast: 890a81df7d | (Zoffix Znet)++ | S03-operators/inplace.t
Test .= can be used to init sigilless vars

Closes github.com/rakudo/rakudo/issues/1461 Rakudo impl: github.com/rakudo/rakudo/commit/8ba3c86e7d
perlawhirl bisectable6: say (1, 2, 3).map(* xx 2); 09:36
bisectable6 perlawhirl, Bisecting by output (old=2015.12 new=8ba3c86) because on both starting points the exit code is 1
perlawhirl, bisect log: gist.github.com/779d9f7f5dcd5de49f...974e96e9a9
perlawhirl, (2016-06-09) github.com/rakudo/rakudo/commit/b6...430078bc7d
[Tux] Rakudo version 2018.01-143-g8ba3c86e7 - MoarVM version 2018.01-77-g9a029b408
csv-ip5xs0.817 - 0.837
csv-ip5xs-207.630 - 7.991
csv-parser11.905 - 12.142
csv-test-xs-200.438 - 0.449
test9.394 - 9.729
test-t2.626 - 2.749
test-t --race1.071 - 1.239
test-t-2048.090 - 49.921
test-t-20 --race16.575 - 17.826
 09:58
dogbert2_ ZOFFLOP: t/spec/S07-hyperrace/basics.t, hung on test #33 11:06
AlexDaniel any experts on memory leaks? :) 12:52
timotimo, MasterDuke, dogbert17? :)
(or maybe not exactly memory leaks, but issues with memory usage growing to unreasonable amounts) 12:53
I have this: gist.github.com/AlexDaniel/c866739...cd91a8f335 12:54
hm, maybe that's even more golfable 12:55
actually, not really 13:00
well unless you golf inside HTTP::UserAgent
dogbert2_ AlexDaniel: buy moar memory :-) it's cheap nowadays ... not 13:42
jnthn AlexDaniel: The heap analyzer tool can probably tell you something about what is being leaked 13:43
(--profile=heap and then install the heap analyzer app and moar-ha the-file-that-profile-wrote 13:44
)
dogbert2_ jnthn: busy with $work or do you have time for a memory leak question? 13:49
jnthn Pretty busy, alas
dogbert2_ such is life :-)
mebbe later
AlexDaniel I did play around in the heap analyzer but I'm not sure what I'm looking for, things look more or less normal 14:47
gist.github.com/AlexDaniel/0facc6c...aa9b7f515d 14:48
ok, but what is increasing… 14:51
jnthn AlexDaniel: There should be one snapshot per GC run 14:52
AlexDaniel: So you'd go to a later snapshot and then run those commands again
dogbert2_
.oO(AlexDaniel is in a heap of trouble)
 14:53
AlexDaniel uh it'd also help if it was possible to see something other than maxrss through telemetry… 14:57
maybe
dogbert2_ AlexDaniel: are you using Proc::Async in your leaking code? 14:58
AlexDaniel dogbert2_: I don't think HTTP::UserAgent is using Proc::Async 14:59
dogbert2_ I've been looking at the code example MasterDuke posted in github.com/MoarVM/MoarVM/issues/680 15:00
but it could be that Proc::Async isn't the culprit
AlexDaniel dogbert2_: o, yes, but that's a different issue 15:01
dogbert2_ aha
there's a thing with that code that I would like to ask a memory expert about, i.e. moving the declarations of @tags and @commits to before the loop cuts maxrss in half but I honestly don't understand why that is 15:02
jnthn dogbert2_: Just the declarations, or the assignments too? 15:05
dogbert2_ just the declaration 15:06
#74.19user 13.80system 1:12.52elapsed 121%CPU (0avgtext+0avgdata 543640maxresident)k # original gist 15:07
73.87user 12.80system 1:11.43elapsed 121%CPU (0avgtext+0avgdata 329160maxresident)k # declarations moved
jnthn Interesting
dogbert2_ :-) 15:08
the numbers are from a 32 bit vm 15:09
nebuchadnezzar hello
AlexDaniel hi! 15:10
jnthn: OK, I see Buf objects accumulating slowly, there are just 12 by the end but they take most of the space 15:12
nebuchadnezzar I'm looking at Rakudo source code, thanks to Perl6 InsideOut blog I have I a dump question, is it better for X::Promise::* to inherit directly from Exception rather than having an intermediate X::Promise? I'm thinking at catching all kind of Promise exception in one step (for example)
s/dump/dumb/
jnthn If there was an X::Promise it'd probably be a role like X::Comp 15:14
But it'd be a sensible enough thing to do 15:15
nebuchadnezzar I try to look at the exceptions schema… quite hard to read ;-) 15:19
jnthn: ok, so if I understand correctly the blue arrows are roles (docs.perl6.org/images/type-graph-Exception.svg) 15:46
jnthn omg, that diagram 15:47
But yes :)
dogbert2_ jnthn: I'll add the information wrt to the moved array declarations to the case when I get home from $work 15:50
AlexDaniel equivalent example with Cro::HTTP::Client is leaking approximately the same amount 18:04
without doing immediate 1G jump though 18:06
pft… segfault 18:27
OK, out of frustration I'm submitting this: github.com/rakudo/rakudo/issues/1501 18:31
dogbert17 aha, a SEGV interesting 18:48
japhb jnthn: Yeah, assuming the algorithm used to size the type graphs is the same one I wrote way back when, it completely falls down on Exception and Any because they have extremely high fan-out, and I tuned the algorithm for ... well, pretty much all the other types ... by assuming most types have low to moderate fan-out. 18:49
jnthn AlexDaniel: ooc, does the SEGV go away with MVM_JIT_EXPR_DISABLE=1 ? 18:50
(I've some work code afflicted by a bug there that brrt++ has hunted down and is working on fixing)
japhb I always liked how docs.perl6.org/images/type-graph-Numeric.svg turns out, for example, because the algorithm has smoothly dealt with the changes there over the years while still giving you more of the info you need.
brrt i've only partially hunted it down i'm afraid 18:51
jnthn japhb: Actually I was kinda impressed it did something sensible with it at all :)
brrt one bug was the register allocator bug, but the other is still ... weird
as in, i haven't seen what it is yet 18:52
AlexDaniel jnthn: actually it's a bit hard to reproduce it…
given that I had it on the first or second run, shouldn't be too hard
brrt and what happens if you have it on MVM_SPESH_BLOCKING? 18:53
AlexDaniel but each request is like ≈3 seconds, so hard to stress test it
brrt: nothing wrong, no segfault so far 18:54
fwiw you can run this example yourself very easily, all you need is Cro::HTTP::Client
brrt hmmm
TimToady m: use NativeCall; my $buf = CArray[uint8].new(0 xx 5); $buf[0] = 255; say $buf[0] 19:20
camelia -1
TimToady is this one known?
AlexDaniel use NativeCall; my CArray[uint8] $a .= new(200 xx 16); say $a[0]; 19:23
evalable6 -56
AlexDaniel TimToady: yes: RT#130267 19:24
synopsebot RT#130267 [open]: rt.perl.org/Ticket/Display.html?id=130267 [BUG] NativeCall: CArray[uint8] may contain negative numbers
TimToady k, thx
geekosaur uh, I think that is not what it looks like? I mean, a negative number is just an interpretation of a bit pattern 19:25
that is, this would probably be the thing where nqp/moarvm do not distinguish signed vs. unsigned 19:27
rt.perl.org/Public/Bug/Display.html?id=124294 rt.perl.org/Public/Bug/Display.html?id=131149 probbly others 19:39
but the way rt.perlorg is configured is a pita
dogbert17 AlexDaniel: is your system down, I'm getting 503's from Cro 19:43
AlexDaniel dogbert17: try again 19:53
it died…
squashable6: uptime
squashable6 AlexDaniel, 22 hours, 59 minutes, and 48 seconds, 986.988281MiB maxrss. This is Rakudo version 2018.01-29-ga2499c90f built on MoarVM version 2018.01 implementing Perl 6.c.
dogbert17 perhaps it was my fault, I have run your code a few time but not a SEGV in sight 19:54
*times
lol, and when I tried again it SEGV'd 19:55
AlexDaniel yay!!!
I mean, no… but at least we can reproduce it :)
dogbert17 at least once, the jit was enabled though. Will add the SEGV info to your report, looks GC related to the untrained eye 19:57
added 19:59
nine t/spec/S32-num/complex.t seems to be a flapper: WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was: 20:24
Cannot convert 2+4i to Real: imaginary part not zero
Zoffix nine: so which test failed? What you pasted is just a warning 21:39
e: use Test; for ^1000 { throws-like '(1 + 2i) < (2 + 4i)', Exception; } 21:45
evalable6 (signal SIGHUP) 1..2
ok 1 - '(1 + 2i) < (2 + 4i)' died
ok 2 - right exception …		 21:46
Zoffix, Full output: gist.github.com/fb8fe1b9f34e6bed45...404eacaac7
Zoffix Looks like the optimizer isn't doing a good job of disarming failures when constant folding
Oh 21:54
s: &infix:«<», \((1 + 2i).Real.Real, (2 + 4i).Real.Real)
SourceBaby Zoffix, Something's wrong: ␤ERR: Cannot convert 1+2i to Real: imaginary part not zero␤ in block <unit> at -e line 6␤␤ 21:55
Zoffix The first explosion never gives a chance to the second Failure to explode, so it gets stuck in limob
*limbo
e: use Test; for ^1000 { my $ = Failure.new < Failure.new; CATCH { default {} } } 22:04
evalable6 WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it…
Zoffix, Full output: gist.github.com/06e558ac81c8f261ad...5236b06cfa
Zoffix I guess that would be a point in favour of R#1298 22:05
synopsebot: wake up
something with hack... managed to log in but runing any command just hangs... 22:12
except `ls`
`cd se[TAB]` hung now... and even CTRL+C doesn't abort it.. Seen this on a box at work when trying to cd into a mounted sshfs share but the server for it went offline.... Something's off with hack's hard drives? 22:14
Anyway, opened R#1502 22:20
synopsebot R#1502 [open]: github.com/rakudo/rakudo/issues/1502 Failure.DESTROY warning sometimes warns when Failure was technically handled
gfldex Was the implicit BEGIN phaser for expressions in modules removed on purpose? 23:42
phasers in modules with theads behave really odd now :-/ 23:48
jnthn gfldex: I'm not sure what you mean 23:50
Statements in the mainline of a module are run at that module's INIT time, not BEGIN time 23:51
gfldex not for me (anymore). I have to provide explicit INIT statements to get them do anything. 23:52
I have a module with a `start { some-sub-called-here() }` and the process will just idle at 3% cpu time. Sometimes it actually starts doing something. 23:54
I shall golf after sleep& and $dayjob.
Before I do that I would like to note that we roast a lot of stuff that is never precompiled and that worries me. 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!