00:22 <ronan> the random idea is just a concept. I don't really know what the concrete consequences can be. I guess we'd need to implement HPyField in pypy or GraalPython to see if it makes any sense

09:53 <antocuni> _hf2py on pypy means that you need to create an HPy, which means you might have to resize HandleManager.handles_w, which might trigger a reallocation

09:53 <antocuni> I don't know if that's possible from within a custom GC tracer but I doubt it

12:29 <Hodgestar> Could tp_traverse for HPy walk HPyField's directly? I.e. not care about handles at all?

12:29 <Hodgestar> Then one wouldn't have to load anything?

12:29 <Hodgestar> (I have not been following the conversation that closely).

16:54 <antocuni> Hodgestar: ronan's problem is that to know where the HPyFields are inside a numpy array, he needs to manipulate app-level objects

16:55 <antocuni> because those info are stored inside the dtype

16:57 <Hodgestar> Ah, so not on the object being traversed?

16:58 <Hodgestar> But on an object referenced by the object being traversed.

16:58 <antocuni> yes

16:58 <Hodgestar> Ah. Bleh.

16:58 <antocuni> I think it's about "structured arrays": https://numpy.org/doc/stable/user/basics.rec.html

16:59 <antocuni> i.e. arrays whose items are C-like structs. The problem is to know which of the struct fields contain PyObject/HPyField

16:59 <antocuni> if I understood correctly

17:45 <mattip> We could limit the hpy numpy support to the array API standard

17:45 <mattip> https://data-apis.org/array-api/latest/

17:45 <mattip> which does not allow object and structured dtypes

17:45 <mattip> at least as a first step

17:46 <mattip> people who want structured arrays or object arrays can use the c-api