Geth MoarVM/main: c1d1f60e71 | (Daniel Green)++ | 3 files
Fix format specifiers clang on OSX complains about
 00:36
MoarVM/main: f4680765ff | MasterDuke17++ (committed using GitHub Web editor) | 3 files
Merge pull request #1876 from MasterDuke17/fix_printf_format_specifiers_clang_on_osx_complains_about

Fix format specifiers clang on OSX complains about
02:08 guifa joined
guifa so my journey on multicast has brought me to the innards of MoarVM. I'm going to try to cobble together something that works -- seems to be *fairly* straightforward 02:10
whoa I think I got it 04:39
it's kind of cludged together and ugly, but it works
Would it be best for me to submit a PR as is, get feedback, and adjust the code per feedback or ? 04:57
ab5tract guifa: seems like a reasonable approach to me 05:04
guifa ab5tract typing it up now and will submit as a draft pull request (forgot that those were a thing) 05:05
Geth MoarVM: alabamenhu++ created pull request #1878:
Preliminary multicast support		 05:14
09:14 sena_kun joined 09:32 sena_kun left 18:49 sena_kun joined 22:33 sena_kun left
guifa What is the best way to convert an MVMString to a char*? 22:52
timo you have to encode it 22:53
there's one function that gives you a null byte terminated utf8 string, and there's utf8-c8 which can be useful 22:54
it depends very much on your use case?
guifa So bind-udp(...) takes a string value for the hostname (IP address or e.g. 'localhost' etc)
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!