travis-ci Rakudo build passed. Elizabeth Mattijsen 'Merge pull request #1715 from ronaldxs/test-RT-122980-wrong-msg-semi 00:32
travis-ci.org/rakudo/rakudo/builds/363886562 github.com/rakudo/rakudo/compare/b...481e26bd1e
Rakudo build passed. Zoffix Znet '[NQP Bump] 463e569 [MoarVM Bump] Brings 2 commits 01:03
travis-ci.org/rakudo/rakudo/builds/363892403 github.com/rakudo/rakudo/compare/6...08f1d0aab1
Geth rakudo: f0c85125f8 | (Zoffix Znet)++ | src/core/Str.pm6
Consistify interface of substr

Fixes R#1717 github.com/rakudo/rakudo/issues/1717
  - When Range is given, coerce the endpoints to Int
  - When Callable is given, coerce its return value to Int
  - When (Non-Int, Callable) are used, fix crash due to attempt to
   numerically compare Callable with Inf		 02:52
synopsebot R#1717 [open]: github.com/rakudo/rakudo/issues/1717 Calling .substr with a Callable for $from that creates a Rat dies
roast: 399ca73435 | (Zoffix Znet)++ | S32-str/substr.t
Test substr coerces from/to/from-to endpoitns to Ints

Closes github.com/rakudo/rakudo/issues/1717 R#1717 Rakudo fix: github.com/rakudo/rakudo/commit/f0c85125f8		 02:53
roast: d43bbdfad2 | usev6++ | S32-io/io-handle.t
Add semicolon to last test

