01:30 Xliff_ left 02:41 ggoebel_ left 03:48 evalable6 left, linkable6 left, evalable6 joined 03:49 linkable6 joined 04:05 melezhik joined 04:19 melezhik left 05:55 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Remove postcircumfix[int] candidates 05:55
travis-ci.org/rakudo/rakudo/builds/747458945 github.com/rakudo/rakudo/compare/0...0956b81b4b
05:55 travis-ci left 06:18 domidumont joined 06:31 frost-lab joined
[Tux] timotimo, which one is twice as fast? 07:50
07:58 sena_kun joined 09:06 Altai-man joined 09:09 sena_kun left 09:53 patrickb joined 10:39 Xliff joined
tyil lizmat: I think I got packages in Gentoo working 10:40
10:41 ggoebel_ joined 10:42 moray joined, moray is now known as morayj
timotimo as i understand it, if you've got a shaped native 1dimensional array like my int @blerp[99] then "most accesses" will be 2x as fast as when you leave out the [99] part; i imagine 2x as fast means instead of 10000 accesses per second you get 20000 (completely fictitious numbers) 10:47
Xliff m: my @a = gather for ^3 { take (0, 1, 2) }; @a.gist.say 10:49
camelia [(0 1 2) (0 1 2) (0 1 2)]
Xliff m: my @a = gather for ^3 { take |(0, 1, 2) }; @a.gist.say
camelia [(0 1 2) (0 1 2) (0 1 2)]
Xliff m: my @a = gather for ^3 { my @a = (0, 1, 2); take |@a }; @a.gist.say
camelia [(0 1 2) (0 1 2) (0 1 2)]
Xliff m: my @a = gather for ^3 { my @a = (0, 1, 2); take |@a.flat }; @a.gist.say
camelia [(0 1 2) (0 1 2) (0 1 2)] 10:50
Xliff Hum.
11:02 patrickb left 11:14 morayj left 11:31 patrickb joined 12:01 Xliff left
moritz my @a = flat gather for ^3 { my @a = (0, 1, 2); take @a }; say @a 12:35
evalable6 [0 1 2 0 1 2 0 1 2]
Geth rakudo: 3def3ced38 | (Elizabeth Mattijsen)++ | 2 files
Properly mark native shaped1 candidates

Some were missing "is raw", all were missing "is default" to resolve dispatch problems with upcoming unshaped native candidates.
12:52
13:05 lucasb joined 13:08 sena_kun joined 13:09 Altai-man left 14:04 frost-lab left 14:54 patrickb left 14:55 patrickb joined 15:14 melezhik joined
melezhik hi! do we have a list of GH issue are going to resolved in the next release? 15:15
Geth rakudo: 705e6e62c5 | (Elizabeth Mattijsen)++ | 4 files
Give native arrays their own postcircumfix candidates

This makes native array access about 40% faster, making it now 25% faster again than shaped native array access.
Remove some candidates from the shaped native array circumfixes that can be handled by the non-shaped native array access ones.
Adapted error message test to check for the mention of type of native array.
melezhik to resolve -> to be resolved
lizmat the ones marked "blocker: I guess ?
melezhik github.com/rakudo/rakudo/issues?q=...+is%3Aopen only 2 issues here? 15:18
lizmat melezhik: yeah, looks like
melezhik I am looking to the closed ones - github.com/rakudo/rakudo/issues?q=...s%3Aclosed , which one from this group are going to be included in the next release? 15:20
lizmat basically all that got closed since the last release ? 15:22
melezhik ok, let me put it this way. I am thinking about having all to be shipped as a next release resolved issues in RICH 15:23
so that devs could take a look at the related RP tests and verify that issues are really gone against HEAD commit 15:24
lizmat that would be very nice... but some issues get closed without any code changes... 15:25
melezhik so far it's just a set of some (recent) issue I greped from GH issues pages - rakudist.raku.org/play/rakudo-issues
lizmat so I don't think you can automate that so easily
melezhik yeah, I see. I am only talking about the type of issues where bug fixes and one can verify it through a RP test
and this is main point in here - sparrowdo.wordpress.com/2020/12/03...es-player/ 15:26
lizmat I guess we could think about some standard format in issues
to make this easier
melezhik yeah ... 15:27
lizmat "Let's make it easier for Richie" :-)
melezhik let's make it easier for everyone :]
so extracting code samples from GH could be a final goal, so far it's just a matter of creating some (unit Test ?) via RP and named it as "issue-$issue_numer" 15:28
number 15:29
after that Sparky cron will start replaying the scenario for all other new commits and have summary at the RICH page
lizmat cool! 15:33
melezhik rakudist.raku.org/sparky/report/RakuPlay-1/2740 just an example. issue-4085 in the build title matters, this is how RICH cron knows it needs to rerun the same build for all new rakudo commits 15:34
16:24 melezhik left 16:30 cog joined 16:57 Xliff joined 17:01 domidumont left 17:07 Altai-man joined 17:09 sena_kun left 17:11 moray joined, moray is now known as morayj
[Tux] Rakudo v2020.11-93-g705e6e62c (v6.d) on MoarVM 2020.11-54-ga595d9ddc
csv-ip5xs0.832 - 0.839
csv-ip5xs-207.880 - 8.673
csv-parser24.635 - 25.020
csv-test-xs-200.388 - 0.398
test7.571 - 7.860
test-t1.884 - 1.893
test-t --race0.844 - 0.926
test-t-2031.972 - 32.423
test-t-20 --race9.364 - 9.747
17:14
Geth nqp: e7b2b7e0c8 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Some ops documentation reshuffling

  - moved some lemma's to a proper chapter
  - created new "Profiling" and "Introspection" section
17:15
nqp: 50862433a3 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Restore Miscellaneous section

It got clobbered in the last commit
nqp: 04a2ddb79f | (Elizabeth Mattijsen)++ | docs/ops.markdown
Some more moving lemma's around

Remove the Variable section, added a Time section
17:20
18:17 morayj left
Geth rakudo: 4304e25059 | (Elizabeth Mattijsen)++ | 3 files
Fixes to native @a[Iterable]

  - Return a list of the same native type, instead of an Opaque one
  - Handle Iterables in containers correctly
18:21
18:21 domidumont joined 18:24 domidumont left 19:41 MasterDuke joined
Geth rakudo: 6c7044ec31 | (Elizabeth Mattijsen)++ | 3 files
Tighten up native @a[] invocant signatures

Candidates can't handle type objects as invocant, so don't allow that.
20:13
21:05 Altai-man left 21:22 patrickb left 21:23 patrickb joined 23:10 leont joined 23:13 patrickb left