| 28 Mar 2025 | |||
| Voldenet | :) | 18:35 | |
| sdomi | ugexe: unbuffer is a silly hack, raku should be able to set the buffer settings by itself | 18:40 | |
| reading the SO post... gahhh this will be painful | 18:41 | ||
| okay, it seems that the answer below suggesting `$*OUT.out-buffer` to 0 did exactly what I wanted | 18:43 | ||
| what is the raku equivalent of the python/bash/(C..?) ~ operator? (sign negation) | 19:22 | ||
| oh, +^. god that was hard to find | 19:24 | ||
| Voldenet | useful page docs.raku.org/language/operators | 19:58 | |
| sdomi | i've been there and struggled to find it regardless | ||
| ^F not -> 150 matches | |||
| Voldenet | "negation" | 20:01 | |
| stanrifkin | sdomi: "sign negation"? | ||
| sdomi | welp, my bad | 20:02 | |
| stanrifkin | sdomi: ah, seeing it now. | ||
| Voldenet | I've tried to use chatgpt for that question, and it was beautifully wrong | ||
| > say ~$x; # Output: -6 (binary: 1010 -> negation of 101 in 2's complement) | |||
| ā(Ā“ļ½`ļ¼)ā | |||
| sdomi | if i wanted to see hallucinations i'd seek drugs, i don't need a chatbot for that | 20:03 | |
| atrocious. | |||
| Voldenet | however, deepseek was right | ||
| 29 Mar 2025 | |||
| 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 | |
| sdomi | Voldenet: sent the issue :) | 16:54 | |