Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade google/benchmark to use nanobind-bazel v2.0.0 #1795

Closed

Conversation

nicholasjng
Copy link
Contributor

This enables binding extension builds with nanobind@v2.

Due to some backwards-incompatible changes in the treatment of enums, Counter::Flags (a flag-based enum) needs to be explicitly marked as arithmetic; setting flags is done as before with the logical "or" operator (now bound like any other class method as __or__(), the Python logical or operator slot).

The bindings changes were suggested by @hawkinsp in the corresponding issue on the repo, see #1790.


Fixes #1790.

This enables binding extension builds with nanobind@v2.

Due to some backwards-incompatible changes in the treatment of enums,
`Counter::Flags` (a flag-based enum) needs to be explicitly marked as
arithmetic; setting flags is done as before with the logical "or"
operator (now bound like any other class method as `__or__()`, the
Python logical or operator slot).

The bindings changes were suggested by @hawkinsp in the corresponding
issue on the repo, see google#1790.
@nicholasjng
Copy link
Contributor Author

Hm, this isn't working yet, I will investigate.

@nicholasjng
Copy link
Contributor Author

nicholasjng commented May 29, 2024

This line in nanobind's enum source:

https://github.com/wjakob/nanobind/blob/4ed5fdf80de460edc416c0e948d6e6c60e61a02a/src/nb_enum.cpp#L46

bases the newly created Flags on the IntEnum class if it's marked as arithmetic, that's presumably where the large negative value comes from in the CI logs.

There is currently a PR open on support for binding Flag enums wjakob/nanobind#599, I could imagine that is necessary to fix this error.

@nicholasjng
Copy link
Contributor Author

@hawkinsp also please let me know about your preferred attribution for these changes - I expect I'll have to tweak things a bit in the end, but I'd still like to give appropriate credit.

hawkinsp added a commit to hawkinsp/benchmark that referenced this pull request Jul 18, 2024
…bind 2.0.

Incorporates the nanobind_bazel change from google#1795.

nanobind 2.0 reworked the nanobind::enum_ class so it uses a real Python enum or intenum rather than its previous hand-rolled implementation.
google-deepmind/clrs#119 (comment)

As a consequence of that change, nanobind now checks when casting an integer to a enum value that the integer corresponds to a valid enum. Counter::Flags is a bitmask, and many combinations are not valid enum members.

This change:
a) sets nb::is_arithmetic(), which means Counter::Flags becomes an IntEnum that can be freely cast to an integer.
b) defines the | operator for flags to return an integer, not an enum, avoiding the error.
c) changes Counter's constructor to accept an int, not a Counter::Flags enum. Since Counter::Flags is an IntEnum now, it can be freely coerced to an int.

If wjakob/nanobind#599 is merged into nanobind, then we can perhaps use a flag enum here instead.
hawkinsp added a commit to hawkinsp/benchmark that referenced this pull request Jul 18, 2024
…bind 2.0.

Incorporates the nanobind_bazel change from google#1795.

nanobind 2.0 reworked the nanobind::enum_ class so it uses a real Python enum or intenum rather than its previous hand-rolled implementation.
https://nanobind.readthedocs.io/en/latest/changelog.html#version-2-0-0-may-23-2024

As a consequence of that change, nanobind now checks when casting an integer to a enum value that the integer corresponds to a valid enum. Counter::Flags is a bitmask, and many combinations are not valid enum members.

This change:
a) sets nb::is_arithmetic(), which means Counter::Flags becomes an IntEnum that can be freely cast to an integer.
b) defines the | operator for flags to return an integer, not an enum, avoiding the error.
c) changes Counter's constructor to accept an int, not a Counter::Flags enum. Since Counter::Flags is an IntEnum now, it can be freely coerced to an int.

If wjakob/nanobind#599 is merged into nanobind, then we can perhaps use a flag enum here instead.
hawkinsp added a commit to hawkinsp/benchmark that referenced this pull request Jul 18, 2024
…bind 2.0.

Incorporates the nanobind_bazel change from google#1795.

nanobind 2.0 reworked the nanobind::enum_ class so it uses a real Python enum or intenum rather than its previous hand-rolled implementation.
https://nanobind.readthedocs.io/en/latest/changelog.html#version-2-0-0-may-23-2024

As a consequence of that change, nanobind now checks when casting an integer to a enum value that the integer corresponds to a valid enum. Counter::Flags is a bitmask, and many combinations are not valid enum members.

This change:
a) sets nb::is_arithmetic(), which means Counter::Flags becomes an IntEnum that can be freely cast to an integer.
b) defines the | operator for flags to return an integer, not an enum, avoiding the error.
c) changes Counter's constructor to accept an int, not a Counter::Flags enum. Since Counter::Flags is an IntEnum now, it can be freely coerced to an int.

If wjakob/nanobind#599 is merged into nanobind, then we can perhaps use a flag enum here instead.
hawkinsp added a commit to hawkinsp/benchmark that referenced this pull request Jul 18, 2024
…bind 2.0.

Incorporates the nanobind_bazel change from google#1795.

nanobind 2.0 reworked the nanobind::enum_ class so it uses a real Python enum or intenum rather than its previous hand-rolled implementation.
https://nanobind.readthedocs.io/en/latest/changelog.html#version-2-0-0-may-23-2024

As a consequence of that change, nanobind now checks when casting an integer to a enum value that the integer corresponds to a valid enum. Counter::Flags is a bitmask, and many combinations are not valid enum members.

This change:
a) sets nb::is_arithmetic(), which means Counter::Flags becomes an IntEnum that can be freely cast to an integer.
b) defines the | operator for flags to return an integer, not an enum, avoiding the error.
c) changes Counter's constructor to accept an int, not a Counter::Flags enum. Since Counter::Flags is an IntEnum now, it can be freely coerced to an int.

If wjakob/nanobind#599 is merged into nanobind, then we can perhaps use a flag enum here instead.
dmah42 pushed a commit that referenced this pull request Jul 18, 2024
…bind 2.0. (#1817)

Incorporates the nanobind_bazel change from #1795.

nanobind 2.0 reworked the nanobind::enum_ class so it uses a real Python enum or intenum rather than its previous hand-rolled implementation.
https://nanobind.readthedocs.io/en/latest/changelog.html#version-2-0-0-may-23-2024

As a consequence of that change, nanobind now checks when casting an integer to a enum value that the integer corresponds to a valid enum. Counter::Flags is a bitmask, and many combinations are not valid enum members.

This change:
a) sets nb::is_arithmetic(), which means Counter::Flags becomes an IntEnum that can be freely cast to an integer.
b) defines the | operator for flags to return an integer, not an enum, avoiding the error.
c) changes Counter's constructor to accept an int, not a Counter::Flags enum. Since Counter::Flags is an IntEnum now, it can be freely coerced to an int.

If wjakob/nanobind#599 is merged into nanobind, then we can perhaps use a flag enum here instead.
@hawkinsp
Copy link
Member

Thanks, the nanobind_bazel change in the PR that was merged was from this PR (and the nanobind_bazel change itself).

@nicholasjng
Copy link
Contributor Author

nicholasjng commented Jul 18, 2024

yup, I saw. Hoping to release the stubgen rule in nanobind-bazel soon, then we will have IDE completions for benchmarks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update nanobind to v2.0
2 participants