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.
00:00 reportable6 left 00:02 reportable6 joined
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
04:19 nativecallable6 left, bisectable6 left, tellable6 left, benchable6 left, squashable6 left, bloatable6 left, coverable6 left, unicodable6 left, sourceable6 left, releasable6 left, shareable6 left, notable6 left, committable6 left, statisfiable6 left, quotable6 left, greppable6 left, linkable6 left, reportable6 left, evalable6 left, benchable6 joined 04:20 committable6 joined, unicodable6 joined, tellable6 joined, evalable6 joined, linkable6 joined, notable6 joined, shareable6 joined, squashable6 joined 04:21 quotable6 joined, bisectable6 joined, greppable6 joined, nativecallable6 joined, statisfiable6 joined, reportable6 joined 04:22 sourceable6 joined, releasable6 joined, coverable6 joined, bloatable6 joined 05:18 squashable6 left 05:21 squashable6 joined
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
06:00 reportable6 left 06:02 reportable6 joined 07:37 sena_kun joined
lizmat and yet another Rakudo Weekly hits the Net: rakudoweekly.blog/2023/08/21/2023-...-exercism/ 11:23
12:00 reportable6 left 12:02 reportable6 joined 13:50 [Coke] left 13:51 [Coke] joined
ugexe Woodi: because rakudo uses stat, and making those uses faster will make the "plain OO" file uses faster 14:30
15:49 evalable6 left, linkable6 left 15:51 evalable6 joined, linkable6 joined 16:01 ab5tract joined 17:00 harrow left 17:02 harrow joined 17:17 harrow left 17:23 harrow joined
gfldex Woodi: Rakudo really likes to stat. You can check how much with: strace -e trace=statx rakudo -e 'say „Hello, Woodi!“' 17:50
18:00 reportable6 left, reportable6 joined
Geth MoarVM/2023.080: 3031458a93 | (Justin DeVuyst)++ | 2 files
Update changelog and version
MoarVM: jdv++ created pull request #1767:
Update changelog and version
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 :)
22:46 sena_kun left 23:21 ab5tract left