🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:16 jpn joined 00:31 jpn left
antononcube @El_Che 🙂 🙂 🙂 00:37
01:10 jpn joined 01:15 jpn left 01:52 MasterDuke joined 02:20 jpn joined 02:39 jpn left 02:44 kylese left 02:45 kylese joined 03:05 jgaz left 03:15 kylese left, jpn joined, kylese joined 03:32 chemist joined
chemist I am getting an issue with uint64 not properly wrapping around 0 with the 2024/01 Rakudo release. It does not appear to affect uint32: 03:36
03:40 chemist left, chemistz joined 03:43 chemistz left 03:44 chemistz joined 03:47 chemitz joined, chemistz left
chemitz my uint32 $x; 03:47
my uint64 $y;
$x = $x - 1;
$y = $y - 1;
say $x; # correct
say $y; # correct
$x = $x + 1;
# $y = $y + 1; # this shows error "Cannot unbox 65 bit wide bigint into native integer" but it should wrap
say $x; # correct
# say $y;
03:58 MasterDuke left 04:53 jpn left 05:50 [Coke] left 05:53 [Coke] joined 06:28 human-blip left 06:45 dustinm` left 06:51 dustinm` joined 07:22 human-blip joined 08:12 Sgeo left 08:25 vlad joined 08:55 [Coke] left 08:58 [Coke] joined 08:59 epony joined 09:12 dakkar joined
gfldex m: my uint32 $x; my uint64 $y; say [$x.WHAT, $y.WHAT]; $x = $x - 1; $y = $y - 1; say [$x.WHAT, $y.WHAT]; say [$x, $y]; $x = $x - 1; $y = $y + 1; 09:19
camelia [(Int) (Int)]
Cannot unbox 65 bit wide bigint into native integer
in block <unit> at <tmp> line 1

