🦋 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.
SmokeMachine any sugestion on how to fix that? 00:08
lizmat get nqp::getdynlex to do all the work that &DYNAMIC does 00:15
sleep&
SmokeMachine should that be changed on Cro? I was trying to avoid that... 00:20
ab5tract SmokeMachine: I poked at this a bit last night and couldn’t fully reconcile what’s going wrong 14:23
ugexe: it does look like there is still a subtle bug in the candidate filtering for revision gating with coercion types 14:26
A surface level solution is to fully qualify all of the argument types (other than the slurpy) 14:27
But I’ll also look into what’s going wrong underneath. The question is, do we need that deeper patch in place prior to merging or is the surface patch Good Enough For The Meanwhile? 14:29
FWIW, having single arg callers go through the slurpy is probably subtly wrong because the input will be returned as a single value array.. 14:30
ab5tract just now sees R#5749 😅 14:32
linkable6 R#5749 [closed]: github.com/rakudo/rakudo/issues/5749 "none of these signatures matches" output is confusing when using revision-gated trait
ab5tract I was trying to verify if this was revision gating specific last night but couldn’t find an incantation to demonstrate it wasn’t, so I would be curious to see that when you get a chance ugexe 14:34
[Tux] Rakudo v2024.12-33-ge7f9223c5 (v6.d) on MoarVM 2024.12-10-g1c2ea87e7
csv-ip5xs0.259 - 0.259
csv-ip5xs-201.088 - 1.135
csv-parser1.424 - 1.503
csv-test-xs-200.143 - 0.146
test1.833 - 1.881
test-t0.413 - 0.415
test-t --race0.277 - 0.280
test-t-204.999 - 5.051
test-t-20 --race1.248 - 1.285
 16:51
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth rakudo/ugexe/deprecate-multi-file-operations: 53177c6698 | (Nick Logan)++ (committed by ab5tract) | 3 files
Deprecate IO subs that operate on multiple paths in 6.e

While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure?
... (10 more lines)		 16:52
rakudo/ugexe/deprecate-multi-file-operations: 6e7221a6bd | ab5tract++ | 3 files
Apply revision-gating to chmod/chown/rmdir/unlink

The idea is that the semantics of providing multiple-path versions of these subs is a mistake.
As currently implemented, this patch leaves the behavior the same for all previous language versions and adding a deprecation message ... (6 more lines)
rakudo/ugexe/deprecate-multi-file-operations: 6a1c0dd9f2 | ab5tract++ | src/core.c/io_operators.rakumod
Solidify all argument types to resolve dispatch ambiguity

Also ensure that single argument editions return their inputs.
Geth rakudo/ugexe/deprecate-multi-file-operations: bd47ea7d2e | ab5tract++ | src/core.c/io_operators.rakumod
Back to more multi candidates to avoid ambiguity
 21:15
ugexe ab5tract: the single path candidates for unlink, rmdir (and maybe others?) also need to continue returning the path for 6.c and 6.d 22:20
ab5tract rmdir needs to return the result of the rmdir operation 22:47
I learned this while fixing some broken rmdir tests :)
The expectation is a Bool 22:48
I assume this is the case for unlink as well, but I'll double check
m: dd unlink("/tmp/nonexistent") 22:53
camelia ["/tmp/nonexistent"]
ab5tract m: dd rmdir("/tmp/nonexistent")
camelia []
ab5tract wtf...
ah, ok, so it returns the path iff it succeeded
m: dd "/tmp/nonexistent".IO.rmdir 22:54
camelia Failure.new(exception => X::IO::Rmdir.new(path => "/tmp/nonexistent", os-error => "Failed to rmdir: no such file or directory", error-code => Any))
ab5tract m: dd "/tmp/nonexistent".IO.unlink 22:55
camelia Bool::True
Geth rakudo/ugexe/deprecate-multi-file-operations: bbdb8f29e0 | ab5tract++ | src/core.c/io_operators.rakumod
Where the waterbed leaves us...
 23:23
rakudo/ugexe/deprecate-multi-file-operations: 18be884554 | ab5tract++ | src/core.c/io_operators.rakumod
Where the waterbed leaves us...
 23:24
ab5tract slurpees seem to be a bit of a weak spot either in revision gating or dispatch disambiguation at large 23:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!