The missing semicolon upset the fudger.		 05:59
[Tux] gist.github.com/Tux/649b0db591bc35...cb815599a9 HELP?! 06:58
geekosaur you need to remove the contents of that directory (the directory itself must exist) 07:02
it was changed to a submodule
(everyone is hitting this; git doesn't handle this well) 07:03
uh, I mean the one on line 30: git error: fatal: destination path '/pro/3gl/CPAN/rakudobrew/moar-blead-master/nqp/MoarVM/3rdparty/libatomic_ops' already exists and is not an empty directory. 07:04
[Tux] 👍 thanks. running again 07:10
Rakudo version 2018.03-208-gf0c85125f - MoarVM version 2018.03-99-g4234ab56b
csv-ip5xs0.909 - 1.034
csv-ip5xs-208.804 - 10.105
csv-parser38.333 - 41.134
csv-test-xs-200.468 - 0.482
test9.260 - 10.064
test-t2.467 - 2.614
test-t --race1.028 - 1.208
test-t-2044.662 - 45.622
test-t-20 --race15.299 - 18.479
 07:20
AlexDaniel releasable6: uptime 07:32
releasable6 AlexDaniel, 2 days, 4 hours, 52 minutes, and 42 seconds, 1560.484375MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
AlexDaniel committable6:
committable6 AlexDaniel, I cannot recognize this command. See wiki for some examples: github.com/perl6/whateverable/wiki/Committable
AlexDaniel committable6: uptime
committable6 AlexDaniel, 4 days, 5 hours, 41 minutes, and 40 seconds, 601.078125MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
AlexDaniel ye that's not right 07:33
releasable6: next
releasable6 AlexDaniel, Next release in ≈12 days and ≈11 hours. 6 blockers. 0 out of 208 commits logged (⚠ 9 warnings)
AlexDaniel, Details: gist.github.com/5fa246be1686c57377...60ee9479cf
Geth rakudo: 28c9ae4faa | (Elizabeth Mattijsen)++ | 2 files
Remove superfluous > 0

Number of elements cannot be negative, so lose the extra check		 08:04
AlexDaniel reportable6: 2018-04-02T00:00:00Z 2018-04-09T00:00:00Z 08:36
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/64312876f462b429be...c550c7053e 08:37
AlexDaniel reportable6: 2018-04-02T00:00:00Z 2018-04-09T00:00:00Z 08:38
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/456d674ba414ad325b...282e36a22d 08:39
AlexDaniel weekly: reportable: gist.github.com/456d674ba414ad325b...282e36a22d
notable6 AlexDaniel, Noted!
AlexDaniel weekly: yet another squashathon happened, some stats: irclog.perlgeek.de/perl6/2018-04-08#i_16020835 + extra stats on github.com/rakudo/rakudo/wiki/Mont...Squash-Day 08:41
notable6 AlexDaniel, Noted!
Geth rakudo: a2d8c96b83 | (Elizabeth Mattijsen)++ | 2 files
Micro-optimize native array iterator

By not using a private method		 08:45
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Remove superfluous > 0 08:48
travis-ci.org/rakudo/rakudo/builds/364002591 github.com/rakudo/rakudo/compare/f...c9ae4faaa0
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Geth rakudo: bd238a7c48 | (Elizabeth Mattijsen)++ | 2 files
Micro-ptimize native array iterator.push-all

About 1% again		 10:15
ilmari why is calling private methods more expensive than public ones? 12:24
timotimo for some reason we go through calling dispatch:<!> for those 12:26
Zoffix timotimo: but even those that get dispatch:<!> unwrapped are 8% slower, because we call them with regular nqp::call that's given the looked up code object, while with public methods we call them with nqp::callstatic and a name 12:28
Can nqp::call of a codeobject be staticalized? Currently the MAST gen stage automatically de-staticalized nameless calls even if you use nqp::callstatic op 12:29
Oh wait, we don't callstatic with a name, we nqp::callmethod with a name.
both the call[static] and callmethod end up with MAST::Call at the end, except in callmethod it also gens findmethod stuff, which makes me think the private one would be faster since it's already found, no? 12:33
Zoffix adds a few debug dumps and recompiles 12:40
|6d design twitter.com/swissgathu/status/9832...9109767168 12:44
ZofBot Zoffix, Will remind you on 2018-04-15T08:44:36.317601-04:00 about design twitter.com/swissgathu/status/9832...9109767168
timotimo Zoffix: i have to write an article about how the new debugger can alleviate the need for rebuilds so you can get debug output 12:49
i think the cli ought to get something like "commands" from gdb so it can output stuff every time you hit a breakpoint
so it'd be exactly like adding debug prints, but without recompilation and you can at any time you want get more info that you might have forgotten the first time 12:50
Zoffix That'd be handy 12:52
timotimo until then you can manually go through all your objects
Zoffix chuckles at MAST::Op findmeth
timotimo had hayfever season not literally just started i might have done a screencast
dogbert2 m: for ^10000 { 1.match(/1/) }; say now - INIT now 12:54
camelia 0.97164166
dogbert2 m: for ^10000 { "1".match(/1/) }; say now - INIT now
camelia 0.1331271
dogbert2 RT #131805
Zoffix dogbert2: it's the we-don't-cache-slurpy-args Issue
synopsebot RT#131805 [open]: rt.perl.org/Ticket/Display.html?id=131805 [REGRESSION] [PERF] .grep-ing Ints with a code block is now almost twice slower ( .grep({/foo/}) )
dogbert2 lizmat "I have tried a few things, but I’m afraid this is really an issue inside “find_best_dispatchee” in the bootstrap" 12:55
quite large difference though
Zoffix Well, it's the Golden Goose of Rakudo. Whoever implements the caching of slurpies will gets a lot of kudos. 12:56
dogbert2 perhaps zofbot will do it :)
Zoffix That shows up in tons of places as the cause of lower perf. Although, this is just backwards thinking: it's not that the 1.match(/1/) is slower, but that "1".match(/1/) is faster thanks to the work that made it possible to cache dispatch of some candidates 12:57
Same with R#1675 . A particular case was optimized to be fast (Bool.roll) and then the ticket got filed that all the other cases are slow :P 12:58
synopsebot R#1675 [open]: github.com/rakudo/rakudo/issues/1675 Rolling bools is faster than with integers even if you use a small range.
dogbert2 it's never ending :) 13:02
Zoffix Well, I dumped the @ins of callmethod for public meth ( temp.perl6.party/pub.txt ) and call for private meth ( temp.perl6.party/priv.txt ) but it don't tell me nothing about why the private one is slower 13:06
and here's the QAST of the `class Foo { method !ber {}; method bar { self!ber } }; Foo.bar` snippet: temp.perl6.party/priv-qast.html 13:08
pmurias m: my uint8 $foo = 1000000000000000000000000; 13:55
camelia Cannot unbox 80 bit wide bigint into native integer
in block <unit> at <tmp> line 1
pmurias m: my uint8 $foo = 10000;
camelia ( no output )
pmurias ^^ is this behavior a bug?
Zoffix I'd say that's the same situation as with int32: irclog.perlgeek.de/perl6-dev/2018-...i_15967217 13:57
dogbert2 m: sub foo { my &curry = &foo.assuming(); }; for 1..100 -> $x { foo() }; say now - INIT now # is this used often?
camelia 3.7663430
Zoffix assuming is also thread-unsafe because it uses EVAL under the hood 13:58
s: &say, 'assuming', \()
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/bd23...ck.pm6#L62
pmurias are 32bit backends expected to support int64? 14:00
Zoffix It probably can be made a bunch faster by getting rid of that sprinf at the end (and `/^^ Callable >> /` regex can just be made into starts-with and C_CLASS check) 14:01
lizmat pmurias
pmurias: I don't think so
Zoffix m: sub foo { sprintf "%s %s %s", INIT |("a" xx 6); }; for 1..100 -> $x { foo() }; say now - INIT now 14:02
camelia Your printf-style directives specify 3 arguments, but 6 arguments were supplied
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
Zoffix m: sub foo { sprintf "%s %s %s %s %s %s", INIT |("a" xx 6); }; for 1..100 -> $x { foo() }; say now - INIT now
camelia 0.0701141
Zoffix m: sub foo { EVAL sprintf "%s+%s+%s+%s+%s+%s", INIT |("1" xx 6); }; for 1..100 -> $x { foo() }; say now - INIT now 14:03
camelia 5===SORRY!5=== Error while compiling <tmp>
EVAL is a very dangerous function!!! (use the MONKEY-SEE-NO-EVAL pragma to override this error,
but only if you're VERY sure your data contains no injection attacks)
at <tmp>:1
------> 3tf "%s+%s…
Zoffix m: use MONKEY; sub foo { EVAL sprintf "%s+%s+%s+%s+%s+%s", INIT |("1" xx 6); }; for 1..100 -> $x { foo() }; say now - INIT now
camelia 0.8146341
Zoffix m: use MONKEY; sub foo { (INIT "Callafoo") ~~ /^^ Callable >> /; EVAL sprintf "%s+%s+%s+%s+%s+%s", INIT |("1" xx 6); }; for 1..100 -> $x { foo() }; say now - INIT now
camelia 0.82742685
Zoffix m: say 3.7/(3.7-.8) 14:04
camelia 1.275862
Zoffix m: say 3.7/(3.7-.08)
camelia 1.022099
Zoffix Ok, just 2% faster I guess :) not loads
m: sub massuming (&ca, |args) { sub (|c) { ca |args, |c } }; my &d-say := &say.&massuming: "DEBUG: "; d-say "meows" 14:08
camelia DEBUG: meows
dogbert2 sprintf is slow as molasses 14:09
Zoffix m: sub massuming (&ca, |args) { sub (|c) { ca |args, |c } }; sub foo { my &curry = &foo.&massuming(); }; for 1..100 -> $x { foo() }; say now - INIT now
camelia 0.0015933
dogbert2 Zoffix: I stole the assuming example from RT #128388 14:10
synopsebot RT#128388 [open]: rt.perl.org/Ticket/Display.html?id=128388 [PERF] Callable.assuming() is slow
Geth rakudo: d1b3809abb | (Elizabeth Mattijsen)++ | 2 files
Streamline native array.splice quite a bit

  - @a.splice() 19x
  - @a.splice(Int offset) 3x
  - @a.splice(Int offset,Int size) 4x
  - @a.splice(Int offset,Int size,native @) 47x
