<antocuni>
also, it seems they plan to add a mechanism to do C-to-C calls, similar to what we want to do as well
<antocuni>
so we probably should coordinate with them
<Hodgestar>
Woot. Getting the C-to-C calls sorted out will be great.
<cfbolz>
antocuni: I think what kmod is saying in his last comment there is true though
<cfbolz>
for pypy it would be amazing to have a way to specify the types and then call the raw c function with everything primitive unwrapped
<antocuni>
yes, that has always been in HPy's plan
<cfbolz>
so maybe we should comment
<cfbolz>
at least that it would be useful
<antocuni>
yes, I'll do it
<antocuni>
I'm involved in too many discussions at once and I'm failing at keeping track of all of them :)
<cfbolz>
hehe
<antocuni>
I added my answer to the "hasty-call" discussion
<arigato>
can anyone explain to me how the "hasty call" is not just Yet Another vectorcall-like extension?
<arigato>
I don't understand how it brings us closer to the stated goal "Ultimately we want to be able to call directly into those low-level functions from JIT compiled code"
<cfbolz>
arigato: yeah, I think what kevin (kmod) is saying further down is the right point
<antocuni>
I think that they are saying something different. I.e., eventually we would like to call low-level functions, but in the meantime we are adding this unrelated feature because it's easier for now
<steve_s>
re the C-to-C calls thing: why we need anything more than exposing the low level functions taking C primitive types via some capsule like numpy does with its API? I am probably misunderstanding it in the same/similar way as Mark does on the GitHub discussion. Is it about providing nicer API than wrapping function pointers to capsules and distributing some header files with their prototypes?
<Hodgestar>
The signature in Mark's example does look almost exactly like vectorcall, which doesn't help the JIT much because it still has to box and unbox things. :/
* Hodgestar
throws a kitten among the pigeons.
<steve_s>
I'd suspect that this will serve well for some concrete optimization in the current interpreter that he has in mind, but going all the way as kmod suggest would be more forward looking