<fangerer> Yes, help is always appreciated. Easiest is to look at the diff in `public_api.h`. For example, we need `HPyUnicode_FromEncodedObject`, `HPyUnicode_InternFromString`, and `HPyUnicode_Substring`.
<fangerer> We also have some functions in https://github.com/hpyproject/numpy-hpy/blob/graal-team/hpy-0.0.5/numpy/core/src/common/hpy_utils.h (and the corresponding `hpy_utils.c`) which are candidates for the HPy API.
<mattip> they all look reasonable except HPy_SetType which arguably is a bug or at least an unwanted feature. Are you sure that is needed?
<fangerer> No, not sure. IIRC, we introduced it because we focused on making progress. That definitively something we don't want to have in the end. We will need to restructure Numpy code a bit such that we don't need it.
<mattip> +1
<mattip> If I recall correctly, it something about MSVC and setting a field in a static struct
<fangerer> ah ok, that could make sense; MSVC is more pedantic concerning initialization of structs with struct literals
<fangerer> mattip: antocuni: I've opened a PR for the vectorcall protocol (https://github.com/hpyproject/hpy/pull/390). Please review.
<antocuni> fangerer: cool! Thank you, I'll try my best :)
<fangerer> Thanks.
<fangerer> btw. I've also written a micro benchmark for that and on my machine, vectorcall is 7-10% faster than `tp_call`
<fangerer> I'll push the micros in a separate PR (don't want to re-run the CI just because of that)
<Hodgestar> fangerer: Thanks for tackling vectorcall.
<Hodgestar> fangerer: Every time I look at the old C API for it, I go "arg" a lot. It feels more like a perfomance hack that got exposed than an API. However, I'm also not sure what to do about it.
<Hodgestar> fangerer: Do you have an important / good example use case for the per-instance vector call? What would prevent people who want per-instance calls from just adding their own C function pointer to their struct and doing it themselves?
<Hodgestar> It feels like we know that a better way is to have our "argument clinic-esque" API for JITs and similar, but that is a lot of work. :/
<Hodgestar> Maybe a goal for now is to be sure we can replace the implementation of vectorcall in HPy with the argument clinic APIs later without breaking compatibility.
<Hodgestar> Would it be possibe to remove HPy_VECTORCALL_ARGUMENTS_OFFSET from our API and, for example, make a new rule that one can always overwrite args[0] (i.e. pass the actual array instead of a pointer to the second element)?
<Hodgestar> Maybe I am wanting to clean up this API too much, but it is such a misshapen snowflake. :)
<Hodgestar> I'm also happy to write some of this into the PR, but I didn't want to fill the PR with ramblings.
<fangerer> > Do you have an important / good example use case for the per-instance vector call?
<fangerer> I don't have a real world example. I think the idea would be that you can have specialized call func impls depending on the object's data.
<fangerer> The PEP says: "Another source of inefficiency in the tp_call convention is that it has one function pointer per class, rather than per object. This is inefficient for calls to classes as several intermediate objects need to be created."
<fangerer> so, the real world example is "calls to classes"
<fangerer> > Would it be possibe to remove HPy_VECTORCALL_ARGUMENTS_OFFSET from our API and, for example, make a new rule that one can always overwrite args[0] (i.e. pass the actual array instead of a pointer to the second element)?
<fangerer> Sure and sounds good to me since it makes it very clear.
<fangerer> I'll transfer this discussion to the PR.
<fangerer> Hodgestar: I moved discussion to the PR and also gave answers there: https://github.com/hpyproject/hpy/pull/390#issuecomment-1355028271
<Hodgestar> Thanks!