01:12 <mkoubaa2> Hello! I'm proposing some changes to the doc in this PR (https://github.com/hpyproject/hpy/pull/336). Please let me know what you think. If there is something else in the doc that anyone feels is missing or weak I can take another look at it

04:28 <Hodgestar> mkoubaa2: Thank you! I will try look once I have recovered a bit more from the conference.

12:44 <fangerer> antocuni: great to hear!

12:46 <fangerer> concerning the lost type info: we already discussed this in one of our dev calls. As far as I remember, we agreed that we won't add support for that in HPy but extensions can just do it. E.g. we can define a `typedef struct { HPy h; PyArrayObject *data; } HPyArrayObject` or such

13:16 <antocuni> yes, I agree

13:17 <antocuni> I think it's an unsolvable problem, given the constraint of C. I.e., extensions which migrate to HPy will have to face with it and be slightly annoyed but this problem

13:17 <antocuni> but hopefully is not annoying enough to prevent people to use HPy

14:27 <fangerer> antocuni: did you talk about next steps on how to upstream our NumPy/HPy changes? Did Sebastian have any hints? I mean, Matti already told us how we should start but maybe Sebastian had anything to add.

14:29 <fangerer> mkoubaa2: thank you for your PR! I think there would be a lot more to do in the docs. If you are willing to work on that, I can probably collect some tasks.

14:31 <steve_s> related to the lost type info: we are also loosing a bit of performance because we have to call HPy_AsStruct, but if we had some flexible calling convention (aka argument clinic) it would help with that. Than maybe we would like to use the same way as the calling convention, i.e., if it would pass two arguments one HPy and the other the struct, we may want to use that convention even for internal helper functions called within NumPy

16:29 <fijal> you gonna get banned from some forums with such name...

21:00 <antocuni> fangerer: we talked about migrating to heap types and he's fine with it

21:01 <antocuni> if I understand correctly the biggest blocker is tp_vectorcall

21:02 <antocuni> if I understand it correctly, tp_vectorcall CAN be used with heap types but it might have a weird behavior if you subclass it from python

21:02 <antocuni> and I seem to recall that in numpy this is used only for dtypes, which are not supposed to be subclassed from python

21:03 <antocuni> but I admit I don't remember the details

21:03 <antocuni> Hodgestar took some notes though, so he may recall better

21:03 <antocuni> in general we went through all of your notes and they seemed easy to fix or workaround, but I don't remember precisely :)

21:04 <antocuni> it might be a good idea to start a more direct conversation with him and mattip. I'm happy to try to setup a call if needed

23:13 <Hodgestar> I did take some paper notes. I'll write them up in a day or two (today was the first day of actual holiday post the conference).

23:14 <antocuni> thank you!

23:14 <antocuni> I hope you are enjoying your post-conference holidays :)

23:16 <Hodgestar> fangerer: If there are things we can change now -- e.g. sorting out details of how dtypes work -- without using HPy right away, Sebastian would be quite happy to have those changes now. We also need a proper porting plan -- e.g. open a PR with these bits for comment, stabilize a version of HPy, decide on a general strategy, etc, etc.

23:16 <Hodgestar> We probably also need a long term survival plan for HPy (versioning, funding, support, etc).

23:17 <Hodgestar> Sebastian would almost certainly be happy with an exploratory PR -- not too hacky, but with, e.g. "WIP: This cannot be merged until HPy 1.0 is releases and has proper versioning, etc ...".