Geth rakudo/main: 0036539579 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
Refactor error X::Syntax::InfixInTermPosition

This error is most often called if there is an error in Pod/RakuDoc syntax. So make those types of cases much more elaborate, and mention the fact that a term was expected as a last option.
So a "=begin FOO" without "=end FOO" will now (in RakUAST) be reported as: ... (7 more lines)		 07:18
rakudo/lizmat-28: 6 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 07:21
10:51 djinni` left 10:57 djinni` joined 11:17 ShimmerFairy joined, ShimmerFairy left 11:18 ShimmerFairy joined, rnddim left 11:25 finanalyst joined 12:14 finanalyst left 13:51 vrurg joined 13:53 vrurg_ left
Geth setup-raku/dependabot/npm_and_yarn/postcss-8.5.25: ea0a4c12c4 | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump postcss from 8.5.16 to 8.5.25

Bumps [postcss](github.com/postcss/postcss) from 8.5.16 to 8.5.25.
  - [Release notes](github.com/postcss/postcss/releases)
  - [Changelog](github.com/postcss/postcss/blob/ma...NGELOG.md)
  - [Commits](github.com/postcss/postcss/compare......8.5.25)
... (8 more lines)		 14:17
setup-raku: dependabot[bot]++ created pull request #60:
Bump postcss from 8.5.16 to 8.5.25
14:26 jdv left 14:27 jdv joined
lizmat we have Hash.push(key,values) and Hash.append(key,values) 15:33
but I just realized we don't have Hash.unshift(key,values) or Hash.prepend(key,values) 15:34
ugexe i dont think any of those make much sense for something without a set order 15:44
lizmat well, Hash.push and Hash.append set an order in the value of the key 15:45
ugexe push/append on a Hash feel like "accumulate into this key" conviences and the ordering behavior is incidental (and type dependant), not a principled order the api promises. unshift/prepend are more order sensitive, which might be why they weren't added 16:03
m: my %h = a => { :1x, :2y, :3z, :4w }; %h.append: (a => 5); say %h<a> 16:04
camelia [z => 3 w => 4 x => 1 y => 2 5]
ugexe m: my %h = a => { :1x, :2y, :3z, :4w }; %h.append: (a => 5); say %h<a>
camelia [y => 2 w => 4 z => 3 x => 1 5]
ugexe m: my %h = a => { :1x, :2y, :3z, :4w }; %h.append: (a => 5); say %h<a>
camelia [w => 4 x => 1 y => 2 z => 3 5]
lizmat but but., push and append where never meant to be used on an HoH ? 16:06
m: my %h; %h.push("a",42); dd %h; %h.push("a",666); dd %h
camelia {:a(42)}
{:a($[42, 666])}
lizmat m: my %h; %h.push("a",42); dd %h; %h.push("a",[666,777]); dd %h 16:07
camelia {:a(42)}
{:a($[42, [666, 777]])}
lizmat m: my %h; %h.push("a",42); dd %h; %h.append("a",[666,777]); dd %h
camelia {:a(42)}
{:a($[42, 666, 777])}
ugexe right, and that's kind of my point. if they're only meant for HoA then the order isn't something push/append provide, it's a property of the Array that happens to be sitting in the value. the hash itself is still unordered 16:09
lizmat right, and that's understood 16:10
it's not about the order of keys in the hash, it's about the order of the array in the values 16:11
ugexe so unshift/prepend can't be justified as symmetry with an order those methods establish. it'd have to be justified by "prepending into a HoA is a common enough pattern to deserve core methods", and i don't know that it is. %h{$k}.unshift(...) would already covers most of it
lizmat I mean, Array.unshift and Array.prepend where created for a reason
I just wonder why we don't have a similar function for Hash, analogous to Hash.push/append 16:12
ugexe fwiw TimToady created the push/unshift vs append/prepend split on 2015-09-30 (4f7065226c) and then added Hash.append 17 days later (d147280a99) without bringing prepend/unshift along. so the asymmetry was made by the guy who invented the symmetry, with it fresh in mind. reads more like a judgment call than an oversight. but thats just my opinion, i doubt any of us can for sure know what his 16:18
intention was since he did not explicitly state it
lizmat well, fwiw, I just ran into a situation where having %hash.prepend would have been nice 16:19
no worries, I worked around it :-) 16:20
ugexe if you have an actual use case then maybe it can be justified. my reasoning is also based in part that in a decade no one has brought up such a use case, and so the burden of proof should be on the addition 16:21
16:24 lizmat_ joined 16:27 lizmat left, lizmat_ left 16:28 lizmat joined
lizmat the actual use case: github.com/raku-community-modules/...#L122-L127 16:28
during an update of Email::Simple
ugexe im confused, because that is code inside a method called header-set 16:36
i.e. a replacement operation
lizmat that's what you'd think, right? 16:37
but it isn't
at least not there
because you can have multiple headers with the same name
and the semantics apparently are that header-set put's it before the first other with the same name 16:38
I'm not sure the semantics are sane, but didn't want to break it
ugexe header-set takes multiple values 16:39
lizmat I wanted to at least have the most common operation (give me the value of this header) be a hash lookup
rather than needing to walk the array time after time
anyways, that's where I wondered why we don't have Hash.prepend 16:40
no worries, just wondering, and definitely not something you need often 16:41
now on to Net::SMTP
but later&
18:10 finanalyst joined
ugexe i dont know when we'll do the next RakuAST blin run, but one thing that came to mind is we probably could just run the list of failures instead of everything, and do the full run less often to save resources / time 18:26
18:34 rakkable left 18:36 rakkable joined
Geth rakudo: ugexe++ created pull request #6501:
Make coercions check subset refinements on every value		 19:34
nqp/main: 2d34221b0c | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for mimalloc 3.4.4

  MasterDuke++		 20:10
