| 9 Nov 2025 | |||
| timo | m: my int @foo[90]; say @foo.WHAT | 19:09 | |
| camelia | (array[int]) | ||
| Voldenet | Ah, right, and in that case it has fixed length | 19:11 | |
| timo | indeed | 19:12 | |
| and can't have a reifier | |||
| or todo | |||
| Voldenet | so it'd only need additional elements count, and the max size would be defined by that native array's length | 19:14 | |
| in which case it'd have to somehow deoptimize the storage for the array and potentially all the things in the stack | |||
| librasteve | in that example, what prevents me writing eg my $hack = @foo[92] ? (just curious onlooker) | 19:15 | |
| timo | m: my int @foo[90]; say @foo[92]; | ||
| camelia | Index 92 for dimension 1 out of range (must be 0..89) in block <unit> at <tmp> line 1 |
||
| Voldenet | the contract for usage of optimized array | 19:16 | |
| librasteve | yeah - but that's runtime error ... oh so the access is not a pure pointer | ||
| Voldenet | Yes, but before accessing it, runtime could quietly deoptimize everything first | 19:17 | |
| e.g. allocate every single object on a heap needed, with pointers etc. | |||
| librasteve | ie the code that runs on Postional AT-KEY checks the length somewhere (not actually in the storage) | ||
| i thought that declared shape was immutable ...? | 19:18 | ||
| timo | i was wondering if the shape was actually on the type as a parameter, but it looks like it's on the instance and only the number of dimensions the shape has is part of the type | ||
| Voldenet | Right, so the runnig code would need the current count, allocated count and pointer for data (pointing on stack by default) | 19:19 | |
| timo | shaped arrays are always fully allocated | ||
| Voldenet | but they could get stack-optimized (similar to the classes) for cases with not many small elements | 19:20 | |
| librasteve | tx | 19:21 | |
| timo | fwiw, moarvm doesn't use the C stack, so even allocating a 1000 or 10000 element array "stored on the stack" will not run into "traditional" stack size limits | ||
| Voldenet | yes, but having large stacks would ruin the cpu caches | 19:22 | |
| timo | we still use the C stack inside of moarvm for all the C code, of course | 19:23 | |
| but in moarvm the depth of the stack is unrelated to the depth of the raku-level call stack | 19:24 | ||
| and it tends to always come back to just roughly 4 stack frames deep | |||
| Voldenet | as a matter of fact, data doesn't even have to use the same stack | 19:25 | |
| timo | you're aluding to having a stack for just return addresses? | ||
| Voldenet | for the whole "data" portion of the code | 19:26 | |
| timo | what's the "data portion"? | ||
| Voldenet | variables and arguments, this prevents mixing return addresses with actual values | 19:27 | |
| but I am not really confident in this being a good idea | 19:28 | ||
| timo | moar's help-allocated stack frames kind of store the return address, or rather the pointer to the caller frame and the return address inside its bytecode or the index of the jit label, in a different kind of slot than all the register and lexical values that make up the stack frame | 19:29 | |
| Voldenet | Ah, so the risk of VLA introducing bugs in return addresses is low | 19:32 | |
| timo | they are still nearby though | ||
| not a completely different memory area | |||
| Voldenet | of course the most sane approach would be not allowing VLAs into optimized structures at all | 19:36 | |
| SmokeMachine | librasteve_: I tried, but I’m not sure it went well… :( usercontent.irccloud-cdn.com/file/...716964.JPG | ||
| timo | in any case, all the accesses to registers that a frame of moar bytecode could do are verified ahead of time by the bytecode validator. a bug can still cause access outside of the array of register values though | 19:38 | |
| Voldenet | thing similar to `class VLA-of-T-of_2 { has int $.elems; has T $.item1; has T $.item2; }` could work as well, but it feels like it wouldn't be as optimizable | 19:42 | |
| because it'd need AT-KEY that would point at the right item | 19:43 | ||
| and it'd require defining the in-memory storage for cached lookups, then dispatching right lookup etc. | 19:46 | ||
| antononcube | I think name of operator ==> was changed from "forward feed" to "right feed" -- is that a recent change? | 19:48 | |
| Hmm... the documentation calls it just "feed" : docs.raku.org/language/operators#infix_==%3E | 19:50 | ||
| Voldenet | there's leftward feed and feed | 20:02 | |
| antononcube | Ok. And "forward feed" and "rightward feed" are synonyms of "feed" or not? | 20:06 | |
| Voldenet | rightward would make sense because of symmetry, I remember forward being used somewhere too | 20:16 | |
| as ==> | 20:17 | ||
| librasteve | weekly: usercontent.irccloud-cdn.com/file/...716964.JPG | 21:11 | |
| notable6 | librasteve, Noted! (weekly) | ||
| librasteve | SmokeMachone | ||
| ... looks good to me - many thanks! | |||
