| 18 Dec 2024 | |||
| guifa | So bind-udp(...) takes a string value for the hostname (IP address or e.g. 'localhost' etc) | 22:54 | |
| timo | we have other places where we handle addresses right? | 22:55 | |
| guifa | Yeah, it's probably done somewhere else. I'm doing lots of digging around ha. This was more of a "here's hoping someone knows how offhand to avoid an 30-60min of digging" type question :) | 22:56 | |
| aha | 22:58 | ||
| MVM_string_utf8_encode_C_string | |||
| timo | the API you offer via syscall or nqp:: op could also just take a buf8 and then the decision how to encode it is done in nqp or raku code | 22:59 | |
| for the possibly unusual case where you need to have a hostname or ip address that is for some reason invalid utf8? | |||
| what if on windows you have to pass a wide string? i have no idea ... | |||
| guifa | so basically there's a function A that handles resolving the hostname/port into an special struct, and then calls function B. It makes more sense for me to do my edits in function B, but I need access to the hostname/port there | 23:01 | |
| there's some lib_uv functions that are not as pretty that I can use but it makes more sense to pass the MVMString to function B, do resolution there, and just do the quick MVMStr to C string conversion there | 23:03 | ||
| but this is my first time working with MoarVM code so major n00b alert | |||
| timo | it should be fine to just cook up a prototype with the utf8_encode_c_string function and when it's working change the API if it's needed | 23:10 | |
| guifa | Yeah -- maybe I'm being a bit too perfectionist. the "easy" way out will be to add two members to the SSI struct (current a a bind_addr and flags, would become bind_addr, host, port, flags, and I could combine port and flags no problem in the same space as the flag since port is 16 bit and flags are 2 bit, but flag is 64bit in the struct). it's definitely not the hottest bit of code out there | 23:15 | |
| guifa also can't see an easy way to copy a MVMString so doing that with a char* is also easier ha | 23:16 | ||
| timo | you don't copy MVMString, they are immutable | 23:20 | |
| guifa | is it safe to pass them around? | ||
| timo | yes, with the usual caveat that being a GC-managed object, any place where you call something that allocates, even indirectly, the variable with the pointer has to be MVMROOTed if you want to use it again after | 23:21 | |
| guifa | okay so I've seen the MVMROOT2/MVMROOT3 stuff | 23:22 | |
| So for instance here github.com/MoarVM/MoarVM/blob/f468...udp.c#L581 | 23:25 | ||
| The MVM_io_resolve_host_name() handles allocation, but because the allocation happens within that MVMROOT3 thing, it's safe to use ? | 23:27 | ||
| timo | the MVMROOT macros protect the variables that you pass in | 23:31 | |
| guifa | what's the difference between MVMROOT2 and MVMROOT3 (and assuming there's a 1 also) | 23:32 | |
| timo | it also indicates, though it's not a guarantee, that the functions called inside the body can allocate (and therefore do a GC run) and that also means that the function you're in needs to be called with rooting itself | ||
| only the number of arguments it takes | |||
| variadic macros are apparently not entirely a thing? | |||
| MVMROOT1 is simply MVMROOT | 23:37 | ||
| guifa | ah ok. i'll mirror the level that i see in the block I'm editing | 23:38 | |
| timo | the precise explanation is that when the GC runs, it needs to know every pointer to GC-managed objects both for finding objects that have to be considered alive and also for updating the pointers because the objects move around | 23:39 | |
| and that's what MVMROOT does, it adds a "temporary root" that acts like a stack, so at the open curly it pushes and at the closing curly it pops | 23:40 | ||
| and if the GC run happens while a local variable in a C function on the C stack is in a temporary root, it will be updated while the GC does its thing | |||
| and if you forget it, you'll be working with a copy of the object that used to be there, but it's conceptually been freed, so you have essentially a "use after free" bug if you forget to do that | 23:41 | ||
| i've got to head to bed soon, so if you have some more questions you can ask them quickly and i'll still be able to explain some stuff | 23:43 | ||
| guifa | I think that's more than enough for me to handle improving my PR | 23:46 | |
| at least to make it good enough for someone to do a review of it | |||
| guifa has added in multicast support, all because I wanted to do add in Zeroconf support in Raku lol | |||
| timo | well, implementing things to scratch an itch you have is a time-honoured tradition | 23:47 | |
| guifa | yeah. I just didn't think how far down the rabbit hole I'd have to go :-) | 23:49 | |
| timo | yup, rabbit holes all the way down until you finally reach elephants and, eventually, turtles | 23:58 | |
| 19 Dec 2024 | |||
| guifa | actually | 00:00 | |
| quicky | |||
| if I alloc something in a MVMROOT | 00:01 | ||
| is it "safe" to arbitrarily free it elsewhere to replace with a new value? | |||
| I have another way around but trying to avoid handling flags in two different places | 00:02 | ||
| Alright, updated the PR... .looks much better now | 06:09 | ||
| timo | ok, so with gc-managed references you don't need to do anything in order to free something except null out, or to change the reference to something else that's vlid | 08:57 | |
| valid* | |||
| Geth | MoarVM/line_coverage_improvements: 8ca24c4040 | (Timo Paulssen)++ | 2 files make line coverage better don't repeatedly encode the same filename to char* don't output the exact same line twice, even in non-dedupe mode |
18:38 | |
| guifa | nine: thanks for that edit. Shows you I'm too used to Raku's type objects haha | 23:38 | |