| 12 Jan 2026 | |||
| camelia | any(any(8, 9, 10), any(9, 10, 11), any(10, 11, 12)) | 13:10 | |
| lizmat | one could also argue that the current infix:<~>(Junction, Junction) behaviour is ... incorrect ? | ||
| m: dd any(1,2,any(3,4,5)) + any(7,8,9) # nested with infix:<+> | 13:12 | ||
| camelia | any(any(8, 9, 10), any(9, 10, 11), any(any(10, 11, 12), any(11, 12, 13), any(12, 13, 14))) | ||
| lizmat | m: dd any(1,2,any(3,4,5)) ~ any(7,8,9) # nested with infix:<+> | ||
| camelia | This type cannot unbox to a native string: P6opaque, Junction in block <unit> at <tmp> line 1 |
||
| lizmat | *~ | ||
| bisectable6: my $a := "a" | "b" | ("c" | "d"); my $b := "f" | "g"; dd $a ~ $b | 13:23 | ||
| bisectable6 | lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| lizmat, Output on all releases: gist.github.com/9197a1dbfe673eecc4...79f160d28e | 13:24 | ||
| lizmat, Bisecting by exit code (old=2017.08 new=2017.09). Old exit code: 0 | |||
| lizmat, bisect log: gist.github.com/46cd4f37fb59004b1a...62928d47e9 | 13:25 | ||
| lizmat, (2017-08-27) github.com/rakudo/rakudo/commit/95...5ba40e8941 | |||
| lizmat, ⚠ New output detected, please review the results manually | |||
| lizmat, Output on all releases and bisected commits: gist.github.com/5c96f0c2692ea27a83...a40d52684c | |||
| librasteve_ | rakudoweekly.blog/2026/01/12/2026-...solutions/ | 17:18 | |
| lizmat | librasteve_++ | 17:21 | |
| [Coke] | releasable6: next | 17:35 | |
| releasable6 | [Coke], Next release in ≈12 days and ≈1 hour. There are no known blockers. 12 out of 16 commits logged | ||
| [Coke], Details: gist.github.com/6e34e0dfcfee4ea403...cb0df98c63 | |||
| [Coke] | librasteve_: FYI, the next release date will be a few days later than previously scheduled, probably not complete by the next weekly | 17:41 | |
| releasable6: next | |||
| releasable6 | [Coke], Next release in ≈12 days and ≈1 hour. There are no known blockers. 16 out of 16 commits logged | ||
| disbot11 | <librasteve> [Coke]: thanks for the heads up | 18:39 | |
| 13 Jan 2026 | |||
| [Coke] | librasteve_: what did I do? :) | 13:51 | |
| disbot11 | <librasteve> I was reading your DAMMIT comments on the error message from late last night (my time) ;-) | 14:09 | |
| <librasteve> (thus the smile on the #raku chan) | 14:10 | ||
| [Coke] | :) | 14:50 | |
| [Coke] ponders a raku-off topic but supposes he could just use discord. :| | 14:59 | ||
| [Coke] is just old enough to really not care for discord. :) | |||
| timo | let's have a general channel for raku people that's not necessarily about raku ... let's pun it off of the mug throwing incident maybe? let's see ... #muggers? okay scratch that ignore me argh | 16:57 | |
| disbot11 | <librasteve> i’m good with that … Discord (barf) already has “other-programming” and “off-topic” suggest we add those to IRC and then bridge em?? | 17:32 | |
| lizmat | in a universe long ago and far away, there existed a "channel" on PLATO called "pad", where anything could and did go | 18:13 | |
| maybe #raku-pad ? | |||
| (unlogged) | |||
| timo | no: left-pad. yes: raku-pad ;) | 18:15 | |
| lizmat | 18:22 | ||
| 14 Jan 2026 | |||
| patrickb | m: (1,2,3).map(*.&a); sub a($t) { } | 16:10 | |
| camelia | ( no output ) | ||
| patrickb | How camelia the above with RakuAST? | ||
| *How can I | 16:11 | ||
| m: Q|(1,2,3).map(*.&a); sub a($t) { }|.AST.EVAL | 16:13 | ||
| camelia | ===SORRY!=== Error while compiling EVAL_0 Undeclared routine: a used at line 1 |
||
| patrickb | ^ That's the zef on RakuAST error I've been seeing. | 16:14 | |
| Note that sub a is put after the call, not before. | 16:15 | ||
| lizmat | I guess the lookup for &a is too eager | 16:16 | |
| and that's a bug in RakuAST I'd say | |||
| patrickb | same breakage when using $_.& syntax | 16:17 | |
| Works when using a($_) syntax | 16:18 | ||
| lizmat | I guess the &a in RakuAST always directly translates into a lookup and when that fails, errors out | 16:19 | |
| I guess in the legacy grammar it just assumes it will be looked up later | |||
| ab5tract | I think it might be that the routine is not installed into the EVAL'd scope, and we are much more graceful about what we put in there, so that an imported sub is visible to EVAL's with the base compiler | 17:36 | |
| but it is not currently visible during an EVAL in RakuAST | 17:37 | ||