🦋 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.
antononcube @El_Che 🙂 🙂 🙂 00:37
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
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;
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]
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
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…
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
(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
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
goes away to have a think 13:00
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
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
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
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
lizmat Voldenet librasteve gfldex github.com/rakudo/rakudo/pull/5526 18:53
[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
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
[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
librasteve jdv: the surface area is very large ... attrition == darwinism ;-) 22:30
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?
[Coke] is that just a new version of Term::? 23:13
tbrowder__: ... he's not here anymore. 23:14
thundergnat Newer and more capabilities 23:21

Powered by Cro and the Raku® Programming Language.

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

Thank you!