Also create a CLONE_SLICE helper sub		 14:12
Zoffix :o
lizmat in cases like this, I really miss being able to check for void context 14:14
most of the work is needed to create the return value
which is a shame when it is being sunk
pmurias it seems like 64bit ints (and bignum in general) are currently being worked on by the js implementations, so it seems that it makes more sense to add them once they are natively supported rather than spend time on some workaround
lizmat pmurias: I would concur with that assessment
nine lizmat: for call context the plan was to return smart objects that could e.g. have a method sink() {}, wasn't it? 14:24
Zoffix dogbert2: as was expected, the `massuming` fails a bunch of tests :)
lizmat yeah, but if you're returning a native array, hmweh
and once splice has returned, there's a good chance you cannot actually create what you wanted 14:25
this is made worse by the fact we can't actually slice something out of a native array
so we need to copy element by element :-(
dogbert2 Zoffix: this comment in the RT is revealing :) "It's also not thread-safe (see ticket #127987), and its implementation is a real mess of spaghetti code." 14:26
lizmat that comment is correct :-) 14:27
dogbert2 I seem to remember that we have separate cases for the EVAL not being thread-safe part 14:28
Zoffix Yeah R#1391
synopsebot R#1391 [open]: github.com/rakudo/rakudo/issues/1391 EVAL is not thread safe
Zoffix lizmat: I got a bunch of failures in t/spec/S32-array/splice.t Failed tests: 78, 82, 130, 134, 182, 186, 234, 238, 286, 290 14:30
Zoffix & 14:31
lizmat hmmm....
lizmat checks
confirmed, investigating
hmmm... and now I can't repro :- 14:36
( so I'll be running a whole spectest again to make sure
dogbert2 did lizmat disappear? 14:47
lizmat no, I'm back
dogbert2 lizmat: this might be of interest (perhaps): gist.github.com/dogbert17/c4ca411e...dd04b16270 14:48
lizmat flaky wifi has been bothering me all day, so I decided to take the Windows approach
dogbert2: intelesting
dogbert2 valgrind also get angry 14:49
same test
lizmat S32-array/splice.t I presume ?
dogbert2 correct :) 14:50
lizmat m: my int @a = ^10; dd @a.splice(5,1,@a); dd @a 14:52
camelia array[int].new(5)
array[int].new(0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 8, 9, 6, 7, 8, 9)
lizmat m: use nqp; my int @a = ^10; nqp::splice(@a,@a,5,1); dd @a # dogbert2: does that make asan complain ? 14:55
camelia array[int].new(0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 8, 9, 6, 7, 8, 9)
dogbert2 the non nqp one causes a complaint
the nqp version also makes valgrind/asan upset 14:56
lizmat ah, ok
dogbert2 at least on my $work system (32 bit Linux) 14:57
lizmat well I guess the question is whether nqp::splice is supposed to handle the first 2 params referring to the same array
I guess we'll have to assume that's not going to be the case on some compilers / hardware
dogbert2 overlaps can be handled, but not by memcpy 15:00
man memcpy says: The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas must not overlap. Use memmove(3) if the memory areas do overlap. 15:01
Geth rakudo: 28629905e9 | (Elizabeth Mattijsen)++ | 2 files
Make sure we won't splice from ourselves
 15:02