20:17 donaldh left
Geth rakudo/main: 4aa6cf1901 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for mimalloc 3.4.4, MasterDuke++
 20:20
20:27 finanalyst left
Geth rakudo: ugexe++ created pull request #6502:
RakuAST: sink when/default bodies whose succeed payload is unused		 20:31
rakudo: ugexe++ created pull request #6503:
RakuAST: skip the runtime type check on the implicit method invocant		 21:31
[Coke] waves from the new locally hosted blin box. 21:40
(which maybe doubles as a very small windows game box?) 21:41
(figured out that azure costs about .80USD a day if everything is turned off (to keep the lights on for the disk), and closer to 13USD a day if you leave it on but not doing anything (which I apparently did, all month) 21:46
Geth setup-raku: a6623fe084 | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump postcss from 8.5.16 to 8.5.25 (#60)

Bumps [postcss](github.com/postcss/postcss) from 8.5.16 to 8.5.25.
  - [Release notes](github.com/postcss/postcss/releases)
  - [Changelog](github.com/postcss/postcss/blob/ma...NGELOG.md)
  - [Commits](github.com/postcss/postcss/compare......8.5.25)
... (9 more lines)		 21:58
ugexe it annoys me that i get a $0 invoice from azure every month 22:03
as i dont have any resources on azure anymore 22:05
22:23 donaldh joined
Geth rakudo: ugexe++ created pull request #6504:
RakuAST: stop thunking the right side of test assignments		 22:45
Blin: 89417011fc | (Will Coleda)++ | META6.json
Actually remove Pakku dep
 22:56
[Coke] Trying to run blin on the new box. 23:04
fetching raw.githubusercontent.com/ugexe/Pe.../p6c1.json
curl: (56) Recv failure: Connection reset by peer
at end of input: expected a json object
lizmat yeah, that trips up the REA harvester as well every now and then 23:05
[Coke] this is like 4 times in a row. 23:06
it's happening SO frequently here. :| 23:09
appears to be ipv6 related. 23:17
lizmat yup, the harvester had crashed again, just 20 mins ago 23:18
and now it was fine... anyways, sleep& 23:19
[Coke] kicks off an early blin run.
This felt much easier to get to a point where I could start testing than on azure, but that's probably because I had already done it on azure at one point 23:26
bah, am going to have to regen some keys for the release. 23:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!