04:17 ShimmerFairy left 04:19 ShimmerFairy joined 08:00 rnddim joined 08:01 rnddim left, rnddim joined 08:02 ShimmerFairy left 08:03 rnddim left, rnddim joined 08:09 rnddim left 08:10 rnddim joined 08:31 rnddim is now known as ShimmerFairy
Geth rakudo/add-AI-policy: 682876f06b | (Elizabeth Mattijsen)++ | AI-POLICY.md
Cat-license Perl 5's AI- policy

Instigated by jam.xwx.moe/objects/fc407208-be1c-...c9d3185ebe
This will hopefully make the Rakudo core team's stance on the use of LLMs in Rakudo's development clearer.
Kudos to the PSC for writing this up.		 09:06
rakudo: lizmat++ created pull request #6847:
Cat-license Perl 5's AI- policy
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 (9 6)
lizmat int-bounds just returns the bounds... the range is perfectly valid, it just won't produce any values ever 11:41
for the left side of .. a ^ means add one, for the right side it means subtract one 11:42
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:50
lizmat for DWIM we have ... 11:51
m: dd 8^....6
camelia (7, 6, 5, 4, 3, 2, 1).Seq
lizmat m: dd 8^...6 11:52
camelia (7, 6).Seq
lizmat ah, the magic of ... :-)
the first one was really:
m: dd 8^... .6
camelia (7, 6, 5, 4, 3, 2, 1).Seq
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:54
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 11:55
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:00
lizmat if you're sure that you only deal with int ranges, then that would be an approach 12:07
alas, Range is not just for ints, but also nums, and strings, and anything that has a .succ method
(if I remember correctly)
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. 12:11
Geth nqp/main: e1d130c400 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get line number annotations fix

When instrumenting bytecode, Marco Ladermann++		 16:31
rakudo/add-AI-policy: 065fcb97b8 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get line number annotations fix

When instrumenting bytecode, Marco Ladermann++		 16:46
lizmat grrr wrong branch
[Coke] I'd go ahead and force push a fix to that AI branch. 16:47
should be fine.
Geth rakudo/main: 61840cfd3e | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get line number annotations fix

When instrumenting bytecode, Marco Ladermann++
[Coke] let me know if anything in the last few days is blin worthy
lizmat so I was looking at .sort just now 16:49
so sort is documented as returning a Seq 16:50
m: my int @a = 3,2,1; dd @a.sort 16:51
camelia int = array[int].new(1, 2, 3)
lizmat but that's just not always true
thing is, to be able to sort something, it has to produce all values eagerly
and the result is always a list of some sort
[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)
not sure if we decided the right answer was Positional or not 16:52
lizmat so yes, I was thinking of Iterable ?
[Coke] Sure.
lizmat m: dd Seq ~~ Positional
camelia Bool::False
lizmat definitely not Positional
[Coke] whoops. 16:53
lizmat Seq does the PositionalBindFailOver role
so if a Seq is used as a Positional, it will cache and use the underlying list for Positional access 16:54
Geth roast/lizmat-1: 0e77fe1e0f | (Elizabeth Mattijsen)++ | S32-list/sort.t
Make .sort return type checks less precise

It doesn't really matter what is being returned exactly, as long as is-deeply checks out ok.		 17:08
roast: lizmat++ created pull request #925:
Make .sort return type checks less precise
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:21
17:58 [Coke] left 18:04 [Coke] joined 18:05 hankache joined 18:46 coleman left
lizmat m: class A { has uint $.a = 42 }; dd A.new.clone(:a(666)) 18:47
camelia Unknown primspec in twiddling: 10
in block <unit> at <tmp> line 1
lizmat meh
18:48 coleman joined
[Coke] I was surprised to see a Pakku update in this weekly 18:53
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
Geth rakudo/lizmat-75: 99195e2c9d | (Elizabeth Mattijsen)++ | src/core.c/Mu.rakumod
Make sure .clone with twiddles knows about uints

Fixed:
   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'
   A.new(a => 154)
Was:
   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'
   Unknown primspec in twiddling: 10		 19:03
rakudo: lizmat++ created pull request #6849:
Make sure .clone with twiddles knows about uints
[Coke] lizmat: looking at github.com/Raku/raku.org/pull/328, but IIRC, I'm blocked by a bug somewhere. 19:18
re-installing deps... 19:19
lizmat UUID4 ? 19:21
[Coke] ah, I installed with --/test cro, air which I probably did not do last time. :| 19:34
What browsers do we want to support on raku.org. Chrome, Firefox, Safari, anything else that has a different engine? 19:37
Moving that question to #raku 19:45
Geth rakudo/main: 9adc19cb0b | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Mu.rakumod
Make sure .clone with twiddles knows about uints (#6849)

Fixed:
   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'
   A.new(a => 154)
Was:
   $ raku -e 'class A { has uint8 $.a = 42 }; dd A.new.clone(:a(666))'
   Unknown primspec in twiddling: 10		 19:53
roast/lizmat-2: ecadedeb68 | (Elizabeth Mattijsen)++ | S12-attributes/clone.t
Add test for twiddling uint attributes in clone

As fixed in github.com/rakudo/rakudo/commit/9adc19cb0b		 20:00
roast: lizmat++ created pull request #926:
Add test for twiddling uint attributes in clone
roast: cf28a323c2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-list/sort.t
Make .sort return type checks less precise (#925)

It doesn't really matter what is being returned exactly, as long as is-deeply checks out ok.		 20:07
linkable6 ROAST#925 [closed]: github.com/Raku/roast/pull/925 Make .sort return type checks less precise
Geth roast/lizmat-3: 7e463a547a | (Elizabeth Mattijsen)++ | 2 files
Make .sort return type checks less precise (2)

Two more cases where s/is-eqv/is-deeply makes sense.		 20:19
roast: lizmat++ created pull request #927:
Make .sort return type checks less precise (2)		 20:20
raku.org: ash++ created pull request #331:
"Learn" page updates.		 20:41
[Coke] stackoverflow.com/questions/624324...rom-a-fork - oops, apparently github makes this very easy 22:19

Powered by Cro and the Raku® Programming Language.

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

Thank you!