Move `pathfinder` to cuda-python top level #723

rwgk · 2025-06-24T08:20:15Z

Description

Note: The name is changed from path_finder to pathfinder. The word "pathfinder" is very common, and it avoids underscore/dash confusion between directory names and package names.

Move cuda.bindings.path_finder → cuda.pathfinder, with backward compatibility: cuda.bindings.path_finder forwards to cuda.pathfinder.
- Make LoadedDL._handle private (underscore prefix). It is now a platform-agnostic unsigned integer.
Make cuda-bindings dependent on cuda-pathfinder, with a temporary backward compatibility layer. — cuda.bindings.pathfinder is slated to be removed after the next cuda-bindings release.
Remove 32-bit DLL names from SUPPORTED_WINDOWS_DLLS and add runtime guard in cuda.pathfinder.load_nvidia_dynamic_lib(): "requires 64-bit Python".
Add specific DynamicLibNotFoundError exception type to public API (this was RuntimeError before; now inherits from RuntimeError).
Run mypy-pathfinder from pre-commit (after systematic mypy cleanup of library code).
Adjust GitHub Actions jobs to the move.
Add nvidia_wheels_cu12 to [project.optional-dependencies] in cuda_pathfinder/pyproject.toml and ensure all libs are loaded successfully. Treat all NVIDIA libs as "supported".
Mark cuda.pathfinder as version 1.0.0

…HOUT trying to make anything work.

… trying to make anything work.

…make anything work.

…ns.abc.Sequence (Python 3.9+)

…init__.py (to make the dynamic version work).

copy-pr-bot · 2025-06-24T08:20:19Z

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

…vidia_dynamic_lib

shwina · 2025-06-25T10:52:46Z

cuda_pathfinder/cuda/pathfinder/__init__.py

+def load_nvidia_dynamic_lib(libname: str) -> LoadedDL:
+    """Load a NVIDIA dynamic library by name.
+
+    Args:
+        libname: The name of the library to load (e.g. "cudart", "nvvm", etc.)
+
+    Returns:
+        A LoadedDL object containing the library handle and path
+
+    Raises:
+        RuntimeError: If the library cannot be found or loaded
+    """
+    return _load_nvidia_dynamic_lib.load_lib(libname)


You could define this wrapper function in the _dynamic_libs module and just import it here. This way your __init__.py here wouldn't have a ton of function definitions.

This file is meant to be the public API in one view.

This way your __init__.py here wouldn't have a ton of function definitions.

I understood exactly that was your goal: a flat list of available APIs.

Note that I moved the docstring here.

This file is meant to be the public API in one view.

Indeed, everything we define (or import) here that is not prefixed with _ constitutes the public API of the module cuda.path_finder. My above suggestion is just that we import load_nvidia_dynamic_lib rather than define it here.

That would make the public API far less obvious. E.g. to see the docstring, they'd need to open a private file.

I don't think that's true. They could still do:

from cuda.path_finder import load_nvidia_dynamic_lib help(load_nvidia_dynamic_lib)

Same as they would do now?

That'll only work interactively.

What I have now can be inspected in obvious ways directly in the sources, e.g. when looking at the sources on github. I can send URLs pointing to specific APIs in this init.py file.

Each function here will just be:

