-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
40 lines (27 loc) · 2.48 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
DONE: Need to mark ExternalPtr as being non-intrusive in general, and switch
to SharedPtr for the types that support it.
DONE: Enums: https://pybind11.readthedocs.io/en/stable/classes.html#enumerations-and-internal-types
TODO: Determine which enums don't need py::arithmetic
Concerining Base classes that are not RefCounted derived that RefCounted's derive from
GPUObject good -- can ignore, leave it to internals to handle (if needed can handle with implicitly_convertible, probably)
Thread as well
Deserializer should be doable with an implicitly_convertible?
not sure we can expose VectorBuffer and MemoryBuffer, though (maybe they don't get the implicitly convertible...?). Could also just create explicit overloads with all teh derived types of Deserializer with lambda functions. Will test if there are any instances of the holder actually made for those with a ThrowingPtr holder type.
Need to check about the (Lua)ScriptEventListener classes.
May need to handle btMotionState, possibly btIDebugDraw and b2Draw, b2ContactListener
No idea if Octant is needed
TODO: Later: libRocket stuff
TODO: I could also tro specializing SharedPtr for the derived class issue bases (like Deserializer), then we just assert in all of the Functions rather than doing anything, and that should tell us if PyBind11 ever makes one of them.
Leak a reference to the context and then clean it up at the end (or switch to a singleton pattern for it) so that we don't end up with crashes on exiting from freeing the context first.
grep bindresult.cpp -B 1 -e "max ptr [^01]"
Function pointer type support (it's often getting flagged as being a higher pointer number than 1)
NOTES: About 8 GB for the present bindresult.cpp where the class declarations and implementations are in other files but the enum implementation is just in another function
- about 1.5-2 GB without the enum implementation
- about 6.7 GB for just the enum function w/ 123-7 enums
- roughly linear with the number of enum_'s, about 3.2 GB for 60-7 enum_'s, 1.1 GB for 20 enum_'s, 514 MB for 1 enum_, 480 ish w/ 0 enum_'s
## all of the below are bad as I was changing the wrong file...
NOTES: About 8 GB for the present bindresult.cpp where the class declarations and implementations are in other files but the enum implementation is just in another function
- same even without the enum implementation
- same even without the container specification
- same even without the namespace variable module faking stuff
bindresult1.cpp uses only about 2GB of RAM, though