[04:17] *** ShimmerFairy left
[04:19] *** ShimmerFairy joined
[08:00] *** rnddim joined
[08:01] *** rnddim left
[08:01] *** rnddim joined
[08:02] *** ShimmerFairy left
[08:03] *** rnddim left
[08:03] *** rnddim joined
[08:09] *** rnddim left
[08:10] *** rnddim joined
[08:31] *** rnddim is now known as ShimmerFairy

[09:06] <Geth> ¦ rakudo/add-AI-policy: 682876f06b | (Elizabeth Mattijsen)++ | AI-POLICY.md

[09:06] <Geth> ¦ rakudo/add-AI-policy: Cat-license Perl 5's AI- policy

[09:06] <Geth> ¦ rakudo/add-AI-policy: 

[09:06] <Geth> ¦ rakudo/add-AI-policy: Instigated by https://jam.xwx.moe/objects/fc407208-be1c-42f9-9074-f6c9d3185ebe

[09:06] <Geth> ¦ rakudo/add-AI-policy: 

[09:06] <Geth> ¦ rakudo/add-AI-policy: This will hopefully make the Rakudo core team's stance on the use

[09:06] <Geth> ¦ rakudo/add-AI-policy: of LLMs in Rakudo's development clearer.

[09:06] <Geth> ¦ rakudo/add-AI-policy: 

[09:06] <Geth> ¦ rakudo/add-AI-policy: Kudos to the PSC for writing this up.

[09:06] <Geth> ¦ rakudo/add-AI-policy: review: https://github.com/rakudo/rakudo/commit/682876f06b

[09:06] <Geth> ¦ rakudo: lizmat++ created pull request #6847: Cat-license Perl 5's AI- policy

[09:06] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6847

[11:35] <ShimmerFairy> m: say (8^..6).int-bounds; # I know Ranges aren't supposed to be used backwards, but still, is this intended behavior? I'd expect (7 6)

[11:35] <camelia> rakudo-moar e17a1d43b: OUTPUT: «(9 6)␤»

[11:41] <lizmat> int-bounds just returns the bounds...     the range is perfectly valid, it just won't produce any values ever

[11:42] <lizmat> for the left side of ..  a ^ means add one,   for the right side it means subtract one

[11:50] <ShimmerFairy> Yeah, I see what it's currently doing, I'm just checking to make sure that the simplistic "add 1 on the left, subtract 1 on the right" is intended, or if the carets should Do What I Mean when the range is specified backwards.

[11:51] <lizmat> for DWIM we have ...

[11:51] <lizmat> m: dd 8^....6

[11:51] <camelia> rakudo-moar e17a1d43b: OUTPUT: «(7, 6, 5, 4, 3, 2, 1).Seq␤»

[11:52] <lizmat> m: dd 8^...6

[11:52] <camelia> rakudo-moar e17a1d43b: OUTPUT: «(7, 6).Seq␤»

[11:52] <lizmat> ah, the magic of ...  :-)

[11:52] <lizmat> the first one was really:

[11:52] <lizmat> m: dd 8^...   .6

[11:52] <camelia> rakudo-moar e17a1d43b: OUTPUT: «(7, 6, 5, 4, 3, 2, 1).Seq␤»

[11:54] <ShimmerFairy> The tricky bit is that Ranges aren't intended to work backwards, so it's reasonable to say "the behavior is unspecified", but as long as Range.new() doesn't die on backwards ranges, it's worth considering what should happen if someone does it anyway.

[11:55] <lizmat> well, I vaguely remember discussions about that before Christmas, and I think @LARRY decided that such a range is valid, it will just never produce or match anything

[12:00] <ShimmerFairy> In my case, I'm writing code to take in an integer Range and make sure it's a valid one. If `8^..6` did the mathematical thing, then I could easily let them through generically by rewriting them with a `Range.new(|$r.int-bounds.sort)`. But since it produces the "wrong" result, I'm inclined to just error out on backwards ranges instead.

[12:07] <lizmat> if you're sure that you only deal with int ranges, then that would be an approach

[12:07] <lizmat> alas, Range is not just for ints, but also nums, and strings, and anything that has a .succ method

[12:07] <lizmat> (if I remember correctly)

[12:11] <ShimmerFairy> Yeah, I'm already filtering out invalid ranges (and frankly they shouldn't make it to the constructor in the first place), so one more criterion isn't a big deal. It would just be neat if backwards int Ranges were functional enough to effortlessly correct them without checking for them.

[16:31] <Geth> ¦ nqp/main: e1d130c400 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION

[16:31] <Geth> ¦ nqp/main: Bump MoarVM to get line number annotations fix

[16:31] <Geth> ¦ nqp/main: 

[16:31] <Geth> ¦ nqp/main: When instrumenting bytecode, Marco Ladermann++

