-
-
Notifications
You must be signed in to change notification settings - Fork 52
dev call 20220303
Stepan Sindelar edited this page Mar 3, 2022
·
6 revisions
Antonio, Simon, Ronan, Matti, Tim, Mohaned, Stepan, Florian
-
- HPyGlobal vs Module State: both or just one
-
- HPyGlobal POC: https://github.com/hpyproject/hpy/pull/299
- Module state PR: TBD soon
- global state in MPL is needed, for example, in some slots where the module object is not easily accessible
- related: new "get current context" approach described in https://github.com/hpyproject/hpy/issues/268#issuecomment-1042824498
-
- NumPy Progress and Plans
-
- Metaclasses support for heap types in CPython.
- Extend other builtin types with pure HPy types (e.g. dtype meta inherits PyType_Type, numpy scalars inherit Python builtins) for pure HPy universal mode.
- Create binary that can run the e.g. all of the code in a [NumPy Game of Life](https://github.com/rougier/numpy-tutorial/blob/master/scripts/game-of-life-numpy.py)
-
- HPyErr_FromFormat and friends: https://github.com/hpyproject/hpy/issues/274
-
- Not super-important but if we want the MPL port to look polished and finalized, we'll need to deal with those.
-
- Misc
-
- Make final decision on "Should HPy_Close silently ignore HPy_NULL" https://github.com/hpyproject/hpy/issues/297
- CPython 3.10 compatibility https://github.com/hpyproject/hpy/issues/292
- Should we take over and finish the PEP 518 support PR https://github.com/hpyproject/hpy/pull/287
- Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS: https://github.com/hpyproject/hpy/pull/276
- Provide a HPyModuleFinder and HPyModuleLoader for some QoL for people trying out our HPy ports
-
- Next release?
-
- matplotlib-hpy port HPy extensions and publication of the port?
- Possible implementation: every global is basically just a per-interpreter token, e.g., an index into an array. Each interpreter would have its own instance of this array.
- Allocation needs to be done per process (across all interpreters)
- Possible "fast" mode: does not allow sub-interpreters and multiple interpreters in the same process but directly store the object's pointer in the global.
- We would have some context functions to use the global
- Open issue: how to do allocation of globals (e.g. generating a unique array index per process) if multiple interpreters are present. In this case, we would probably need to make it part of the HPy ABI (e.g. a counter variable).
- Each interpreter then needs to initialize every global during module initialization.
- Stepan started to migrate dtype
- Main problem: HPy does not support meta types and CPython does also not support it for heap types.
- There is a CPython issue for meta type support for heap types (10y old). It was recently brought up again.
- We could ask if Victor could help us with this. Chances should be good since we now have concrete use cases.
- Possible alternative solution: HPyType_FromSpec could also create a static type (but it will leak the struct)
- For upstream changes, we would need backport to 3.8
- Further problem: pure inheriting from built-in types * We need to align the artificial struct that contains PyObject/the builtin struct + the HPy struct, this is now done using "union hack", but that is not going to scale for all builtins(?), alternative: there is some POSIX API for getting memory alignment
- Should HPy_Close silently ignore HPy_NULL ? To make a decision: we should change all Py_DECREF to Py_XDECREF and see what the impact is.
- Kiwi, MPL perf was something like 25% worse than with C API. We need to investigate that anyway.
- HPyContext.h_builtins: don't remove HPy_Repr and co; Florian will create an appropriate GH issue for that
- Create issue for adding HPy_Eval
- CPython 3.10 compatibility: we should address that. Moving most HPy flags to HPyType_Extra_t sounds good. But we still need a way to identify HPy types. We could ask CPython to reserve a type flag for us. An alternative would be to use e.g. a special tp_dealloc function.
- HPyErr_FromFormat: continue discussion on the issue.
- 5 September 2024
- 4 April 2024
- 7 March 2024
- 1 February 2024
- 11 January 2024
- 7 December 2023
- 9 November 2023
- 5 October 2023
- 14 September 2023
- 3 August 2023
- 6 July 2023
- 1 June 2023
- 4 May 2023
- 13 April 2023
- 2 March 2023
- 2 February 2023
- 12 January 2023
- 1 December 2022
- 3 November 2022
- 6 October 2022
- 8 September 2022
- 4 August 2022
- 7 July 2022
- 2 June 2022
- 5 May 2022
- 7 April 2022
- 3 March 2022
- 3 February 2022
- 13 January 2022
- 2 December 2021
- 4 November 2021
- 7 October 2021
- 2 September 2021
- 12 August 2021
- 8 July 2021
- 6 May 2021
- 4 March 2021
- 7 January 2021
- 3 December 2020
- 5 November 2020