lizmat dogbert2: could you check with this commit ?
dogbert2 sure, give me a minute or two :) 15:04
valgrind seems happy with t/spec/S32-array/splice.t 15:10
this snippet, 'my int @a = ^10; dd @a.splice(5,1,@a); dd @a', also works without complaints 15:11
the nqp snippet still fails though 15:12
lizmat yeah, that's to be expected, as that would requite MoarVM to be changed 15:13
dogbert2 does your change impact performance? 15:14
lizmat only if you @a.splice(5,1,@a)
afk for a bit&
dogbert2 cool
mr_ron lizmat: yesterday you merged my PR #1715 to test RT #122980 but RT was left open. Any reason for leaving open? 15:27
synopsebot RT#122980 [open]: rt.perl.org/Ticket/Display.html?id=122980 [BUG] LTA error message on fairly strange input, complaining about the lack of a semicolon when the semicolon's right there in Rakudo
AlexDaniel no 15:29
R#1715 15:30
synopsebot R#1715 [closed]: github.com/rakudo/rakudo/pull/1715 Update 05-messages/03-errors.t to add test for RT #122980.
AlexDaniel closed 15:31
mr_ron: thank you!
timotimo making splice on native arrays faster will drastically impact the heap snapshot analyzer, i bet
OK, on this random test load it didn't impact it that strongly 15:36
it's still very welcome, though
> 92.59user 1.93system 0:30.28elapsed 312%CPU (0avgtext+0avgdata 1328976maxresident)k 15:37
> 84.64user 1.72system 0:25.73elapsed 335%CPU (0avgtext+0avgdata 1320592maxresident)k
not sure how noisy it is, i only ran it once 15:38
Geth rakudo/inlined-shaped-carray: ae18b7a08c | (Tobias Leich)++ | src/Perl6/Actions.nqp
Mark the CArray dimension as nut sunk
 15:42
