lizmat Files=1306, Tests=111227, 211 wallclock secs (28.93 usr 8.23 sys + 2973.79 cusr 268.25 csys = 3279.20 CPU) 07:48
SOOP3RN3TZ THIS CHANNEL HAS SMALL DICK ENERGY | ALL CHATTERS MUST QUARANTINE ON ɪʀᴄ.ꜱᴜᴩᴇʀɴᴇᴛꜱ.ᴏʀɢ #ꜱᴜᴩᴇʀʙᴏᴡʟ 07:53
█░█▀█░█▀▀░░░█▀░█░█░█▀█░█▀▀░█▀█░█▄░█░█▀▀░▀█▀░█▀░░░█▀█░█▀█░█▀▀
█░█▀▄░█░░░░░▀█░█░█░█▀▀░█▀▀░█▀▄░█▀▄█░█▀▀░░█░░▀█░░░█░█░█▀▄░█░▄▄
█░█░█░█▄▄░▄░▄█░█▄█░█░░░█▄▄░█░█░█░▀█░█▄▄░░█░░▄█░▄░█▄█░█░█░█▄█
RIDE OUT THIS TARANTINO FILM IN A BIG DICK NETWORK
OOP3RN3TZ [Tux] upupbb-user3 b2gills discord6 Geth_ MasterDuke dogbert17 Kaeipi maggotbrain squashable6 cognominal [TuxCM] unclechu AlexDaniel` quotable6 shareable6 nativecallable6 reportable6 tellable6 releasable6 committable6 notable6 statisfiable6 bloatable6 unicodable6 benchable6 bisectable6 greppable6 sourceable6 rypervenche linkable6 tbrowder Guest54471 literal tobs synthmeat lizmat pochi_
AlexDaniel hmmm 08:00
MasterDuke huh. github.com/MasterDuke17/nqp/commit...08feafef37 cause the nqp build to die with `Bytecode validation error at offset 262, instruction 41:operand type 32 does not match register type 160 for op coerce_iu in frame write_header` 08:01
nine MasterDuke: that's the joy of working on the mbc stage: you get these incredibly useful error messages... 08:02
tellable6 2020-03-31T22:27:21Z #raku-dev <tbrowder> nine when i say remote i mean via a terminal on my ipad accessing my laptop in another room while i'm lying in my easy chair :-/
AlexDaniel if this happens again we'll have to invite Sigyn
MasterDuke nine: i'm just not sure how that happens. i actually tested that on the command line, but maybe it's happening to early in nqp and the conversion isn't happening the same? 08:04
MasterDuke nqp: sub a($b) { nqp::mul_n($b, 1.3) }; say(a(2.3)); sub b($b) { my uint32 $c := nqp::mul_n($b, 1.3); $c }; say(b(2.3)); sub c($b) { my uint32 $c := nqp::mul_n($b, 1.3) }; say(c(2.3)) 08:06
camelia 2.9899999999999998
2
2
Geth rakudo: 6541775c2e | (Elizabeth Mattijsen)++ | src/core.c/array_operators.pm6
Make unshift(@a,foo) about 20x as fast

Part 3 of fixing R#3584
08:28
linkable6 R#3584 [open]: github.com/rakudo/rakudo/issues/3584 sub push much slower than method push
lizmat m: my @a = 1,2,3; use nqp; dd nqp::iscont(@a.shift); dd nqp::iscont(shift @a) # these appear to be inconsistent 08:36
camelia 1
0
lizmat jnthn ^^
m: my @a = 1,2,3; use nqp; dd my $b = @a.shift = 666 # does this even make sense ? 08:37
camelia Int $b = 666
Geth rakudo: 9b735b7699 | (Elizabeth Mattijsen)++ | src/core.c/array_operators.pm6
Make prepend(@a,foo) about 20x as fast

Part 4 of fixing R#3584
08:38
linkable6 R#3584 [open]: github.com/rakudo/rakudo/issues/3584 sub push much slower than method push
tyil . 08:39
tellable6 2020-03-31T22:18:37Z #raku-dev <lizmat> tyil looks like Geth is AWOL again
tyil looks fixed to me 08:40
:>
lizmat tyil++
.ask jnthn is there some performance reason why Array.pop and Array.shift do not de-containerize ? 09:18
tellable6 lizmat, I'll pass your message to jnthn
timotimo perhaps it's for when you've bound a scalar to the array 09:24
so the container you're getting back from pop or shift is the same as whatever else you bound
MasterDuke huh. for some reason heaptrack doesn't work when using the nqp binary 09:25
lizmat timotimo: thing is, if I decont .pop / .shift, I get one TODO passing in roast 09:29
also pop / shift as a sub decont
timotimo ah interesting 09:33
jnthn Interesting. I dunno if that's an accident or not, but I can kinda imagine `@queue-of-things-to-update.shift = 42` actually being written by somebody... :) 09:49
tellable6 2020-04-01T09:18:52Z #raku-dev <lizmat> jnthn is there some performance reason why Array.pop and Array.shift do not de-containerize ?
jnthn Or stack of things with pop
I don't know there's so much a perf reason there, but it's arguably useful.
lizmat jnthn: there is no test in roast for it
jnthn Yes, but if that told us about all the usages then we'd not need blin ;)
lizmat ok, so then the sub form of shift / pop should also not decont I guess 09:50
and the TODO'd test in roast should be removed then, I guess
jnthn I guess it's a bit inconsistent... 09:51
Geth rakudo: 6793713b27 | (Elizabeth Mattijsen)++ | src/core.c/Array.pm6
Failure handling of Array.pop/shift in private method

To reduce the footprint of Array.pop/shift themselves, to make them more likely targets for inlining.
10:01
lizmat jnthn: making sub pop / shift "is raw" breaks spectest: they expect to be deconted 10:11
so in that light, I think it would be best to make them all decont and see what blin thinks about that ?
jnthn Can try, I guess. There's not really much precedent for method/sub forms being distinctive in this way. 10:17
AlexDaniel sourceable6: (1, 2, 3).append(42, 50) 10:18
sourceable6 AlexDaniel, github.com/rakudo/rakudo/blob/6793....pm6#L1504
AlexDaniel sourceable6: [1, 2, 3].append(42, 50) 10:19
sourceable6 AlexDaniel, github.com/rakudo/rakudo/blob/6793...y.pm6#L746
AlexDaniel lizmat: I'm a bit surprised how well that works :D
sourceable6++ # underrated bot
lizmat jnthn: if a routine is "is raw", it basically would not emit a decont() on the return value, right? 10:21
lizmat so if I make the method decont, then the sub could be "is raw" as it would always just obtain a deconted value anyway? 10:21
AlexDaniel tellable6: Xliff 10:26
tellable6 AlexDaniel, I saw Xliff 2020-03-30T08:36:34Z in #raku-dev: <Xliff> [Tux]: How are those results, read? Is this current commit vs last commit?
jnthn lizmat: Yes 10:28
lizmat: raw just passes on what it gets
lizmat ok
Geth rakudo: 2edce41bd2 | (Elizabeth Mattijsen)++ | 2 files
Make pop/shift behaviour re deconting consistent

  - Array.pop/shift now decont
  - sub pop/shift are now raw, as they don't need a decont check
10:41
roast: 66649d3dd6 | (Elizabeth Mattijsen)++ | S32-array/pop.t
unTODO test now that Array.pop deconts
roast: Kaiepi++ created pull request #631:
Update tests WRT IO::Socket::INET bind before connect
10:50
Geth rakudo: 4325972835 | (Elizabeth Mattijsen)++ | src/core.c/native_array.pm6
Revert "Fix performance issue on native shaped arrays"

This reverts commit 80f2aebff482da6e67589d043b6888a8e3eb2128.
It appears that each *each* class of a certain type would get its own type (without caching), which is also a severe memory issue. Fixes R#3586. Re-opened R#3532.
11:10
linkable6 R#3586 [open]: github.com/rakudo/rakudo/issues/3586 Native shaped array performance regression
R#3532 [open]: github.com/rakudo/rakudo/issues/3532 [native types][performance][shaped] Looping sized native typed array is slow
lizmat m: my int32 @a[42]; dd @a.^name 11:24
camelia "array[int32]"
lizmat m: my int32 @a; dd @a.^name 11:25
camelia "array[int32]"
lizmat jnthn: you cannot see the difference between a native shaped array, and a normal native array
jnthn Why'd you expect to? :) 11:26
m: my @a; say @a.^name
camelia Array
jnthn m: my @a[42]; say @a.^name
camelia Array
jnthn Same there too 11:27
lizmat I'd expect the shape to be part of it ?
jnthn No
m: my @a[42]; say @a.shape
camelia (42)
jnthn m: my int @a[42]; say @a.shape
camelia (42)
jnthn You find it like that.
lizmat hmmm.... 11:28
m: my int @a[10]; my int @b[11]; dd @a.WHAT =:= @b.WHAT # somehow I'd expect this to be false
camelia Bool::True
lizmat trying to find ways to fix R#3532 11:29
linkable6 R#3532 [open]: github.com/rakudo/rakudo/issues/3532 [native types][performance][shaped] Looping sized native typed array is slow
lizmat 80f2aebff482da6e67589d turned out to not be the solution, as it apparently created a separate type for each native array instance 11:30
linkable6 (2020-03-20) github.com/rakudo/rakudo/commit/80f2aebff4 Fix performance issue on native shaped arrays
dogbert17 lizmat+++, you made short work of R#3584 13:05
linkable6 R#3584 [closed]: github.com/rakudo/rakudo/issues/3584 sub push much slower than method push
lizmat yeah, since I caused the issue in the first place in July 2019 :-( 13:06
what was I thinking? :-)
dogbert17 we all make the occasional mistake :) 13:07
MasterDuke bisect: good=478239e61 my @b; append @b, [0 xx 3], [1 xx 3]; say @b # lizmat 13:14
bisectable6 MasterDuke, Bisecting by output (old=478239e new=4325972) because on both starting points the exit code is 0
MasterDuke, bisect log: gist.github.com/bd6a48a75b46e1265c...c3b699aef7
MasterDuke, (2020-04-01) github.com/rakudo/rakudo/commit/b9...48c9041141
MasterDuke seen by SqrtNegInf over in #whateverable 13:17
lizmat MasterDuke: I guess we need more spectests :-) 13:18
MasterDuke can't argue with that 13:19
[Coke] wow, quick catch. 13:23
Geth rakudo: 1e4c736143 | (Elizabeth Mattijsen)++ | src/core.c/array_operators.pm6
Fix regression in sub append/prepend

  SqrtNegInf++ for spotting
13:34
AlexDaniel heh, I've been staring at that line thinking it can't be right 13:46
and then I got distracted by something else
Geth rakudo: 2b49d685b3 | (Elizabeth Mattijsen)++ | src/core.c/IterationBuffer.pm6
Give IterationBuffer its own iterator method

Since IterationBuffer is not an Iterable (on purpose), it was using the default iterator, which is basically useless for an IterationBuffer. This iterator will treat the IterationBuffer as a fully reified List. For work that is underway refactoring the ... sequence generator
13:49
lizmat AlexDaniel: no spectest caught it :-(
*hint* :-)
nine is looking forward to a sane sequence generator
AlexDaniel nine: meaning?
lizmat: well, I wrote all this tooling so that even with no spectests we can quickly figure out what's wrong :P :P 13:50
nine During the GLR that was the one thing that I gave up on right from the start because....oh that code!
lizmat yeah... it's pretty ... old
it predated the existence of iterators 13:51
nine So I just patched it up a little but never did what lizmat is now doing - bringing it fully into the iterator world
AlexDaniel ah, I just read the commit message :)
nine so ++lizmat!
lizmat I'll also be implementing ^... and ^...^ 13:55
AlexDaniel lizmat: oh no :) 14:00
jnthn
.oO( 3 eyed cat )
AlexDaniel I mean, as a feature it probably makes sense, but I remember all the bugs in ^.. 14:01
lizmat well, ^... will just call ... but skip the first value produced
and ^...^ will skip the first and last value
AlexDaniel lizmat: any chance of .reverse breaking some sort of hacks? :) 14:02
btw this is funny, I didn't know you can leave whitespace out:
Geth rakudo: 77defa770e | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Add R:It.AllButLast iterator

Produce all values of a given iterator, except the last value. For work that is underway refactoring the ... sequence generator
AlexDaniel m: say 5....1
camelia (5 4 3 2 1)
lizmat m: say 5...^1 14:03
camelia (5 4 3 2)
lizmat m: say 5^...1
camelia 5^..0.1
lizmat m: dd 5^...1
camelia 5^..0.1
lizmat m: dd 5 ^... 1
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of . to concatenate strings; in Raku please use ~
at <tmp>:1
------> 3dd 5 ^...7⏏5 1
AlexDaniel m: dd 5 ^.. .1
camelia 5^..0.1
AlexDaniel ;)
SqrtNegInf Thanks MasterDuke++ for bringing the issue over here, meant to, but got distracted... 14:52
It's all in the automation: 1,111 Rosettacode tasks being smoke-tested daily, and yesterday exactly 1 flagged the issue with 'append'. Cast a wide net, and you catch stuff. 14:53
MasterDuke SqrtNegInf++
AlexDaniel SqrtNegInf: you do that?? 14:54
I remember there was a discussion but I didn't know somebody is actively testing rosettacode solutions
SqrtNegInf++
SqrtNegInf github.com/SqrtNegInf/Rosettacode-Perl6-Smoke
[Coke] If there's a repo for that, can probably remov thec examples from the spectest repo. 14:56
*remove the 2 or 3...
Geth ¦ problem-solving: chloekek assigned to samcv Issue printf padding and wide East Asian characters github.com/Raku/problem-solving/issues/171 16:02
Geth rakudo: bd4e119df1 | (Elizabeth Mattijsen)++ | src/core.c/operators.pm6
Turn infix:<…> / infix:<…^> into aliases

There's no need for them to be full-blown subs that just pass on.
16:27
rakudo: d0e427dcda | (Elizabeth Mattijsen)++ | src/core.c/precedence.pm6
Set precedence of ...^ … …^

These appeared to not have been set before.
Kaiepi i can't push atm because dns is screwed, but you're right lizmat, not boxing the return values of Capture.raku and .Str make them around 10% faster 16:32
tellable6 2020-03-31T20:58:17Z #raku-dev <dogbert17> Kaiepi: thx, didn't know that
Kaiepi oh there we go 16:33
Geth nqp: 57a4d5eacb | (Jonathan Worthington)++ | tools/templates/MOAR_REVISION
Bump to a MoarVM with new container spec type

It now offers a built-in alternative to the Rakudo Scalar one that Rakudo currently uses.
rakudo: d6298edc59 | (Ben Davies)++ | src/core.c/Capture.pm6
Don't box strings returned by Capture.Str and .raku

This makes these methods around 10% faster.
16:34
rakudo: 4221f8225f | (Jonathan Worthington)++ | 9 files
Adopt MoarVM-provided value_desc_cont

This gets rid of the Rakudo Scalar container descriptor, which was a big chunk of the extops library (which we're gradually aiming to get rid of). It also removes an assumption on P6opaque and Scalar layout, which makes things a bit more robust. Curiously, on a benchmark I did to check the consequence of this, it seems that we may also gain a little speed ... (9 more lines)
16:41
jnthn 11 insertions(+), 238 deletions(-)
Most of which was C code in the extops lib. Now we've only 420 lines left of it. 16:42
MasterDuke heh, and looks like maybe that'll get rid of that last leak with --full-cleanup 16:43
jnthn Oh, bonus :) 16:44
MasterDuke jnthn: speaking of, have you seen github.com/MoarVM/MoarVM/pull/1263 ?
actually, that's required to get rid of them all
jnthn Ah, forgot to review that
Let me check something...
Yeah, it all fits. Merged. 16:46
nine \o/ 16:50
jnthn Getting rid of the dispatcher stuff in the extops will get rid of a good chunk more
(of the extops code, not of the leaks...) 16:51
[Coke] jnthn++ 16:52
jnthn Unifying the various dispatchy trees will be...interesting. 16:55
(This was a yak shave when to doing that...) 16:56
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Give IterationBuffer its own iterator method 17:10
travis-ci.org/rakudo/rakudo/builds/669711890 github.com/rakudo/rakudo/compare/1...49d685b337
MasterDuke oops, the container spec leak wasn't actually touched by that 17:15
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Add R:It.AllButLast iterator 17:54
travis-ci.org/rakudo/rakudo/builds/669716841 github.com/rakudo/rakudo/compare/2...defa770e13
Geth rakudo: 0b414c0a0f | (Elizabeth Mattijsen)++ | src/core.c/precedence.pm6
Remove superfluous precedence settings for aliases

The operators (usually Unicode versions) that are aliases of the real thing, don't need there precedence set (again) as the source of the alias already has them applied.
18:00
Geth rakudo: 88a9a36efa | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Make R:It.AllButLast actually work correctly
19:11
dogbert17 m: 1, 11 Z... 4, 14 19:17
camelia ( no output )
dogbert17 m: dd 1, 11 Z... 4, 14
camelia ((1, 4).Seq, (11, 14).Seq).Seq
Geth rakudo: 4fe18a48ea | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Added R:It.AllButFirst

Returns an iterator that produces all but the first value
19:52
rakudo: 371590fa16 | (Elizabeth Mattijsen)++ | 10 files
Introduce ^... and ^...^ sequence generator operators

The ... and ...^ already existed, but ^... and ^...^ were curiously missing. Please note that you can also use these operators with an array on the left hand side:
   my @a = 1,2,4;
... (5 more lines)
MasterDuke huh. just now realized you can't open a file :rw in nqp, only :r or :w 20:08
MasterDuke oh wait, '+' is :rw 20:13
Geth rakudo: aa5154e027 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Make R:It.AllButLast handle PredictiveIterators correctly
20:15
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Set precedence of ...^ … …^ 20:15
travis-ci.org/rakudo/rakudo/builds/669778983 github.com/rakudo/rakudo/compare/7...e427dcda3d
lizmat hmmmm... "Stage optimize : Segmentation fault (core dumped)" 20:16
I'm *not* seeing that locally
also: Variable "$self" will not stay shared at (re_eval 13) line 1.
1094Variable "$last_text" will not stay shared at (re_eval 13) line 1.
that feels like Perl error messages... could it be some recently introduced build issue ? 20:17
Altai-man_ ugh, is it the same segfault or a new one... 20:19
lizmat not sure... 20:20
lizmat is tired and gets an early night&
all in place for writing a lot of tests tomorrow
Altai-man_ lizmat, good night! 20:21
travis-ci Rakudo build failed. Ben Davies 'Don't box strings returned by Capture.Str and .raku 21:03
travis-ci.org/rakudo/rakudo/builds/669782042 github.com/rakudo/rakudo/compare/d...298edc59fd
jjatria tyil: How does this look for an initial stab at a docker building action for rstar? gitlab.com/jjatria/rstar/-/commit/71b80f4e 22:20
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Remove superfluous precedence settings for aliases 22:33
travis-ci.org/rakudo/rakudo/builds/669817539 github.com/rakudo/rakudo/compare/4...414c0a0fd5
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make R:It.AllButLast actually work correctly' 22:54
travis-ci.org/rakudo/rakudo/builds/669845520 github.com/rakudo/rakudo/compare/0...a9a36efa6b
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Introduce ^... and ^...^ sequence generator operators 23:24
travis-ci.org/rakudo/rakudo/builds/669859861 github.com/rakudo/rakudo/compare/8...1590fa1693
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make R:It.AllButLast handle PredictiveIterators correctly' 23:53
travis-ci.org/rakudo/rakudo/builds/669867234 github.com/rakudo/rakudo/compare/3...5154e02783