<fangerer>
highlighting c module code... [ 25%] autogen/public_api.h
<mattip>
what did you get as output and what did you expect to get?
<cfbolz>
phlebas: ping?
<cfbolz>
phlebas: how does graalpy support C-level subclasses of built-in types, like int?
<cfbolz>
where do you store the pointer to the C memory?
<phlebas>
a native subclass of `int` (or `float` etc) is purely native - there's no managed part, the managed object is just a wrapper around a pointer
<cfbolz>
even using HPy?
<cfbolz>
or just in your cpyext?
<cfbolz>
phlebas: what about something like dict, where there is more complicated data on the managed side usually?
<phlebas>
i'm not sure we support subclassing dict
<cfbolz>
ok
<cfbolz>
seems there is no test for subclassing a built-in type, and having an interesting hpy struct yet, or am I missing that?
<antocuni>
cfbolz: HPy doesn't support subclassing builtin types so far
<antocuni>
although fangerer is working on it because it's needed to implement metaclasses in C
<antocuni>
in that case you inherit from "type" and on CPython you embed PyHeapTypeObject, but it's the same for other builtin types
<antocuni>
the solution which I and fangerer designed at the sprint is the following
<arigato>
(and *writing metaclasses in C* is something we definitely want for some reason?)
<antocuni>
arigato: I fear we want it because C extensions use the feature. E.g. porting numpy without them would be much harder
<antocuni>
1. in HPyType_Spec, you have a field called "builtin_shape" (or similar), which can be Shape_Legacy, Shape_Object, Shape_Type, Shape_Int, etc.
<cfbolz>
antocuni: there is a test for it already though
<antocuni>
Shape_Legacy means that your C struct embeds e.g. PyHeapTypeObject_HEAD, so the PyObject* points at the start of the C struct
<antocuni>
all the other shapes assume that the user-defined C struct is "pure"; and Shape_Object is the default of course
<antocuni>
then we will have an _HPyType_AsStruct_* for every shape; this way each implementation can know how to translate a handle/PyObject* into a pointer to the C struct
<cfbolz>
arigato: for some reason basically everyone does it :-(
<antocuni>
and finally, HPyType_HELPERS depends on the shape: so e.g. it generates PointObject_AsStruct() which internall calls the _HPy_AsStruct_* with the correct shape, which means that in CPython-ABI mode we have a fixed-offset at compile time
<antocuni>
cfbolz: what is the test?
<cfbolz>
arigato: it's a big thing that re-appears on various cpython channels with some regularity, because you can't easily have heaptypes that inherit from type
<cfbolz>
antocuni: ah, missed the question. it's test_with_spec_and_params in test_helpers.py
<cfbolz>
it subclasses int
<cfbolz>
(why is the C name still h_LongType?)
<phlebas>
cfbolz: iirc what fangerer told me, that particular test works currently, because no C structure is added - you can subclass all you want if you're only adding methods, not C data
<cfbolz>
Ok
<mattip>
Wouldn't you eventually need HPy_AsStruct somewhere, even for some methods? For instance in the buffer protocol
<mattip>
no, I guess not, the instance should use the parent's methods to create a buffer