00:16 abraxxa-home left
guifa aha 00:19
I can do uv_udp_getsockname(), then read the sin6_scope_id 00:20
Just annoying because i have to convert to an sockaddr, extract the interger, then reformulate into a str 00:25
01:03 MyNetAz left
antononcube .seen lizmat 01:07
01:18 MyNetAz joined
guifa oh fun 02:03
Undefined symbols for architecture arm64: "_uv__idna_toascii", referenced from: _uv_getaddrinfo in libuv.a[18](getaddrinfo.o)
02:04 hulk joined 02:05 kylese left
ugexe We don’t build libuv normally and instead include the files ourselves in a makefile or some such. Often the files (or order of those files) needs to be changed to use features/code paths that weren’t used yet 02:06
guifa that's what I was gathering -- was trying to see where I'd be able to link it in 02:09
is it as simple as adding in `3rdparty/libuv/src/idna@obj@` where I see all of the other similarly named lines? 02:10
answer: it seems so, compile was successful, time to try it out 02:14
whelp, it works, but apparently uv_udp_getsockname doesn't write back to the scope_id 02:50
there has to be an easier way to figure out the ipv6 interface from a bound socket
03:01 hulk left, kylese joined
ugexe have you tried looking at node or julia source code? 03:02
03:03 Aedil joined
ugexe llm might even be able to somewhat correctly guide you on libuv usage 03:04
guifa Yeah I think I'm going to have to do a deep dive on Node, that's so far been the solution to my issues 03:10
03:15 kylese left, kylese joined
guifa From what I can see with Node.js, it looks it's unavoidable to have to effectively manually specify the interface 03:15
At least, not without doing a lot of potentially platform specific hoops to determine the prefered/default interface (seems like it's supposed to be index 0, but on my system, the "default" is at idx 12, with no interfaces at 0, and loopback at 1) 03:20
I guess the easiest for now is on the Raku side to make it be IO::Socket::Async.bind-udp($addr, :multicast($interface)) 03:22
and leave it to module space to figure out the ideal one
Julia doesn't seem to require an interface. Trying to track down their code 04:39
guifa thinks they might be listening on all interfaces, which is certainly one solution
Nope. Both just pass a NULL to lib_uv for the interface. That just clearly doesn't work on macOS :-) 06:44
06:51 gfldex left 07:36 Sgeo left 07:40 MyNetAz left 07:55 MyNetAz joined 08:07 acidsys left 08:30 acidsys joined 09:51 melezhik joined
melezhik Dormitory post has got some UPs (+1 for just few hours) on programming.dev - programming.dev/post/23334003 - please support if you wish ) 09:52
+11 09:53
09:56 melezhik left 09:57 MyNetAz left 10:12 MyNetAz joined 10:15 sena_kun joined 13:15 Aedil left 13:20 Aedil joined
antononcube @guifa What you are trying to find out looking at Julia? How to implement a DNS service? And / or socket library? 13:24
Sorry, I am too lazy to read all of the related discussion above…
guifa antononcube: looking at how they implement IPv6 multicast, because their sample code didn't seem to be too terribly bothered with specifying network interfaces, which the underlying libuv (which Raku also uses) effectively requires 13:25
antononcube I wonder then how Mathematica and R do that. (Same type of languages.) 13:26
guifa github.com/Raku/problem-solving/issues/457 <-- bottom post sums up the current state of affairs
I can create something that works regardless how we want to, but the question is how to wire it up API wise really 13:27
antononcube But, more importantly for me, I can / should hook up a Julia kernel to Jupyter. Also, at some point I experimented using Julia in Raku sessions. 13:28
“bikeshedding” 🙂 13:30
guifa lol maybe Is hould just change it to "Multicast API" or something 13:33
timo oh no, the bike is shedding! 13:35
13:36 tadzik left
antononcube Some of that discussion reminds of designs in ZeroMQ. 13:59
But using ZMQ for inspiration might be too much of a stretch.
timo for the purpose of what guifa is doing, there is a hard limit on the amount of innovation we can do, since it's meant to interoperate with other regular programs that use this kind of multicast 14:01
14:01 tadzik joined
timo we can make the API more convenient to use for as many use cases as possible, but we're tied to the semantics of existing UDP multicast system calls and such 14:03
guifa ZMQ is definitely a bit higher level than what I'm trying to work out 14:16
14:16 sena_kun left
timo and cro has support for ZMQ right? i haven't tried it yet, though. 14:16
14:18 sena_kun joined
guifa I'm happy at least I've figured out the lower level (MoarVM) issues, though. Once I know/decide how the higher-level side should look, I can clean up/adjust MoarVM to follow. 14:18
"figured out" eq "finally groks everything going on under the hood" 14:19
timo .o( boss, we caught another one! )
guifa lol not saying I get MoarVM's internals fully, just enough to handle the socket setup and libuv :) 14:22
timo not long ago i realized i don't thoroughly grok the async event loop thread and "active work" and such
there's still a bug related to doing stuff in a bad sequence that one of our spec tests flaps with that i couldn't really debug to the end 14:24
guifa although seriously, the write up on this is going to be legendary. "So multicast didn't seem to work. Let's try to figure out why. Here's the Rakudo code. And now the NQP, and now the MoarVM. But now to understand the MoarVM, we need to understand libuv. Oh, and study back on up on oddities with IPv6. Let's now compare with NodeJS. Oh, welcome to cross-platform issues. Okay, phew, all that's done. Oh wait, how will we enable all of this from Raku? 14:25
🤦‍♂️"
14:34 Sgeo joined
antononcube @guifa Maybe you should use some of the reasoning LLMs. 18:51
I would say, there is 70% probability they would help.