[16:31] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/e1d130c400

[16:46] <Geth> ¦ rakudo/add-AI-policy: 065fcb97b8 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[16:46] <Geth> ¦ rakudo/add-AI-policy: Bump NQP to get line number annotations fix

[16:46] <Geth> ¦ rakudo/add-AI-policy: 

[16:46] <Geth> ¦ rakudo/add-AI-policy: When instrumenting bytecode, Marco Ladermann++

[16:46] <Geth> ¦ rakudo/add-AI-policy: review: https://github.com/rakudo/rakudo/commit/065fcb97b8

[16:46] <lizmat> grrr   wrong branch

[16:47] <[Coke]> I'd go ahead and force push a fix to that AI branch.

[16:47] <[Coke]> should be fine.

[16:47] <Geth> ¦ rakudo/main: 61840cfd3e | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[16:47] <Geth> ¦ rakudo/main: Bump NQP to get line number annotations fix

[16:47] <Geth> ¦ rakudo/main: 

[16:47] <Geth> ¦ rakudo/main: When instrumenting bytecode, Marco Ladermann++

[16:47] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/61840cfd3e

[16:47] <[Coke]> let me know if anything in the last few days is blin worthy

[16:49] <lizmat> so I was looking at .sort just now

[16:50] <lizmat> so sort is documented as returning a Seq

[16:51] <lizmat> m: my  int @a = 3,2,1; dd @a.sort

[16:51] <camelia> rakudo-moar e17a1d43b: OUTPUT: «int  = array[int].new(1, 2, 3)␤»

[16:51] <lizmat> but that's just not always true

[16:51] <lizmat> thing is, to be able to sort something, it has to produce all values eagerly

[16:51] <lizmat> and the result is always a list of some sort

[16:51] <[Coke]> not sure if we ever did the cleanup, but we have a lot of docs that claim to return a very specific type when a more generic one is probably a better answer for the language (as opposed to Rakudo)

[16:52] <[Coke]> not sure if we decided the right answer was Positional or not

[16:52] <lizmat> so yes, I was thinking of Iterable ?

[16:52] <[Coke]> Sure.

[16:52] <lizmat> m: dd Seq ~~ Positional

[16:52] <camelia> rakudo-moar e17a1d43b: OUTPUT: «Bool::False␤»

[16:52] <lizmat> definitely not Positional

[16:53] <[Coke]> whoops.

[16:53] <lizmat> Seq does the PositionalBindFailOver role

[16:54] <lizmat> so if a Seq is used as a Positional, it will cache and use the underlying list for Positional access

[17:08] <Geth> ¦ roast/lizmat-1: 0e77fe1e0f | (Elizabeth Mattijsen)++ | S32-list/sort.t

[17:08] <Geth> ¦ roast/lizmat-1: Make .sort return type checks less precise

[17:08] <Geth> ¦ roast/lizmat-1: 

[17:08] <Geth> ¦ roast/lizmat-1: It doesn't really matter what is being returned exactly, as long as

[17:08] <Geth> ¦ roast/lizmat-1: is-deeply checks out ok.

[17:08] <Geth> ¦ roast/lizmat-1: review: https://github.com/Raku/roast/commit/0e77fe1e0f

[17:08] <Geth> ¦ roast: lizmat++ created pull request #925: Make .sort return type checks less precise

[17:08] <Geth> ¦ roast: review: https://github.com/Raku/roast/pull/925

[17:21] <japhb> ShimmerFairy: I believe the reason that a reversed Range (as opposed to a reversed sequence) acts as if silently empty is to simplify writing algorithms that track two or more indices into a data set and continue "until the indices cross"

[17:58] *** [Coke] left
[18:04] *** [Coke] joined
[18:05] *** hankache joined
[18:46] *** coleman left
[18:47] <lizmat> m: class A { has uint $.a = 42 }; dd A.new.clone(:a(666))

[18:47] <camelia> rakudo-moar e17a1d43b: OUTPUT: «Unknown primspec in twiddling: 10␤  in block <unit> at <tmp> line 1␤␤»

[18:47] <lizmat> meh

[18:48] *** coleman joined
[18:53] <[Coke]> I was surprised to see a Pakku update in this weekly

[18:53] <[Coke]> I think it's safe to say zef is the recommended variant (but I suppose with other compilers now, perhaps the option is used more there?)

[18:57] *** coleman left
[18:58] *** coleman joined
[19:03] <Geth> ¦ rakudo/lizmat-75: 99195e2c9d | (Elizabeth Mattijsen)++ | src/core.c/Mu.rakumod

[19:03] <Geth> ¦ rakudo/lizmat-75: Make sure .clone with twiddles knows about uints

[19:03] <Geth> ¦ rakudo/lizmat-75: 