lizmat timotimo: that's 9% faster ? 16:09
not too shabby, I would say ?
timotimo it seems to be very noisy, actually
lizmat well, does it have many splices in the form of @a.splice(5,1,@a) ?
also. I wonder if we shouldn't have something like [email@hidden.address] 16:10
that would just inject and return Nil
timotimo github.com/jnthn/p6-app-moarvm-hea...l.pm6#L792 16:12
not many splices
but these are huge
lizmat hmm.... those look more like .appends to me ? 16:14
timotimo hm, kind of 16:15
lizmat it won't make much of a difference
timotimo h, locally it does use append
lizmat depending on how often you do this
timotimo: before my work, .append would have been much faster for you 16:18
now, it doesn't make much difference :-(
timotimo fair enough :) 16:19
i'm trying to get this piece of code to not allocate gigantic amounts of Int objects ...
it used to be for ^$n, now it's loop ($idx = 0; $idx < $n; $idx = $idx + 1)
not sure if that's actually what's creating the objects
33702392 calls, 33701733 allocations 16:20
so just one int per call, it looks like
ah, maybe it's the way it accesses $n; that's a parameter that's not set to be a native int 16:24
lizmat yeah, that will allocate an Int for each call 16:27
afaik
Geth rakudo: 72473bd0ad | (Elizabeth Mattijsen)++ | 2 files
Make native array.STORE(Seq) about 2x as fast

Because it will now no longer make a copy to AT-POS from.		 16:28
timotimo could it stop allocating lexref to compare $idx and $n? :(
lizmat eh no, that allocating is not removed yet 16:29
discussed that with jnthn last weekend
at basic block level, it should eventually see it can lose the box/unbox and lexreffing 16:30
but we're not there yet
(is how I interpreted it)
timotimo right 16:32
i've been hoping to get this opt in
there's no way to get a loop over a certain number without allocating stuff? 16:36
maybe nqp::while helps?
lizmat I usually do nqp::while 16:37
but apparently a C-style loop with natives should do that as well
timotimo whoop there it is 16:49
> 31.86user 0.84system 0:12.06elapsed 271%CPU (0avgtext+0avgdata 817952maxresident)k
lizmat that's down from the original 90+ secs ? 16:53
timotimo yup 16:56
lizmat pretty good :-)
Geth rakudo: a39d382e19 | (Elizabeth Mattijsen)++ | 2 files
Streamline native array.splice(offset,size,Seq)

