|
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 |
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 :) | |||
|
22:46
sena_kun left
23:21
ab5tract left
|
|||