|
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. |
|||
|
10:31
sena_kun joined
|
|||
| Geth | MoarVM/main: 1c2ea87e7b | timo++ (committed using GitHub Web editor) | 3 files Install gdb extension (#1848) Install GDB extension to the system where gdb looks for it |
13:17 | |
| guifa | So I'm trying to add another argument to a moarvm call in NQP. AFAICT I've updated everything in Moar world, but I must be missing something | 14:50 | |
| When generating NQP, I get | 14:51 | ||
| Stage mast : Arg count 7 doesn't equal required operand count 6 for op 'asyncudp' | |||
| at NQP::src/vm/moar/QAST/QASTOperationsMAST.nqp:153 (/Applications/rakudo/share/nqp/lib/QAST.moarvm:compile_mastop) | |||
| ah it looks like I need to update ops.c also, somehow missed that that one had a reference too | 15:24 | ||
| oh and oplist (which I guess generates ops.c it seems like) | 15:32 | ||
| But fixing those still seems to register somewhere along the chain an operand count of 6 | 15:35 | ||
| lizmat | timo may be able to help | 15:41 | |
|
15:51
MasterDuke joined
|
|||
| MasterDuke | guifa: tools/update_ops.raku | 15:53 | |
| guifa | Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from 'gen/moar/Pod.nqp') | 15:54 | |
| MasterDuke | After updating sec/core/oplist | ||
| guifa | although maybe at this point I've b0rked my installs and I need to do some fresh builds and installs | ||
| MasterDuke | Well, you have to have a working raku… | ||
| guifa | yeah, I'll go build an older version somewhere else and then run from that one | 15:55 | |
|
15:56
MasterDuke left
|
|||
| timo | guifa: i recommend using the syscall mechanism for this instead of the ops | 20:46 | |
| just leave the asyncbindudp op as it was and add a new syscall to do the same thing but with one more parameter | 21:01 | ||
| guifa | timo: noted. Actually then, I might see if I can have it be adding membership to multicast with or without source specificity | 21:21 | |
| And then let Raku land code handle making the two separate calls | |||
| certainly would make the MoarVM code a bit lighter, I think, and most people aren't going to be opening and closing multicast sockets in tight loops | |||
| timo | syscalls can take any amount of arguments dynamically | 21:34 | |
| ops must be compiled with a fixed number of arguments | |||
| guifa | hmm, okay. What I was thinking was more along the lines of leave asyncbindudp exactly as is | 22:00 | |
| and then the next op would be "make multicast". For other languages like NodeJS and Julia, those are indeed two separate calls in the language, but I think it makes more sense for Raku to be one line. But if anyone else wants to support MoarVM for their language, leaves them the option | |||
| but if you think the syscall route is better suited, happy to go that way. I don't really know any pros/cons of them | 22:04 | ||
| Geth | MoarVM: AntonOks++ created pull request #1881: beautify release_guide.md |
22:07 | |
| timo | yeah syscalls are actually pretty good | 22:22 | |
| i would maybe even go so far as to say that we could turn more ops into syscalls over time | 22:24 | ||
| lizmat | I wonder whether it would be an idea to get rid of a lot of nqp::ops at the VM level | ||
| ^^ I was just typing that :-) | |||
| also: I wonder if we could have a syscall to see whether there is a syscall for "foo" ? | 22:25 | ||
| timo | you can just try to call the syscall and catch the exception if it doesn't exist :D | 22:26 | |
| what kinds of nqp ops would you think should go away? | |||
| lizmat | I guess the ones that aren't very performance sensitive ? | 22:27 | |
| guifa | okay, I think I can see pretty easily how to set up a syscall | 22:30 | |
| timo | yeah it's pleasantly simple | ||
| guifa | looks like they all have a foo-impl where you write the underlying code, and then a foo which sets it up for use | ||
| timo | yeah the foo struct that has the properties and at the very end of the file it's "registered" | 22:31 | |
| guifa | Any restrictions on what I can call in the syscall ? | 22:33 | |
| My naîve thinking is I could remake it as a syscall that calls the extant asyncsocketudp call, and then in asyncsocketudp.c add one more call for making stuff multicast | 22:34 | ||
| (assuming I can access the right underlying bits) | |||
| timo | i don't think there's any special limitations | ||
| guifa | alright, that might make it fairly painless to do | 22:35 | |
| aaaah actually | 22:38 | ||
| timo | oh no? | ||
| guifa | wait no, nm. | 22:39 | |
| I was concerned I needed to get a queue, but that's actually passed in from Raku/nqp land | |||
| what is the expected_kinds in the struct? | 22:45 | ||
| { INVOCANT , RESULT } ? | 22:46 | ||
| timo | for kinds, usually mostly obj or int, maybe str sometimes? | 22:47 | |
| guifa | I didn't know if it's refering to the expected invocant or the expected result | 22:52 | |
| timo | ah, no, the result is not part of these arrays | 22:53 | |
| guifa | ah okay, they're args then? | 22:54 | |
| timo | syscalls are slightly like an invocation, so they get arguments passed and there's a spot where they can store their result, which may be a register of any kind, and they may set any kind of result, and the moarvm bits make sure it gets put properly | ||
| guifa | do syscalls have separate syntax in NQP land? | 22:56 | |
| timo | yes, nqp::syscall("blabla", arg1, arg2, arg3) | ||
| well, it's not so much "separate syntax" | 22:57 | ||
| guifa | alrighty | ||
| goal is going to be just make syscall take the current UDP setup args and pass them to the c function | |||
| if I can get that work I think we'll be golden | |||
| timo | i don't foresee any trouble with that | 22:58 | |
| guifa | do you get NULL if an argument isn't present? | 23:07 | |
| timo | you need to check by looking at what callsite the syscall was invoked with | 23:09 | |
| trying to access the index of an argument that wasn't passed will be invalid memory access, though unlikely to crash immediately, only confusing and unpredictable results | 23:10 | ||
| guifa | alright noted, I'll go see how some of the varg ones works | ||
| timo | look at the MVMArgs argument, it has a callsite member with num_flags telling you how many arguments there are, which is a good starting point | 23:11 | |
|
23:12
sena_kun left
|
|||
| guifa | yeah looks like it's | 23:13 | |
| arg_info.callsite->num_pos | |||
| will I need to do anything else set up wise besides the add_to_hash(tc, &async_socket_udp) or should everything just compile? | 23:33 | ||
| timo | everything should just compile i think | 23:34 | |
| guifa | I guess we'll find out here in a bit :) hopefully I get the representations correct for the args | ||
| timo | did you give the right repr for the io handle argument? | 23:36 | |
| MVMOSHandle i assume? | |||