🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
08:25
finanalyst left
08:40
TheAthlete joined
09:16
guifa left
09:19
guifa joined
|
|||
lizmat | notable6: weekly | 09:45 | |
notable6 | lizmat, 1 note: 2025-05-26T07:49:49Z <librasteve>: rakujourney.wordpress.com/2025/05/...avigation/ | ||
lizmat | notable6: weekly reset | ||
notable6 | lizmat, Moved existing notes to “weekly_2025-05-26T09:45:44Z” | ||
lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/05/26/2025-...rcigation/ | 09:57 | |
10:32
finanalyst joined
|
|||
lizmat | nine: looking at github.com/rakudo/rakudo/commit/2ec173ab07 it feels that this really should be an operator property | 11:38 | |
also feels that github.com/rakudo/rakudo/blob/main...#L331-L333 is missing a few cases | 11:40 | ||
such as ⚛+= , ⚛-= and ⚛−= ? | |||
m: my atomicint $a; $a ⚛+= 42 # shows a worry in RakuAST, but not in legacy | 11:55 | ||
camelia | ( no output ) | ||
lizmat | so I was thinking of adding a "sinky" attribute in OperatorProperties | 11:57 | |
but that would mean a default of true: looking for a term to use to allow for a default of false (like the other attributes) | |||
half serious: titanicy (as in unsinkable) | 11:58 | ||
nine | I think the major advantage operator properties have is that they are available for custom operators. That is certainly a big plus for that idea. | ||
Not sure about the name though. Those existing property names are overly cute and not at all descriptive ("fiddly", err...right, huh?). I wouldn't know what "sinky" means either. | 11:59 | ||
lizmat | ok, so a straightforward: unsinkable then ? | 12:00 | |
nine | That would be wrong. It's entirely possible to sink the result of such an operator. | ||
What really differentiates here is whether an operator may have side effects or not. We shouldn't warn if the point of applying the operator may be the side effect. | 12:01 | ||
lizmat | so the name of the method "can-be-sunk" is not really right then either ? | ||
nine | As the side effect may be the reason for applying the operator in the first place as is usually the case with anything that assigns. | ||
lizmat | "has-side-effects" then ? | 12:02 | |
nine | Well the opposite of has-side-effects is "pure" which is a term we already use for precisely this meaning | 12:03 | |
I'd say can-be-sunk is not great but not entirely wrong either given the context. It's about whether the compiler may generate the .sink call. | 12:06 | ||
lizmat | but we can't use the "pure"ness of an operator as a flag for can-be-sunk semantics, right ? | 12:11 | |
or: if we make "pure" an Operator Property, then we could get rid of all of the "is pure" on operators in core :-) | 12:15 | ||
12:18
finanalyst left
12:38
finanalyst joined
12:52
rakkable left,
rakkable__ joined
|
|||
Geth | rakudo/main: bffe23777c | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod RakuAST: rename "can-be-sunk" to the more appropriate "is-pure" Following discussion at irclogs.raku.org/raku-dev/2025-05-26.html#11:38 Also make sure that use of ⚛+= , ⚛-= and ⚛−= do not cause worries. |
12:55 | |
roast: 3549a55760 | (Daniel Green)++ | packages/Test-Helpers/lib/Test/Util.rakumod Remove useless `,` It wasn't a real problem, but was causing ``` Potential difficulties: Useless use of , in sink context at <...>/rakudo/t/spec/packages/Test-Helpers/lib/Test/Util.rakumod (Test::Util):433 ``` warnings if some tests files were run directly. |
14:14 | ||
14:59
finanalyst left
|
|||
japhb | Did 2025.04 have known stability issues? I'm trying to bisect a seeming incompatibility between Terminal::Widgets (or one of its dependencies) and latest Rakudo, but when I try to build everything for 2025.04, random tests fail all over the place -- some in Rakudo's own test suite, some in the tests of various modules. No real consistency that I've seen so far. | 19:31 | |
(And the failing tests don't repeat from run to run.) | 19:32 | ||
19:34
TheAthlete left
|
|||
[Coke] | I believe I did that release - didn't notice any stability issues doing testing, no one else has reported issues. | 20:14 | |
:( | 20:17 | ||
japhb | Maybe I'm just unlucky today | 20:34 | |
lizmat | japhb: I see instability like that if you didn't nuke install between building different versions | 22:18 | |
japhb | I have been, though with enough flapping tests across Rakudo and all of the modules I build, it can be a pain to get a good build from scratch if there's even a *little* more instability than usual. | 22:20 | |
Still, I'm slowly closing in on where Rakudo and Terminal::Widgets start fighting, though it's a bit of a slog TBH. | 22:21 |