guifa | is it just me or is nqp::closefh only defined for JS? | 03:47 | |
bartolin | for MoarVM it should be github.com/MoarVM/MoarVM/blob/f468...ile.c#L259 and for the JVM github.com/Raku/nqp/blob/fda688110....java#L803 (and the different methods in src/vm/jvm/runtime/org/raku/nqp/io/). | 06:13 | |
timo | well, the closefh you linked to on moarvm is only for syncfile, a handle will have a few structs with "ops", in other words function pointers | 09:09 | |
github.com/MoarVM/MoarVM/blob/f468...o/io.c#L28 this is one step closer to nqp::closefh | 09:10 | ||
github.com/MoarVM/MoarVM/blob/f468...rp.c#L3398 this is where the close_fh opcode turns into a call to that function | 09:11 | ||
github.com/Raku/nqp/blob/main/src/....nqp#L3353 this is where closefh turns into close_fh | 09:12 | ||
09:50
[Coke] left
10:19
sena_kun joined
11:45
[Tux] left
11:48
[Tux] joined
11:49
[Coke] joined
|
|||
guifa | Ah okay. I was trying to track down why close_socket and close_perform didn't seem to be called in MoarVM, so went walking back from Rakudo and it just called the nqp::closefh, and couldn't see where that was defined | 12:40 | |
What's the best error type to throw if something is called with incompatible options? I feel like there's some other examples out there, but the only one I can find is Timezone clash but it throws a very specific error | 12:51 | ||
guifa is modifying bind-udp to include a :multicast option, which is incompatible with :broadcast (can use one or the other, but both doesn't make sense) | 12:55 | ||
timo | hm, there's something for adverbs at least, but broadcast and multicast are not obviously adverbs right? | 12:57 | |
m: CATCH { dd $_; dd $! }; my @a; @a[5]:exists:kv:p | |||
camelia | ( no output ) | ||
timo | hm, not like that apparently | ||
m: CATCH { dd $_; dd $! }; my @a; say @a[5]:exists:kv:p | 12:58 | ||
camelia | X::Adverb.new(what => "element access", source => "\@a", unexpected => [], nogo => ["exists", "kv", "p"]) $! = Nil Unsupported combination of adverbs ('exists', 'kv', 'p') passed to element access on '@a'. in block <unit> at <tmp> line 1 |
||
guifa | Eh sort of? [insert named args v adverb discusssion] | 13:01 | |
timo | it kind of fits with "no candidate matched" | 13:02 | |
but there's the "methods always take any named argument" thing to consider as well | 13:03 | ||
i guess it'd be an ambiguous dispatch then though | |||
maybe it really wants to be a cast => "uni" | "broad" | "multi" :D | 13:04 | ||
guifa | Right. At the moment, the combination of :multicast and :broadcast will generate a flag with a value of 3, which in my MoarVM modifications will ultimately throw an invalid args UV_EINVAL. But I'd rather catch that higher up in Raku to provide an better error message | 13:05 | |
timo | yes | ||
guifa | timo: honestly, :type<unicast> as default and allowing :type<broadcast>and :type<multicast> wouldn't be a bad thing | 13:06 | |
except it would break current code that uses :broadcast (if anyone actually is?) | 13:07 | ||
timo | we do have revision gating now, so it could be a change for the next language version if we want | 13:08 | |
guifa just tosses it on problem solving :) | 13:18 | ||
timo | yeah, good idea | 13:20 | |
guifa | also just thought about it -- I'll probably need to go figure out multicasting in Java and Javascript now too lol | 13:23 | |
Interesting, in the docs we do call :broadcast an adverb | 13:24 | ||
what's the bot that lets us search for usages of things across the ecosystem? | 13:31 | ||
timo | i think it's called greppable | 13:34 | |
with a 6 | |||
guifa | ah seems to be offline | 13:35 | |
github.com/Raku/problem-solving/issues/457 if anyone wants to comment :) | 13:38 | ||
timo | i don't think we have anything in the language for easily working with already-established file descriptors that can be sockets, files, pipes, whatever | 14:32 | |
like, we can't get a IO::Socket::Async by just opening fd 5 or such | 14:33 | ||
we can supply a path, which could in theory be /proc/self/fd/5 but i don't think attempting to open that path as a unix domain socket actually works if it's actually a AF_INET socket for example | 14:34 | ||
you can open that exact path as a regular file and then you get the same semantics as you would when you get a socket's fd and open() it in, say, C | |||
that's probably okay often enough for TCP, but i don't know how much you get out of it when using UDP, and i have zero clue of SCTP | 14:35 | ||
you can of course always nativecall into your libc but i'm looking for stuff available from raku directly | 14:36 | ||
also i want Proc::Async and related to allow you to pass established FDs to your child at specified numbers, too | 14:37 | ||
there should also be an easy path from "i'm on linux and i'd like to use AF_VSOCK" to "i have a Socket::Async i can use to communicate over that" | 14:42 | ||
not 100% sure putting vsock support directly into moar is right? it's slightly niche | |||
lizmat | yeah, MacOS doesn't support it out of the box | 14:45 | |
15:17
vrurg_ joined
15:20
vrurg left
|
|||
Geth | rakudo/main: 77c4c64e37 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod Add proper support for regexes to multi-needle .split Before this commit, having a regex as one of the needles in a multi-needle split would just take all the needles and interpolate them into a single regex. This was fine as long as you didn't specify any :k, :kv or :p adverb as well. If you did, then the key value would always be 0. ... (15 more lines) |
16:46 | |
lizmat | bisectable6: old=2024.12 say "twone".split((/<?after o>ne/, "two"), :kv) | 17:00 | |
bisectable6 | lizmat, Bisecting by output (old=2024.12 new=77c4c64) because on both starting points the exit code is 0 | 17:01 | |
lizmat, bisect log: gist.github.com/2726091bfba95a5f7e...3f34eb4762 | |||
lizmat, (2024-12-19) github.com/rakudo/rakudo/commit/77...b917c53560 | |||
lizmat | m: say "twone".split((/<?after o>ne/, "two"), :kv) | 17:02 | |
camelia | ( 1 two n 0 e ) | ||
Geth | rakudo/main: bea1f0991e | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod Fix stupid thinko in handling regex in multi-needle split The cursor tells us where the match begins, duh! |
17:24 | |
23:08
sena_kun left
|
|||
guifa | timo: interesting. What I was really trying to do is ultimately catch the closing of the socket. The way multicast works is you sign up to receive messages from a particular source. In theory, you should ALSO unregister. I'm not sure if the way things work if that's needed if the socket is closed, or if that's just an option for repurposing an existing socket | 23:41 |