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.
MasterDuke huh. we don't have a function to copy an MVMString? 01:07
guess i have to go via REPR->copy_to() 01:09
oh, or MVM_repr_clone() 01:14
maybe i'm making this more complicated than it needs to be 01:15
on windows, the moarvm implementation of nqp::isexecutable needs to know the filename. the stat-related syscalls i've been adding don't have/know the filename 01:16
so i was going to add an `MVMString *filename` field to the new MVMStat repr (surrounded by `#ifdef _WIN32`, so linux/mac don't pay the cost) 01:17
but i was thinking that the MVMStat repr should have a copy of the string, so it can safely free it. and then when an MVMStat is copied, it should also copy the filename. but in copy_to, i have the two body structs, not the object header structs 01:21
so i can't just call MVM_repr_clone() 01:22
any thoughts/suggestions?
afk for a bit, but should be back a little later this evening 01:23
maybe i'll just not copy, and assume gc will keep everything safe 02:07
Woodi MasterDuke:but why stat stuff is not just another module ? plain OO is not enough ? files are just another problem domain external to interpreter/compiler... 05:28
lizmat and yet another Rakudo Weekly hits the Net: rakudoweekly.blog/2023/08/21/2023-...-exercism/ 11:23
ugexe Woodi: because rakudo uses stat, and making those uses faster will make the "plain OO" file uses faster 14:30
gfldex Woodi: Rakudo really likes to stat. You can check how much with: strace -e trace=statx rakudo -e 'say „Hello, Woodi!“' 17:50
Geth MoarVM/2023.080: 3031458a93 | (Justin DeVuyst)++ | 2 files
Update changelog and version
18:08
MoarVM: jdv++ created pull request #1767:
Update changelog and version
18:20
MoarVM/main: 3031458a93 | (Justin DeVuyst)++ | 2 files
Update changelog and version
MoarVM/main: a2da8e7b17 | (Justin DeVuyst)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1767 from MoarVM/2023.080

Update changelog and version
jdv this release done, back to the other... 18:32
Woodi for sure I like fast :) and MasterDuke++ actually doing stuff is excellent. also modularity in code is good. but something with reps looks off, to me. a) looks like src/6model/reprs is where datatypes of all kinds are defined 18:59
eg. MVMString.h defines 5 possible representations of string :) and that is classic representations usage. but eg. MVMThread have just one to my eye. and if it is only one then "representation" is just wrapper and possible slowdown 19:06
back to stat - repr is to me "noun" and stat is more for do checking so more "verb". struct stat is noun but it is such small functionality so representation for this is strange 19:09
MVMFile maybe ? then much more thing can be put there 19:11
there already is MVMOSHandle but probably it is a file descriptor 19:13
but P6String is just MVMString and nothing else so representation of representation... 19:14
and threads, frames, references looks very internal, another subsystem ? 19:15
maybe splitting hair but do not see that yet... 19:16
b) looks like reprs are kind of internal modules ? 19:18
btw. what if MVMFile or handle be a) file on disk b) mmapped file c) in-memory file ? with c) temp files would be fast :) 19:20
or maybe stat repr need to be thinked as stat via syscal and via uv ? so another kind of difference. anyway good to have native ops 19:24
night :)