|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
01:41
lizmat_ joined
01:45
lizmat left
04:48
MasterDuke left
07:32
lizmat_ left,
lizmat joined
|
|||
| nine | It's not even just MVMRegister and CPU registers. Even for object attributes, using less than 64 bits often won't save any memory at all due to alignment requirements, i.e. a 64 bit value (like our normal ints or pointers) should only be stored at an address that's a multiple of 8 | 09:49 | |
| lizmat | there are several data structures in MoarVM that are aligned on 4 byte boundaries | 09:59 | |
| perhaps we should align them on 8-byte as well ? | 10:00 | ||
|
10:19
sena_kun joined
|
|||
| ab5tract | Regarding my MR: I could shave two shorts off the (new) size of MVMIOFileData by storing the simplified mode flag directly and then exposing three helper functions for checking the modes. Would this be preferable? | 10:48 | |
| Or even a single helper function, if we don’t mind some magic numbers in the syscall definitions | 10:49 | ||
| lizmat | magic numbers are ok if they are also nqp::const:: constants, at least in my book | 10:58 | |
| ab5tract | okay, I think it's in pretty fine shape now. feedback much appreciated | 15:00 | |
|
15:42
Geth left,
Geth joined
|
|||
| lizmat | not sure why this wasn't announced here: sadly I cannot re-annouce MoarVM pushes :-( | 15:43 | |
| ab5tract | lizmat: probably because it's in my clone of the repo. ENOBIT | 15:52 | |
| lizmat | ah, I see *phew* So I kicked Geth without it needing to be kicked. Sorry, Geth | 15:53 | |
| lizmat gives Geth a pat on the back | |||
| lizmat can do that since Geth lives on her desk :-) | 15:54 | ||
| ab5tract | :) | ||
| ab5tract feeds Geth M#1803 | |||
| linkable6 | M#1803 [open]: github.com/MoarVM/MoarVM/pull/1803 Provide some mechanisms for introspecting file mode | ||
| ab5tract | ah, well linkable looked hungry too ;) | 15:55 | |
| lizmat | src/io/syncfile.c:487:15: error: no member named 'open_mode_simpl' in 'MVMIOFileData'; did you mean 'open_mode_simple'? | ||
| data->open_mode_simpl = simple_flag; | |||
| ^~~~~~~~~~~~~~~ | |||
| ab5tract | huh, that's really weird. I fixed that locally | ||
| lizmat | actually: src/io/syncfile.c:486:1: error: version control conflict marker in file | ||
| ab5tract | ahh, some cherry-pick merge gunk | 15:56 | |
| sorry about that :( | |||
| lizmat | CI for the win! | ||
| ab5tract | love that stuff | 16:00 | |
| should be un-borked now | |||
| nine | lizmat: do you mean in the bytecode files? | 17:07 | |
| lizmat | possibly? but yeah, you're right, I shouldn't equate bytecode format with in-memory layout, right? | 17:10 | |
| otoh, why do we align on 2/4 byte boundaries in the bytecode format? to allow for easier reading, right ? | 17:11 | ||
|
18:53
sena_kun left
19:11
sena_kun joined
22:34
sena_kun left
|
|||