[19:03] <Geth> ¦ rakudo/lizmat-75: Fixed:

[19:03] <Geth> ¦ rakudo/lizmat-75:   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'

[19:03] <Geth> ¦ rakudo/lizmat-75:   A.new(a => 154)

[19:03] <Geth> ¦ rakudo/lizmat-75: 

[19:03] <Geth> ¦ rakudo/lizmat-75: Was:

[19:03] <Geth> ¦ rakudo/lizmat-75:   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'

[19:03] <Geth> ¦ rakudo/lizmat-75:   Unknown primspec in twiddling: 10

[19:03] <Geth> ¦ rakudo/lizmat-75: review: https://github.com/rakudo/rakudo/commit/99195e2c9d

[19:03] <Geth> ¦ rakudo: lizmat++ created pull request #6849: Make sure .clone with twiddles knows about uints

[19:03] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6849

[19:18] <[Coke]> lizmat: looking at https://github.com/Raku/raku.org/pull/328, but IIRC, I'm blocked by a bug somewhere.

[19:19] <[Coke]> re-installing deps...

[19:21] <lizmat> UUID4 ?

[19:34] <[Coke]> ah, I installed with --/test cro, air which I probably did not do last time. :|

[19:37] <[Coke]> What browsers do we want to support on raku.org. Chrome, Firefox, Safari, anything else that has a different engine?

[19:45] <[Coke]> Moving that question to #raku

[19:53] <Geth> ¦ rakudo/main: 9adc19cb0b | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Mu.rakumod

[19:53] <Geth> ¦ rakudo/main: Make sure .clone with twiddles knows about uints (#6849)

[19:53] <Geth> ¦ rakudo/main: 

[19:53] <Geth> ¦ rakudo/main: Fixed:

[19:53] <Geth> ¦ rakudo/main:   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'

[19:53] <Geth> ¦ rakudo/main:   A.new(a => 154)

[19:53] <Geth> ¦ rakudo/main: 

[19:53] <Geth> ¦ rakudo/main: Was:

[19:53] <Geth> ¦ rakudo/main:   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'

[19:53] <Geth> ¦ rakudo/main:   Unknown primspec in twiddling: 10

[19:53] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/9adc19cb0b

[20:00] <Geth> ¦ roast/lizmat-2: ecadedeb68 | (Elizabeth Mattijsen)++ | S12-attributes/clone.t

[20:00] <Geth> ¦ roast/lizmat-2: Add test for twiddling uint attributes in clone

[20:00] <Geth> ¦ roast/lizmat-2: 

[20:00] <Geth> ¦ roast/lizmat-2: As fixed in https://github.com/rakudo/rakudo/commit/9adc19cb0b

[20:00] <Geth> ¦ roast/lizmat-2: review: https://github.com/Raku/roast/commit/ecadedeb68

[20:00] <Geth> ¦ roast: lizmat++ created pull request #926: Add test for twiddling uint attributes in clone

[20:00] <Geth> ¦ roast: review: https://github.com/Raku/roast/pull/926

[20:07] <Geth> ¦ roast: cf28a323c2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-list/sort.t

[20:07] <Geth> ¦ roast: Make .sort return type checks less precise (#925)

[20:07] <Geth> ¦ roast: 

[20:07] <Geth> ¦ roast: It doesn't really matter what is being returned exactly, as long as

[20:07] <Geth> ¦ roast: is-deeply checks out ok.

[20:07] <Geth> ¦ roast: review: https://github.com/Raku/roast/commit/cf28a323c2

[20:07] <linkable6> ROAST#925 [closed]: https://github.com/Raku/roast/pull/925 Make .sort return type checks less precise

[20:19] <Geth> ¦ roast/lizmat-3: 7e463a547a | (Elizabeth Mattijsen)++ | 2 files

[20:19] <Geth> ¦ roast/lizmat-3: Make .sort return type checks less precise (2)

[20:19] <Geth> ¦ roast/lizmat-3: 

[20:19] <Geth> ¦ roast/lizmat-3: Two more cases where s/is-eqv/is-deeply makes sense.

[20:19] <Geth> ¦ roast/lizmat-3: review: https://github.com/Raku/roast/commit/7e463a547a

[20:20] <Geth> ¦ roast: lizmat++ created pull request #927: Make .sort return type checks less precise (2)

[20:20] <Geth> ¦ roast: review: https://github.com/Raku/roast/pull/927

[20:41] <Geth> ¦ raku.org: ash++ created pull request #331: "Learn" page updates.

[20:41] <Geth> ¦ raku.org: review: https://github.com/Raku/raku.org/pull/331

[22:19] <[Coke]> https://stackoverflow.com/questions/62432498/how-do-i-checkout-a-pr-from-a-fork - oops, apparently github makes this very easy

[22:49] *** hankache left