Create seperate candidate for it, using the new .STORE(Seq) functionality. Makes it about 13x faster with *way* fewer allocations, as we don't need to keep a list around to AT-POS on.		 17:01
timotimo wow 17:07
> 29.92user 0.96system 0:10.03elapsed 307%CPU (0avgtext+0avgdata 971496maxresident)k 17:39
pay ~150 megs of ram usage, get 35% cpu usage increase
uh oh, i didn't pay enough attention to see that the data wasn't correct any more 17:40
Geth rakudo: 7b5ccaa6f9 | (Elizabeth Mattijsen)++ | 2 files
Give native array.iterator its own skip-one/skip-at-least

Because we can skip on native arrays very quickly by just moving the index, so independent of the number of elements to skip.
lizmat .tell jmerelo have been playing with your algorithm: gist.github.com/lizmat/b33a04cf7f1...e4660985f2 17:48
yoleaux lizmat: I'll pass your message to jmerelo.
timotimo what's nomming my lists ... 17:52
i'm apparently doing nqp::if wrong? 17:57
lizmat nqp::if( condition, true statement, false statement) " 18:00
skids regarding the .assuming implementation... what's holding that back from a better re-implementation is lack of metaprogramming API for callsites. I did what I could with the tools available at the time :-) Also it'll always be a bit spaghetti just due to the complexity of what is expected. 18:03
lizmat skids: I feel your pain :-( 18:04
timotimo looks like a := i did caused the target to become Any ?!? 18:11
lizmat que?
timotimo things be weird. 18:21
i know what i did wrong. wow. 18:28
i had code with nqp::stmts and in the middle was "$buf = $fh.gimme(10)," 18:29
it was parsing the entire rest of the stmts as "assign all those into $buf please"
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Give native array.iterator its own skip-one/skip-at-least 18:30
travis-ci.org/rakudo/rakudo/builds/364230676 github.com/rakudo/rakudo/compare/a...5ccaa6f9d3
buggable [travis build above] ☠ All failures are due to: failed make test (1 failure). Across all jobs, only t/04-nativecall/05-arrays.t test file failed.
lizmat timotimo: yeah, you learn to put parens around all asignments that way 18:32
timotimo f course it's much slower now ;)
lizmat but more correct, I hope ?
timotimo memory usage is also up 18:33
looks a lot better, yes
> 82.23user 1.57system 0:26.01elapsed 322%CPU (0avgtext+0avgdata 1362544maxresident)k
Geth rakudo: 518f2c319d | (Elizabeth Mattijsen)++ | 2 files
Simplify native array.STORE(seq)

Let the iterator decide how best to optimize		 19:20
lizmat notable6: weekly 19:21
notable6 lizmat, 4 notes: gist.github.com/6739c99eb9b54cd9b8...8d21f87e89
timotimo MFW the #1 allocator of Int is infix:«<» 19:31
lizmat and it's only native ints involved ?? 19:36
perhaps we forgot a candidate ?
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Simplify native array.STORE(seq) 20:03
travis-ci.org/rakudo/rakudo/builds/364272639 github.com/rakudo/rakudo/compare/7...8f2c319dfc
lizmat samcv: could you give a one/two line description of the strand work you've done ? (for the P6W) 20:05
samcv Collapsing strands, which happens in Perl 6 during regex, has been made 4x faster by taking advantage of SIMD instructions. Also indexing has been made 50% faster when the needle is internally with a different number of bits than the haystack. 20:09
*internally stored
lizmat thanks!
timotimo > 70.51user 1.23system 0:22.34elapsed 321%CPU (0avgtext+0avgdata 1344752maxresident)k 20:50
GC still at about 12%
lizmat notable: weekly reset 20:53
notable6 lizmat, Moved existing notes to “weekly_2018-04-09T20:53:48Z”
timotimo oooh 20:54
lizmat ?? 20:55
timotimo weekly is about to hit? :) 20:56
lizmat eh, yes
got anything I should put in there ?
timotimo nope
timotimo turns more for loops into loop loops 20:57
lizmat
.oO( loop di loop )
timotimo the top allocator is currently IntRange's pull-one 20:59
lizmat that's probably because you can't return a native int without it being HLLized 21:00
or can you ?
timotimo not sure
hum. now the top allocator of Int is infix:<+> 21:04
MasterDuke timotimo: what are you measuring? 21:10
timotimo i'm doing "summary all" on a random heap snapshot i had on my disk
it's a good benchmark for the "load snapshot" code
Geth roast: 0ab8279ee8 | (Zoffix Znet)++ (committed using GitHub Web editor) | S32-io/io-handle.t
Localize class to the test it belongs to

