Voldenet re `my $b; $b[1e18]="meow"` causing panic, I think this is a bug 12:08
lizmat wow 12:09
yeah, please make an issue :-)
Voldenet idk what's the behavior I'd expect from it though - in js browsers behave differently in such case 12:13
lizmat I suggest we don't allow bigInt values for indices 12:24
Voldenet there's a few solutions, v8 uses sparse arrays 12:27
and firefox (spidermonkey, I think) simply ignores that error :> 12:28
lizmat I think we're going to opt to disallowing bigint values for now and throwing an execution error 12:32
m: my @a; @a[my $ = -1e13]="meow" # related meh 12:36
camelia ( no output )
Voldenet hm… it doesn't crash on the newest version?
m: my $b; $b[1e18]="meow"
camelia MoarVM panic: Memory allocation failed; could not allocate 8000000000000000008 bytes
Voldenet Ah, it does.
lizmat m: my @a; @a[-1e0]="meow" 12:37
camelia ( no output )
lizmat m: my @a; @a[-1]="meow"
camelia ===SORRY!=== Error while compiling <tmp>
Unsupported use of a negative -1 subscript to index from the end. In
Raku please use: a function such as *-1.
at <tmp>:1
------> my @a; @a[-1]<HERE>="meow"
lizmat meh
Voldenet Having "oom" to catch here would be a solution, but I'm not sure if it'd be actually useful 12:40
I've seen developers doing this in other languages, and obviously handling OOM didn't really add more ram properly :>
in perl5, `eval { @b[1e15]=1; }` doesn't seem to be handled, but `eval { @b[1e20]=1; }` is handled 12:44
ah, right the second one is not OOM and that is properly handled by raku too 12:45
> github.com/rakudo/rakudo/issues/5835 12:48
stanrifkin_ Not $b[1e15]?
Voldenet uh, right, I mean $b[1e15]
lizmat m: my @a; @a[my $ = -1]="meow"; dd @a # this feels very wrong 12:51
camelia []
Voldenet either way, checks for "arrays can be at most N bytes in size" would be probably better sanity check
but if someone with 2EB of ram uses large arrays, they should work ;) 12:52
m: my @a; my $n = -10e17; @a[$n]="meow"; dd @a 12:54
camelia []
Voldenet I'm suspecting this code quietly does nothing instead of writing to arbitrary locations, otherwise it'd segfault 12:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!