[(Int) (Int)]
[4294967295 18446744073709551615]
09:25 epony left, epony joined 09:32 vlad left
gfldex chemitz: might be the same as: github.com/rakudo/rakudo/issues/5349 09:36
m: my uint64 $y; $y = $y - 1; say ++$y; 09:39
camelia 0
gfldex chemitz: I agree with the comment in the issue. In Raku `1` is not a native int. And we upgrade to a "bigger"-type when needed automatically. IHMO, the error-message is LTA. 09:40
Voldenet a bit of ridiculousness 09:50
m: my uint64 $y; $y = $y - 1; $y = $y + 1; say $y
camelia Cannot unbox 65 bit wide bigint into native integer
in block <unit> at <tmp> line 1
Voldenet m: my uint64 $one = 1; my uint64 $y; $y = $y - $one; $y = $y + $one; say $y 09:51
camelia 0
lizmat yeah, that's basically the issue: the literal 1 is currently not a native int 09:53
Voldenet I wonder, is there some api for casting things to uint64? I think nativecast could do that 09:55
09:58 sena_kun joined
Voldenet something like `1.uint64` could work 09:59
m: my uint64 $one = 1.uint64; my uint64 $y; $y = $y - $one; $y = $y + $one; say $y
camelia No such method 'uint64' for invocant of type 'Int'. Did you mean
'UInt'?
in block <unit> at <tmp> line 1
lizmat Voldenet: I think the appropriate fix would be to change the QAST step for RakuAST::IntLiteral 10:03
perhaps a problem solving issue about whether literal ints should be native or not, would be a good start for a discussion 10:04
gfldex m: my uint64() \one = 1; my uint64 $y; $y = $y - 1; $y = $y + one; 10:06
camelia Cannot unbox 65 bit wide bigint into native integer
in block <unit> at <tmp> line 1
gfldex I'm not happy with that one.
Voldenet but then integers I'd usually use in my code, like `340282366920938463463374607431768211456` wouldn't work 10:07
lizmat Voldenet: only if they fit, of course :-) 10:08
github.com/Raku/nqp/blob/master/do...down#isbig 10:09
Voldenet Ofc, I prefer the solution of this particular problem with using native integers 10:10
but explicitly setting the cast would fit into all those .Int .Num casts
and let people do things like `my $x = 42.int32` 10:11
lizmat not saying that shouldn't be possible too :-) 10:13
Voldenet m: my uint64 $y = nativecast(uint32, 1); 10:22
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
nativecast used at line 1
Voldenet m: use NativeCall; my uint64 $y = nativecast(uint32, 1); 10:23
camelia Native call cast expected return type with CPointer, CStruct, CArray, or VMArray representation, but got a P6opaque (Int)
in sub nativecast at /home/camelia/rakudo-m-inst-2/share/perl6/core/sources/C47EB52A2207A2AFF663A5292D3B13B5E3BA3269 (NativeC…
10:28 jpn joined 10:46 jpn left 10:50 jpn joined 11:35 derpydoo left
librasteve m: my UInt() $x = 1; say $x.^name; dd $x; 12:19
evalable6 Int
UInt(Any) $x = 1
Raku eval Int Int $x = 1
librasteve I am in Discord, I now see Raku bridge say OUTPUT: «Int␤UInt(Any) $x = 1␤» and Raku eval say «Int␤Int $x = 1␤» 12:21
m: my $x = 1; say $x.^name; dd $x; 12:22
evalable6 Int
Mu $x = 1
Raku eval Int Int $x = 1
librasteve I guess we have upgraded the evalable6 bot to run twice (on both Discord and IRC sides) --- personally I prefer it to have just one result shown --- and not sure why one agrees with my repl and one is different! 12:23
Voldenet, I agree that casting literals would be a good solution. I'd like to keep native types a specialist area, so would be against a change that all literals be native types. 12:32
m: say 1 ~~ Int;
evalable6 True
Raku eval True
librasteve m: say 1 ~~ unit64; 12:33
evalable6 (exit code 1) 4===SORRY!4=== Error while compiling /tmp/d6vx4XtirB
Undeclared routine:
unit64 used at line 1
Raku eval Exit code: 1 ===SORRY!=== Error while compiling /home/glot/main.raku Undeclared routine: unit64 used at line 1
librasteve m: say 1 ~~ int;
evalable6 False
Raku eval False
lizmat m: say my int $a = 42 ~~ Int
camelia 1
lizmat oddly enough not a Bool
but this implies that if literal 1 would be an int, it would still typematch with Int 12:34
librasteve yes - that's my objection 12:36
I think 1 ~~ Int should be True 12:37
and 1 ~~ int should be False
lizmat why ? 12:38
librasteve consider this
m: sub fn(Int $x){say 'ok'}; my $x = 1; fn($x); 12:39
evalable6 ok
Raku eval ok
librasteve vs this 12:40
sub fn(int $x){say 'ok'}; my $x = 1; fn($x);
evalable6 ok
lizmat you're saying the latter shouldn't work ? 12:41
librasteve errr - I am surprised that the latter works
lizmat it's different with multis 12:42
cokebot9000 huh
lizmat then the 1 would favour the Int candidate
with the proposed change, it would favour the int candidate
librasteve I just assumed that ~~ int would let you weed out native types 12:43
so I think that the multis are right and that there should be a bias to vanilla untyped raku having Int all round 12:44
cokebot9000 /me, having had a power. outage last night, sees a benefit to using discord instead of IRC. 12:45
librasteve I am curious what is going on in my latter example - I guess that Ints are generally coerced to / interpreted as ints ... not sure of the rationale for that?
if you want to descend to native types, then there should be some reasonable incantation, but OK if that is a specialist subject 12:47
12:48 derpydoo joined
(which is what I think Voldenet's literal cast proposal 1.uint64 achieves) 12:48
lizmat I guess part of the story is that historically native ints in Rakudo got implemented *after* Int was implemented
12:52 jpn left 12:56 jpn joined
librasteve m: say int ~~ Int 12:56
evalable6 True
Raku eval True
librasteve Int ACCEPTS int ... good 12:57
m: say Int ~~ int
Raku eval False
evalable6 False
librasteve int doesn't ACCEPT Int ... okay
12:59 clarkema left, clarkema_ is now known as clarkema
goes away to have a think 13:00
13:03 jpn left
so I expect to be able to use sub(int $x) to reject Int s ... but that only works in multis ... that feels like a bad surprise to me 13:04
lizmat m: sub a(uint8 $a) {dd $a }; a 255 13:08
camelia 255
lizmat m: sub a(uint8 $a) {dd $a }; a 256
camelia 0
lizmat m: multi sub a(uint8 $a) {dd $a }; a 255
camelia ===SORRY!=== Error while compiling <tmp>
Calling a(Int) will never work with any of these multi signatures:
(uint8 $a)
at <tmp>:1
------> multi sub a(uint8 $a) {dd $a }; ⏏a 255
lizmat now, with 255 becoming a native uint (I guess) that would work 13:09
however, it would only select the candidate on an exact type match at the moment: 13:11
m: multi sub a(uint8 $) {dd }; multi sub a(Int $) { dd }; a my int64 $ = 255
camelia sub a(Int)
lizmat m: multi sub a(uint8 $) {dd }; multi sub a(Int $) { dd }; a my uint64 $ = 255
camelia sub a(uint8)
lizmat afk& 13:12
13:18 jpn joined 13:55 jgaz joined 14:14 [Coke] left 14:19 [Coke] joined
Voldenet > m: sub a(uint8 $a) {dd $a }; a 256 14:49
I'd totally expect an error here
btw, that 1.uint64 could become `1.COERCE(uint64)/nativecast(uint64, 1)/1 (cast) uint64/1 🪄 uint4` 14:54
second part is something that could probably be implemented by MVM_nativecall_cast, since the error comes from moarvm 14:56
15:27 vlad joined
librasteve Voldenet: ++ I agree sub a(uint8 $a) {dd $a }; a 256 should error, this is a more glaring example of sub a(int $a) {dd $a }; a 256that I showed above 15:42
m: say 256 ~~ uint8 15:43
evalable6 False
Raku eval False
librasteve so the sub Signature maches, yet the smartmatch does not 15:44
this is the rude surprise that I think is wrong
Voldenet it's only a result of 256 not being native 15:45
15:46 vlad_ joined
librasteve another good part of the 1.uint64 literal cast solution you propose is that you do not have to decide that 1 is a uint8, -1 is an int8, 255 is a uint8, 256 is a uint32 and so on 15:46
(ie the compiler does not have to decide this, the user has this explicit control) 15:47
I think the smartmatch is correct (since 256 is non native), my objection is that the sub Signature does a different thing 15:48
15:49 vlad left 15:54 xsen joined 15:58 xsen left 16:45 vlad_ left 16:48 nebuchadnezzar left 16:56 vlad_ joined 16:58 jpn left 17:29 dakkar left 17:58 vlad__ joined 18:01 vlad_ left 18:25 epony left, epony joined
lizmat Voldenet librasteve gfldex github.com/rakudo/rakudo/pull/5526 18:53
19:33 [Coke]_ joined 19:34 vlad_ joined 19:35 [Coke] left 19:37 [Coke]_ is now known as [Coke], vlad__ left
[Coke] wants a module that gives powershell-like prompting for inputs/responses. 19:45
"here's a list of all the possible values, the basic prompt, generate something that can take partial input and return the canonical answer"
antononcube @Coke It seems you are requesting / looking for a notebook solution. 20:00
@Coke I actually, googles "powershell" -- do you mean something that emulates / mimics that MicroSoft program? 20:01
@Coke I showing something like that functionality here: www.youtube.com/watch?v=3OUkSa-5vEk&t=2694s 20:15
But, the selection reaction in my data acquisition project is much more specialized. (I.e. not universal.) 20:16
[Coke] No, I don't want a notebook solution 20:35
in this case, just the style of text prompts that powershell does. Will probably whip up a prototype today
[Y] Yes [N] No [?] Help (default is "N"): 20:37
How to declare a sub takes an array where all elements are of type F? sub($a, $b, F @c) complains that I want Positional[F] but gave it Array([F.new...]) 21:02
ah, nevermind
(declared types require a declaration on the one passed in, also, not just the sig) 21:03
21:04 jpn joined 21:11 El_Che_ is now known as El_Che 21:13 jpn left 21:14 sftp left
tbrowder__ what is the status of File::Temp by 2colours,? it needs updating. can we fix it and reissuse it, or will he respond to PRs? (note he has never addressed an existing issue, nor has he fixed the current test failure) 21:18
21:19 sftp joined
[Coke] Anyone know how to make readchars work with a single char? $*IN.readchars(1) does not return after a single char. 21:38
maybe japhb? 21:39
same with .getc, which at least mentions you should set your handle to unbuffered. 21:43
(but only buffering methods are for output buffering) 21:44
Term::ReadKey 21:50
.. except that doesn't work either, shame. 21:54
.seen jkramer
tellable6 [Coke], I saw jkramer 2019-07-17T13:26:49Z in #perl6: <jkramer> Does grep with race not smartmatch?
jdv so much attrition:( 21:56
[Coke] github.com/jkramer/p6-Term-ReadKey/issues/6 21:59
Maybe someone not a mac could test that. 22:00
22:15 jpn joined 22:20 jpn left
librasteve jdv: the surface area is very large ... attrition == darwinism ;-) 22:30
22:30 sena_kun left 22:36 epony left 22:48 MasterDuke joined 22:49 thundergnat joined
thundergnat [Coke]: Would Terminal::ReadKey work for you? raku.land/zef:thundergnat/Terminal::ReadKey 22:54
raku -MTerminal::ReadKey -e 'react { whenever key-pressed() { .&dd } }' 22:55
tbrowder__ .seen 2colours 22:57
tellable6 tbrowder__, I haven't seen 2colours around, did you mean orylesor?
23:01 vlad__ joined 23:04 vlad_ left 23:05 vlad__ left 23:09 jpn joined
[Coke] is that just a new version of Term::? 23:13
tbrowder__: ... he's not here anymore. 23:14
23:14 jpn left
thundergnat Newer and more capabilities 23:21
23:21 thundergnat left 23:26 teatime joined 23:35 MasterDuke left, derpydoo left 23:47 jpn joined 23:52 jpn left 23:55 Sgeo joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!