Ralf W. Grosse-Kunstleve

Results 538 comments of Ralf W. Grosse-Kunstleve

For the record, I also experimented with this script: https://github.com/rwgk/stuff/blob/2398710e6be12f65c044b91c8cb105093c720f43/cuda-python/cuda_bindings_nvvm_proc_self_maps.py Example: Into a `scratchvenv`: ``` pip install cuda_bindings-12.8.0-cp312-cp312-linux_x86_64.whl ``` Example output WITHOUT setting LD_LIBRARY_PATH: ```sys.path=['/home/rgrossekunst/clone/stuff/cuda-python', '/home/rgrossekunst/rwgk_config/py', '/usr/lib/python312.zip', '/usr/lib/python3.12', '/usr/lib/python3.12/lib-dynload', '/home/rgrossekunst/scratchenv/lib/python3.12/site-packages']...

Possible approaches for locating libnvvm.so: * Rely on the existing `$ORIGIN/../../../nvidia/cuda_nvcc/nvvm/lib64` `rpath` addition to discover `site-packages/nvidia/cuda_nvcc/nvvm/lib64`. * Traverse `sys.path`, look for `lib` subdirectories, look for `nvvm/lib64` in their parent directories....

Some ChatGPT queries, for more datapoints: * https://chatgpt.com/share/67d03b9a-07c4-8008-bad7-5fcc777cf37e For easy reference, copy-pasting summaries: General: * Use `cuda-toolkit-config` if available (it's direct and robust). * Fallback to `which nvcc` or `CUDA_HOME`...

Thanks @kkraus14, that's very useful, for me to better understand the environment. > We intend to move `numba.cuda` to depend on `cuda.core` for its internal usage of CUDA libraries, so...

Content moved here: https://github.com/NVIDIA/cuda-python/issues/451#issuecomment-2810937934

> @junyer Or should we also add 2.13.0 to BCR? Tragically we lost our junyer: [google/re2#502](https://github.com/google/re2/issues/502) @jiawen is there a chance that you could help?

I think we are set up so that the CI will never trigger automatically. Only of you leave the ok to test comment. Certainly in draft mode.

> What version (or hash if on master) of pybind11 are you using? > 2.3.0rc1 Do you mean 3.0.0rc1? > I am trying out the numpy 2.3.0rc1 arm windows support,...

Sorry I don't have a lot of time to spend on this, could you please 1. Try the `type_caster_enum_type_enabled` specialization as documented in the upgrade guide? — I strongly believe...

> Might this be because it used to convert to the underlying integer type, but now it's expecting a `py::native_enum` caster to be registered? ... no, I think. The error...