def function(...) -> ...: """docstring"" return call_into_private_code(...)

That's exactly the public API, with a one-line call that's easy to ignore.

What's the point of hiding that away, especially hiding away the docstring and the type hints?

That'll only work interactively.

The docstrings and type hints would also get picked up:

Sphinx (which we use to generate API docs
-pydoc

the developers' IDEs/lsp

Those are primarily the ways consumers of a package interact with docstrings or type hints, rather than looking directly at the source.

What's the point of hiding that away, especially hiding away the docstring and the type hints?

It tightens the scope of __init__.py, whose job is:

to include any initialization code for the module

to import stuff from submodules that the module wants to expose

to define __all__ for the module if needed

As examples, we can look at the __init__.py from some other popular libraries:

requests

pandas

It tightens the scope of init.py, whose job is

The most important job: Show the public API

You didn't answer why you want to hide that away.

I'm advocating for keeping function and type definitions outside of __init__.py. I don't think that "hides" anything from the user as we still import them here.

The main reason I'm advocating for that is because __init__.py typically only defines functions and types needed for module initialization, and imports anything else. I think the examples I linked to above are a good demonstration of that.

Defining functions and types beyond that serves to clutter __init__.py.

I would argue it makes the code base less navigable than more for people looking at the source. Do I expect the function load_nvidia_dynamic_libs to be defined in a file called _dynamic_libs.py, or a file called __init__.py?

If this all seems nitpicky, I apologize. While I do have a strong opinion here, I don't mind at all if another reviewer (or you, as the author of this PR) made the final call about this.

cuda.core's __init__.py is a good example for what Ashwin suggested. As a developer who occasionally peeks into someone else's __init__.py, I certainly get confused why we are defining things in there directly, as opposed to properly organizing them in respective public/private modules, and just import them. What's imported are considered public APIs (including types). Does it make sense?

rwgk · 2025-06-25T21:49:30Z

I'm a bit lost, to be honest, and I’d appreciate some clarification so I can move this forward in the direction you want.

The goals that seemed most important to me originally (from a Slack post last Wednesday) were:

Dependency isolation – avoid importing unrelated logic (e.g. dynamic lib loading) when only working with headers
Public API should be obvious from the code – minimal need for external docs or tooling to understand what’s exposed

After Ashwin’s comment on Slack, I interpreted the request as: prioritize a flat public API, even if that means giving up on some of that isolation — especially when type hints are involved.

Then Leo wrote:

as opposed to properly organizing them in respective public/private modules

That seems more aligned with what I had before the last commit (e.g., a file like nvidia_dynamic_libs.py directly under pathfinder/). But that seemed in conflict with Ashwin’s preference for flatness.

I’m happy to implement what you both want here — I just need a bit more clarity.

If we go back to what I proposed last week:

from cuda.pathfinder import nvidia_dynamic_libs, nvidia_static_libs, nvidia_headers

nvidia_dynamic_libs.load("nvrtc")
nvidia_static_libs.find("cudart")
nvidia_headers.find_file("cuda.h")

The file structure was:

cuda/pathfinder/
├── __init__.py  # empty
├── nvidia_dynamic_libs.py
├── nvidia_static_libs.py
└── nvidia_headers.py

I thought that structure balanced modularity and clarity, and users could still import just what they needed. But it sounds like we might instead prefer:

from cuda.pathfinder import load_nvidia_dynamic_lib, find_nvidia_static_lib, find_nvidia_header_file

That keeps the API flat, but does give up on the isolation goal unless we resort to function-local imports or other workarounds.

Could you please help me understand: What would be the preferred file/module structure to go along with the flat API? Should I keep separate modules like nvidia_dynamic_libs.py and re-export in __init__.py, or move everything into a single file (what would be the name)?

shwina · 2025-06-25T22:57:32Z

Given there's some urgency for getting this PR in, @rwgk @leofang do you want to proceed with the PR as is and address the questions Ralf posed above as a follow-up?

leofang · 2025-06-26T00:07:51Z

At this point we need to follow up offline. I think there is a gap that we unfortunately did not really cover during the weekly meeting. I suggest we don't cancel the dev meeting tomorrow and use the time to finalize it.

This PR also needs at least @kkraus14's approval for the change of license.

rwgk · 2025-07-08T23:01:45Z

Approved, but would like to finish the conversation on whether handle is needed to be a public attribute

Thanks!

I'm thinking of that as essential, with the primary use case in mind, like here:

cuda-python/cuda_bindings/cuda/bindings/_internal/nvvm_linux.pyx

Line 55 in 126bca0

cdef uintptr_t handle = path_finder._load_nvidia_dynamic_library("nvvm").handle

It's unfortunate that there is no universal handle type, but I believe what we're using (in the checked-in code already) are de-facto standards.

Introducing our own handle type: presumed over-engineering, more likely to cause confusion than being helpful.

Hiding the handle object: presumed to cause usability hardships.

While writing this, I realized that I lost comments that I had earlier, about how to use the handle objects in cython. I'll work on adding them back here (in load_dl_common.py) asap:

if IS_WINDOWS:
    import pywintypes

    HandleType = pywintypes.HANDLE
else:
    HandleType = int

rwgk · 2025-07-09T04:45:27Z

In my previous comment I wrote:

It's unfortunate that there is no universal handle type, but I believe what we're using (in the checked-in code already) are de-facto standards.

I quizzed the LLMs a bit, and I'm surprised to learn:

ChatGPT: ctypes.WinDLL (and CDLL) is much more widely used and idiomatic for dynamically loading and calling functions from DLLs in Python — especially in cross-platform projects like yours.
claude.ai: ctypes.windll is significantly more widely used than win32api for dynamic library loading, ...

@kkraus14 @leofang does that match your experience?

If yes, I believe I should rework load_dl_windows.py, in this PR, and change the LoadDL.handle type to ctypes.CDLL. It will be much nicer to have a platform-independent type.

(I'm also much better set up now to get this done quickly, compared to my situation a couple months ago: I have easy interactive access to a Windows development environment now, and fairly comprehensive CI testing is in place already.)

kkraus14 · 2025-07-09T05:49:15Z

Yes, ctypes is probably the most common way that a shared library is loaded in Python in this way. That being said, I don't think we particularly want to encourage users to start making function calls into the loaded cuda library, so returning a CDLL doesn't feel like the right choice in my opinion.

My 2c: I think we should remove the handle attribute from being part of the public API for now. For our usage in cuda.bindings we can access an internal attribute in _handle or something similar for now and as we gauge usage we can see if / how we'd like to expose something like this.

If someone wanted a ctypes object based on LoadDL it would be quite straightforward: CDLL(LoadDL.abs_path) which I think is sufficient for now.

rwgk · 2025-07-09T07:08:35Z

Yes, ctypes is probably the most common way that a shared library is loaded in Python in this way. That being said, I don't think we particularly want to encourage users to start making function calls into the loaded cuda library, so returning a CDLL doesn't feel like the right choice in my opinion.

My 2c: I think we should remove the handle attribute from being part of the public API for now. For our usage in cuda.bindings we can access an internal attribute in _handle or something similar for now and as we gauge usage we can see if / how we'd like to expose something like this.

If someone wanted a ctypes object based on LoadDL it would be quite straightforward: CDLL(LoadDL.abs_path) which I think is sufficient for now.

Cool! Then we can simplify and standardize to:

@dataclass
class LoadedDL:
    """Represents a loaded dynamic library with minimal public API."""
    abs_path: Optional[str]
    was_already_loaded_from_elsewhere: bool
    _handle: int  # Platform-agnostic unsigned pointer value

With that, win32api and pywintypes will appear exclusively in load_dl_windows.py.

This is based on the observation that ultimately _handle is a pointer type on all platforms:

For Linux that's extremely obvious:

void *dlopen(const char *filename, int flags);

For Windows we have to drill down:

https://learn.microsoft.com/en-us/previous-versions/ms915415(v=msdn.10)

HMODULE LoadLibraryEx(
LPCTSTR lpLibFileName, 
HANDLE hFile, 
DWORD dwFlags );

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

HMODULE — A handle to a module. This is the base address of the module in memory. HMODULE and HINSTANCE are the same in current versions of Windows, but represented different things in 16-bit Windows. This type is declared in WinDef.h as follows: typedef HINSTANCE HMODULE;

HINSTANCE — A handle to an instance. This is the base address of the module in memory. HMODULE and HINSTANCE are the same today, but represented different things in 16-bit Windows. This type is declared in WinDef.h as follows: typedef HANDLE HINSTANCE;

HANDLE — A handle to an object.This type is declared in WinNT.h as follows: typedef PVOID HANDLE;

PVOID — A pointer to any type. This type is declared in WinNT.h as follows: typedef void *PVOID;

With that, we just have to be careful to consistently cast from/to unsigned integers.

Linux: CDLL._handle is already an unsigned integer.

For Windows, claude.ai suggests:

def _handle_to_int(native_handle: pywintypes.HANDLE) -> int:
    """Convert Windows HANDLE to unsigned int."""
    # Windows HANDLE is already an integer representation of a pointer
    # Just ensure it's treated as unsigned
    handle_int = int(native_handle)
    if handle_int < 0:
        # Convert from signed to unsigned representation
        handle_int += 2**64  # Assuming 64-bit pointers
    return handle_int

…finder/tests pass, cuda_bindings/tests are broken). Interactive testing: CUDA_PATHFINDER_TEST_LOAD_NVIDIA_DYNAMIC_LIB_STRICTNESS=all_must_work pytest -ra -s -v tests/ python ../toolshed/run_cuda_pathfinder.py

This does not break any cuda_pathfinder tests. (cuda_bindings tests are "more broken".)

…vate member.

…der.py

rwgk · 2025-07-09T17:54:19Z

/ok to test

rwgk · 2025-07-09T18:32:41Z

@kkraus14 Could you please take another look?

The changes in cuda_pathfinder turned out to be really straightforward:

46fd972 — Make LoadedDL.handle an unsigned integer also for Windows.
428a2dc — Rename LoadedDL.handle → LoadedDL._handle_uint
4096885 — Move _handle_uint last in LoadedDL, to emphasize that this is private member.

The changes in cuda/bindings/path_finder.py probably look a bit hairy, but I believe in a month or two we can simply delete the entire file.

rwgk · 2025-07-09T21:16:49Z

@kkraus14 I'm testing the mostly auto-generated load_dl_windows.py win32api → ctypes conversion under PR #751. Assuming it passes, we could add the changes to this PR, so that cuda-pathfinder does not have any external dependencies from the start.

kkraus14 · 2025-07-09T21:19:45Z

I'm quite happy with the latest set of changes in terms of the state of the public API at this point.

As far as the type of the now private handle attribute, I would defer entirely to your best judgement on how it is typed and represented based on our own consumption of it.

Will do a deeper dive implementation review when I get some spare cycles.

rwgk · 2025-07-09T21:38:41Z

As far as the type of the now private handle attribute, I would defer entirely to your best judgement on how it is typed and represented based on our own consumption of it.

I'm very happy with the latest state of the pathfinder code, as under PR #751.

Without your feedback, I'd probably have standardized on ctypes.CDLL, but standardizing on unsigned int instead seems clearly better for these reasons:

It doesn't get more robust / future-proof than that. We're not committing to any library.
We're not "inviting" people to make ctypes-based function calls into the loaded shared libraries.
For power users, a platform-agnostic convention will be the easiest to work with.

To the last point: unsigned ints are the de-facto standard under Linux, signed ints seem to be more common under Windows. In theory, we could go with that, but then people would always have to think twice. A simple "it's always an unsigned int" gives them a firm reference point on our side, then they only need to figure out what the "other side" (e.g. win32api) expects, and only if they actually need to interface.

rwgk · 2025-07-09T21:53:27Z

Testing under PR #751 passed: https://github.com/NVIDIA/cuda-python/actions/runs/16180272303?pr=751

I'll hold off moving the changes over to this PR until after your review. (I assume the split makes the review a little easier.)

rwgk · 2025-07-10T00:06:12Z

For last-minute polishing, I worked under #751 on hardening the ruff.lint config (going by LLM suggestions) ... and I'm so glad I got to it, this was a pretty silly oversight:

ruff (legacy alias)......................................................Failed
- hook id: ruff
- exit code: 1

cuda_pathfinder/cuda/pathfinder/_dynamic_libs/load_dl_common.py:10:7: N818 Exception name `DynamicLibNotFound` should be named with an Error suffix
   |
10 | class DynamicLibNotFound(RuntimeError):
   |       ^^^^^^^^^^^^^^^^^^ N818
11 |     pass
   |

Found 1 error.

(The other changes in e90855e and 15c5791 are just nice to haves.)

kkraus14 · 2025-07-11T18:10:15Z

cuda_bindings/cuda/bindings/path_finder.py

 __all__ = [
    "_load_nvidia_dynamic_library",
    "_SUPPORTED_LIBNAMES",
 ]


Given this module is effectively part of the public API, is using __all__ here sufficient to guard against the non-underscored import names and class we're introducing?

Not perfectly:

>>> import cuda.bindings.path_finder >>> dir(cuda.bindings.path_finder) ['HandleType', 'LoadedDL', 'Optional', '_SUPPORTED_LIBNAMES', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '_load_nvidia_dynamic_library', 'dataclass', 'load_nvidia_dynamic_lib', 'supported_nvidia_libs']

The __all__ mainly (or maybe only) affects the import * behavior:

>>> dir() ['__annotations__', '__builtins__', '__doc__', '__loader__', '__name__', '__package__', '__spec__', 'cuda'] >>> from cuda.bindings.path_finder import * >>> dir() ['_SUPPORTED_LIBNAMES', '__annotations__', '__builtins__', '__doc__', '__loader__', '__name__', '__package__', '__spec__', '_load_nvidia_dynamic_library', 'cuda']

I think it's fine though, in the interest of not increasing the complexity here, and because I want to remove this entire file as soon as possible. The game plan:

After this PR is merged, create PyPI cuda-pathfinder (v1.0.0) asap.

Update cuda-cccl to use cuda-pathfinder.

Update cuda-bindings internals to use cuda-pathfinder directly.

Ask around who else is using cuda.bindings.path_finder and take care of those. I figure there will only be a couple at most, given the short lifetime of cuda.bindings.path_finder.

Remove this file and the _path_finder subdirectory.

I do not think it's fine. We're following strict semver here, which means if you can publicly access something via cuda.bindings.path_finder that doesn't begin with an underscore that it is part of our API and we will not break it in bumping minor versions.

If this is only a temporary stopgap that we don't intend to survive until a release then that is fine.

I've added commit 58ca181, which fully sanitizes the cuda/bindings/path_finder.py module namespace. Retesting.

kkraus14 · 2025-07-11T18:11:23Z

This looks good to me, sans the one comment above about the visibility of things in the cuda.bindings.path_finder and avoiding accidentally introducing public APIs that we don't wish to support.

rwgk · 2025-07-11T20:11:33Z

/ok to test

rwgk · 2025-07-11T20:13:58Z

@kkraus14 I merged in main (SPDX changes) and put #751 as-is on top here: commit c0509be

Everything else is as before. I think this is ready for merging (pending completion of tests).

@leofang Merging is blocked by your request for changes, could you please help?

rwgk · 2025-07-11T23:48:08Z

I just added one more commit to this PR, just one extra line: eedf658

After reading up on publishing to PyPI, I'm guessing this is all that's needed on this end to publish cuda-pathfinder wheels to PyPI?

rwgk · 2025-07-12T04:39:32Z

I was thinking of making a release right after this is merged. This whole file is already deprecated per the README. I guess we could just add more underscores, would that be acceptable? Get Outlook for iOS<https://aka.ms/o0ukef>

________________________________ From: Keith Kraus ***@***.***> Sent: Friday, July 11, 2025 9:24:22 PM To: NVIDIA/cuda-python ***@***.***> Cc: Ralf Grosse Kunstleve ***@***.***>; Mention ***@***.***> Subject: Re: [NVIDIA/cuda-python] Move `pathfinder` to cuda-python top level (PR #723) @kkraus14 commented on this pull request.

________________________________ In cuda_bindings/cuda/bindings/path_finder.py<#723 (comment)>:

__all__ = [

"_load_nvidia_dynamic_library", "_SUPPORTED_LIBNAMES", ] I do not think it's fine. We're following strict semver here, which means if you can publicly access something via cuda.bindings.path_finder that doesn't begin with an underscore that it is part of our API and we will not break it in bumping minor versions. If this is only a temporary stopgap that we don't intend to survive until a release then that is fine. — Reply to this email directly, view it on GitHub<#723 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAFUZACZPGCREHK5PLRHQYT3ICEXNAVCNFSM6AAAAAB77RWJV2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTAMJSGYZTKMRRG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

…backward_compatibility.py, to fully sanitize path_finder.py

rwgk · 2025-07-12T17:17:18Z

/ok to test

rwgk added 15 commits June 22, 2025 11:09

Move files WITHOUT trying to make anything work.

fbdebfa

First pass changing imports from cuda.bindings → cuda.path_finder WIT…

731256d

…HOUT trying to make anything work.

Move README.md one level up.

6e0ec6c

Move find_sub_dirs.py → ../_utils/find_sub_dirs.py

07e1385

Move files from cuda_bindings/tests to cuda_path_finder/tests WITHOUT…

68aa8d5

… trying to make anything work.

First VERY ROUGH version of pyproject.toml

fafa998

Change imports in tests/ WITHOUT trying to make anything work.

4eff7d2

Clean up pyproject.toml (with the help of ChatGPT) WITHOUT trying to …

db0f540

…make anything work.

ruff automatic fix: Replace deprecated typing.Sequence with collectio…

9fea2e7

…ns.abc.Sequence (Python 3.9+)

Add dynamic = ["version"] in pyproject.toml and cuda/path_finder/__…

c494ef2

…init__.py (to make the dynamic version work).

Modernize [project] license line.

78b8c6d

Change dir/file names: path_finder → pathfinder

5690d96

Change imports: path_finder → pathfinder

81b9bd9

Fix up broken imports.

b9be5cb

add [project.optional-dependencies] test

79a8019

github-project-automation bot added this to CCCL Jun 24, 2025

github-project-automation bot moved this to Todo in CCCL Jun 24, 2025

leofang assigned rwgk Jun 24, 2025

leofang self-requested a review June 24, 2025 12:51

leofang added cuda.pathfinder Everything related to the cuda.pathfinder module enhancement Any code-related improvements P0 High priority - Must do! labels Jun 24, 2025

rwgk changed the title ~~Move path_finder to cuda-python top level~~ Move pathfinder to cuda-python top level Jun 24, 2025

rwgk added 2 commits June 24, 2025 17:18

Adopt cuda_core license.

975ba0b

cuda.pathfinder.nvidia_dynamic_libs.load_lib → cuda.pathfinder.load_n…

3678fb4

…vidia_dynamic_lib

shwina reviewed Jun 25, 2025

View reviewed changes

rwgk added 4 commits July 9, 2025 09:25

Make LoadedDL.handle an unsigned integer also for Windows. (cuda_path…

46fd972

…finder/tests pass, cuda_bindings/tests are broken). Interactive testing: CUDA_PATHFINDER_TEST_LOAD_NVIDIA_DYNAMIC_LIB_STRICTNESS=all_must_work pytest -ra -s -v tests/ python ../toolshed/run_cuda_pathfinder.py

Rename LoadedDL.handle → LoadedDL._handle_uint

428a2dc

This does not break any cuda_pathfinder tests. (cuda_bindings tests are "more broken".)

Move _handle_uint last in LoadedDL, to emphasize that this is pri…

4096885

…vate member.

Implement TEMPORARY BACKWARD COMPATIBILITY in /cuda/bindings/path_fin…

5e6c7e5

…der.py

rwgk dismissed kkraus14’s stale review via 5e6c7e5 July 9, 2025 17:15

Fix oversight discovered via local Windows testing.

d787a4c

Merge branch 'main' into move_path_finder_to_top

60918d5

rwgk mentioned this pull request Jul 9, 2025

[cuda_pathfinder] Remove win32api dependency (use ctypes instead). #751

Closed

kkraus14 reviewed Jul 11, 2025

View reviewed changes

rwgk added 2 commits July 11, 2025 12:10

Merge branch 'main' into move_path_finder_to_top

933a889

Put the changes from NVIDIA#751 on top of this PR (723)

c0509be

Add cuda-pathfinder to options in .github/workflows/release.yml

eedf658

Move temporary backward compatibility code to _path_finder/temporary_…

58ca181

…backward_compatibility.py, to fully sanitize path_finder.py

Move pathfinder to cuda-python top level #723

Are you sure you want to change the base?

Move pathfinder to cuda-python top level #723

Uh oh!

Conversation

rwgk commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

copy-pr-bot bot commented Jun 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shwina Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shwina Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

leofang Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk commented Jun 25, 2025

Uh oh!

shwina commented Jun 25, 2025

Uh oh!

leofang commented Jun 26, 2025

Uh oh!

rwgk commented Jul 8, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

kkraus14 commented Jul 9, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

kkraus14 commented Jul 9, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

rwgk commented Jul 9, 2025

Uh oh!

rwgk commented Jul 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkraus14 commented Jul 11, 2025

Uh oh!

rwgk commented Jul 11, 2025

Uh oh!

rwgk commented Jul 11, 2025

Uh oh!

rwgk commented Jul 11, 2025

Move `pathfinder` to cuda-python top level #723

Move `pathfinder` to cuda-python top level #723

rwgk commented Jun 24, 2025 •

edited

Loading

shwina Jun 25, 2025 •

edited

Loading

shwina Jun 25, 2025 •

edited

Loading

leofang Jun 25, 2025 •

edited

Loading