also make description more precise
MasterDuke ah nice 21:11
timotimo sadly, all the changes i'm making are in the program, not in rakudo 21:12
so will only benefit that code
right now, the profiler keeps dieing while trying to write out the profile, though %) 21:15
MasterDuke got a little russian nesting doll situation of profilers and debuggers? 21:24
lizmat and yet another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/04/09/...an-perl-6/ 21:27
timotimo bleh, prefix:<++> is now the top allocator of Int, at the same amount of allocations that infix:<+> used to have %)
lizmat some relaxation& 21:38
Geth geth: 6a110d58ea | (Zoffix Znet)++ | lib/Geth/GitHub/Hooks.pm6
Remove trailing whitespace
 22:47
geth: 906fc4b5fd | (Zoffix Znet)++ | 2 files
Report Issue [un]assignment
 22:48
geth: 4ca98d81d6 | (Zoffix Znet)++ | lib/Geth/GitHub/Hooks.pm6
List `issues` in supported events
 22:49
¦ rakudo: self-assigned Likely issue in block migrator 22:50
¦ rakudo: zoffixznet self-unassigned Likely issue in block migrator
¦ rakudo: zoffixznet unassigned Likely issue in block migrator from AlexDaniel 22:51
¦ rakudo: self-assigned Likely issue in block migrator
geth: 3ce1f5f37c | (Zoffix Znet)++ | lib/Geth/GitHub/Hooks.pm6
Fix misnamed keys
 22:54
¦ rakudo: zoffixznet unassigned Likely issue in block migrator from AlexDaniel
¦ rakudo: zoffixznet self-assigned Likely issue in block migrator
geth: 2342672132 | (Zoffix Znet)++ | lib/Geth/Plugin/GitHub.pm6
Tweak assignment text
 22:56
¦ rakudo: zoffixznet self-unassigned Likely issue in block migrator github.com/rakudo/rakudo/issues/1718 22:57
¦ rakudo: zoffixznet assigned to AlexDaniel Issue Likely issue in block migrator github.com/rakudo/rakudo/issues/1718
¦ rakudo: zoffixznet unassigned from AlexDaniel Issue Likely issue in block migrator github.com/rakudo/rakudo/issues/1718 22:58
¦ rakudo: zoffixznet self-assigned Likely issue in block migrator github.com/rakudo/rakudo/issues/1718
Zoffix (sorry for spam, but didn't want to setup dev server just to dev this small thing :))
Geth ¦ rakudo: zoffixznet self-assigned IO::Socket::INET doesn't set nl-in github.com/rakudo/rakudo/issues/1721 23:07
roast: 51afb21a7f | (Zoffix Znet)++ | S32-io/IO-Socket-INET.t
Remove trailing whitespace
 23:49
rakudo: 6e37c7f048 | (Zoffix Znet)++ | src/core/IO/Socket.pm6
Fix hang in IO::Socket::INET.lines

Fixes R#1721 github.com/rakudo/rakudo/issues/1721
When we read zero bytes we ask the decoder for all it's got, which gives us an empty string and we infiniloop "reading" all the empty strings.
Fix by checking if the decoder is empty before grabbing the last bytes.		 23:56
synopsebot R#1721 [open]: github.com/rakudo/rakudo/issues/1721 [regression][⚠ blocker ⚠] IO::Socket::INET doesn't set nl-in
roast: 216229011f | (Zoffix Znet)++ | S32-io/IO-Socket-INET.t
Test no hang in IO::Socket::INET.lines

Closes github.com/rakudo/rakudo/issues/1721 R#1721 Rakudo fix: github.com/rakudo/rakudo/commit/6e37c7f048		 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!