🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
leont Is an Int keyed hash a good idea? In theory it sounds like it could be, but I have the impression that will just be an object-hash instead of a string/primitive hash (I'm not sure how to describe this) 00:20
lizmat leont: modules.raku.org/dist/Hash::int:cpan:ELIZABETH 00:34
rjbs lizmat++ 01:06
[Coke] sees he had a patch in progress on a module, makes the tests pass, gets to the "upload" bit and re-discovers that that's all changed since the last time 01:35
that's no fun, perhaps I'll figure out fez tomorrow.
[Coke] (\_/) 01:36
(•_•)
> 🐇
japhb fez++ # It pretty much Just Worked for me. 02:28
leont Is there a way to have a resettable timer? I can make a new Promise.in(), but I don't think I can cancel the old one, right? 14:33
lizmat leont: perhaps $*SCHEDULER.cue is more what you want: docs.raku.org/routine/cue 16:43
it returns a cancellation object
leont Yes, that does look like what I need 17:24
[Coke] so, I originally used p6c, then CPAN - is fez the preferred method now? Should I migrate off CPAN? 17:50
lizmat afaik, fez is still sorta in beta ? 18:03
smarton Just found out Raku has arbitrary-long integers by default, that's cool 18:18
We do live in 2021 after all
codesections here's an interesting error message that gives the impression that Rakudo can't count all that well:
m: sub f(*@a, **%h, |c) {}; f 1, 2, 3 18:19
camelia Too few positionals passed to 'f'; expected at least 2 arguments but got only 3
in sub f at <tmp> line 1
in block <unit> at <tmp> line 1
japhb [Coke]: My experience with fez has been pretty positive. I found a bug, it was fixed lickety-split. 18:20
And otherwise it's now just part of my release script. 18:21
codesections question: why does this die 20:15
m: sub f(Int $a?, *@s) {}; f('foo') 20:16
camelia 5===SORRY!5=== Error while compiling <tmp>
Calling f(Str) will never work with declared signature (Int $a?, *@s)
at <tmp>:1
------> 3sub f(Int $a?, *@s) {}; 7⏏5f('foo')
codesections It sure _seems_ like not passing an optional argument ought to be fine...
guifa2 m: sub f(Int $a?, Str $b?) {}; f('foo') 20:43
camelia 5===SORRY!5=== Error while compiling <tmp>
Calling f(Str) will never work with declared signature (Int $a?, Str $b?)
at <tmp>:1
------> 3sub f(Int $a?, Str $b?) {}; 7⏏5f('foo')
guifa2 codesections: ^^ It's probably working off of the principal that each optional argument should come in order.
I had worked on a trait a while ago that would try to reorder optional arguments based on their type, but I never finished it because I just went with named arguments ha 20:44
codesections guifa2: do you think it's a _good_ principle for it to work off of? or a buggy one?
I mean, it's not a big deal to make it a multi 20:45
guifa2 codesections: I don't think either mechanism is better than the other — but it's probably much easier to explain that optional arguments can only "match" if the previous optional is fulfilled 20:46
I mean, imagine that we allow one to be skipped
sub f(Int $a?, Int $b?, *@s) {} 20:47
now if I pass in a single Int and a Str, what decides whether it goes in A or B? Logically, we go left to right, and we don't skip.
or perhaps for more confusion, what if I do sub f(Int $a?, Int() $b?, *@s) {}; f(5, '100') 20:48
codesections hmmmm, yeah, that's a good point
maybe it's an opportunity to throw an error or warning, though. If I understand correctly, in sub f(Int $a?, *@a), the ? is totally meaningless 20:50
as in, nothing would match that signature that wouldn't match without the ? 20:51
I guess the same is true of sub f($a?, *@s) too, actually 20:53
guifa2 I'd expect it to match a blank call 20:54
m: sub f(Int $a?, *@s) { say "hi" }; f() 20:55
camelia hi
guifa2 maybe I should go back to my auto-rearranging trait 20:56
codesections oh, hmmm, interesting.
guifa2 I think where I got thrown off was not being able to fully introspect some of the attributes, or maybe it was handling multis, I forget which made me kind of give up. But it should be possible
codesections yeah. Though it'll get even easier with AST macros 20:57
guifa2 another reason for me to put stuff off ;-)
codesections s/AST/RakuAST/
brown121407 I see the Raku mailing lists are still called perl6-*. Are there plans to change them? 21:42
codesections interesting: 21:43
m: my $cap = \:key<val>:another<val2>; say $cap.list; say $cap.hash
camelia (key => val)
Map.new((another => val2))
codesections m: my $cap = \(:key<val>:another<val2>); say $cap.list; say $cap.hash
camelia ()
Map.new((another => val2, key => val))
codesections brown121407: yep. We're working on the logistics still, but it's something we'd like to do 21:44
brown121407 Also, maybe toolchain updates (like rakudo) should be announced on perl6/raku-announce so package maintainers get notifications. If they are announced in another place, please tell me. I see that perl6-announce is quite empty. 21:45
codesections: good to know, thanks!
Hmm, I see rakudo is announced on perl6-compiler 21:46
guifa2 codesections: interesting, so \:foo<bar> forces a named parameter as a positional? 23:08
m: sub foo($a, $b) { say $b }; foo \:a<1>, \:b<2> 23:09
camelia \(:b(IntStr.new(2, "2")))
guifa2 aha!
it does!
codesections Oh, that's nifty. And significantly more elegant than <b> => '2' 23:11
MasterDuke well, it's a Capture of a named param
guifa2 MasterDuke: ah actually you're right. I missed the backslash in front of the parentheses in the output 23:12
codesections oh, I missed that, too 23:15
m: sub foo($a, $b) { say $b }; foo |\:a<1>, |\:b<2> 23:16
camelia b => 2
codesections ^^^^^ works, but I'm not sure quite where it falls on the elegance spectrum 23:17
(A run where 5 of 7 characters are non-alphabetic gets a bit close to line noise, even for my tastes!) 23:18
lizmat m: sub foo($a, $b) { dd $a, $b }; foo (:2a), (:3b) # my preference 23:55
camelia :a(2)
:b(3)
lizmat afk again& 23:56
short night :-)

Powered by Cro and the Raku® Programming Language.

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

Thank you!