[ExecuTorch][#10375] Add `extension.BundledModule` to Wrap `extension.Module` with Bundled Program Logic by zhenyan-zhang-meta · Pull Request #10449 · pytorch/executorch

zhenyan-zhang-meta · 2025-04-24T21:29:33Z

Stack from ghstack (oldest at bottom):

-> [ExecuTorch][#10375] Add extension.BundledModule to Wrap extension.Module with Bundled Program Logic #10449

Context

This issue is a step of #9638.

In #9638, we want to have extension.Module as the single source of implementation in pybindings, which means that pybindings.PyModule should use extension.Module rather than its own pybindings.Module.

The issue is that pybindings.PyModule is dependent on the method getter from pybindings.Module, which extension.Module do not have. Since we don't want to expose method getter in extension.Module, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple pybindings from a method getter.

Proposal

Now that we have a protected method getter, we can introduce a extension.BundledModule, a child class inheriting extension.Module which wraps up bundled program logic that is dependent on the method getter.

Differential Revision: D73564125

….Module` with Bundled Program Logic #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

….Module` with Bundled Program Logic #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) ghstack-source-id: 279969988 Pull Request resolved: #10449

pytorch-bot · 2025-04-24T21:29:37Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/10449

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure

As of commit 54cf39f with merge base 9febabd ():

NEW FAILURE - The following job has failed:

.github/workflows/build-presets.yml (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

facebook-github-bot · 2025-04-24T21:29:41Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-24T21:53:00Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-24T23:25:13Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-29T00:57:12Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

….Module` with Bundled Program Logic Pull Request resolved: #10449 #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. ghstack-source-id: 281069665 Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/)

facebook-github-bot · 2025-04-29T23:54:02Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T01:03:03Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T01:29:53Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T01:55:47Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T02:15:19Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T02:57:08Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T05:44:29Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T07:30:10Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-04-30T18:19:10Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

facebook-github-bot · 2025-05-05T17:44:19Z

This pull request was exported from Phabricator. Differential Revision: D73564125

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

….Module` with Bundled Program Logic Pull Request resolved: #10449 #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce an `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. We are also introducing ctests and a file-path-based factory function constructor. ghstack-source-id: 282080273 Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/)

facebook-github-bot · 2025-05-05T18:32:24Z

This pull request was exported from Phabricator. Differential Revision: D73564125

Gasoonjia

current version is good enough for unblocking our requirement. Thanks @zhenyan-zhang-meta for your great work!

Gasoonjia · 2025-05-06T16:20:50Z

+          std::move(data_map_loader)),
+      bundled_program_ptr_(bundled_program_ptr) {}
+
+runtime::Result<std::unique_ptr<BundledModule>> BundledModule::from_file(


It would be great if we can follow the extension.module's pattern, which uses constructor instead of factory function, and leverage is_loaded function for sanity check.

Yeah we can follow up in another PR to iterate on it. Will land this diff as discussed and write up potential improvements in #10375.

… `extension.Module` with Bundled Program Logic" #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce a `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/) [ghstack-poisoned]

….Module` with Bundled Program Logic Pull Request resolved: #10449 #10375 # Context This issue is a step of #9638. In #9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce an `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. We are also introducing ctests and a file-path-based factory function constructor. ghstack-source-id: 282374587 Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/)

facebook-github-bot · 2025-05-06T21:06:17Z

This pull request was exported from Phabricator. Differential Revision: D73564125

….Module` with Bundled Program Logic Pull Request resolved: pytorch/executorch#10449 pytorch/executorch#10375 # Context This issue is a step of pytorch/executorch#9638. In pytorch/executorch#9638, we want to have `extension.Module` as the single source of implementation in `pybindings`, which means that `pybindings.PyModule` should use `extension.Module` rather than its own `pybindings.Module`. The issue is that `pybindings.PyModule` is dependent on the `method` getter from `pybindings.Module`, which `extension.Module` do not have. Since we don't want to expose `method` getter in `extension.Module`, we have to protect the getter, wrap the functions that is dependent on it and use the protected getter there, ultimately decouple `pybindings` from a `method` getter. # Proposal Now that we have a protected `method` getter, we can introduce an `extension.BundledModule`, a child class inheriting `extension.Module` which wraps up bundled program logic that is dependent on the `method` getter. We are also introducing ctests and a file-path-based factory function constructor. ghstack-source-id: 282066737 Differential Revision: [D73564125](https://our.internmc.facebook.com/intern/diff/D73564125/)

zhenyan-zhang-meta requested review from Gasoonjia, shoumikhin and tarun292 as code owners April 24, 2025 21:29

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Apr 24, 2025

zhenyan-zhang-meta self-assigned this Apr 24, 2025

zhenyan-zhang-meta added the topic: not user facing label Apr 24, 2025

zhenyan-zhang-meta mentioned this pull request Apr 24, 2025

[ExecuTorch][#10447] Extend PyBundledModule with extension.BundledModule #10450

Closed

facebook-github-bot added the fb-exported label Apr 24, 2025

zhenyan-zhang-meta mentioned this pull request Apr 30, 2025

[ExecuTorch] Separate extension.Module Namespaces from Aten and non-Aten #10576

Closed

Gasoonjia approved these changes May 6, 2025

View reviewed changes

facebook-github-bot merged commit 6e118f2 into gh/zhenyan-zhang-meta/5/base May 7, 2025

facebook-github-bot deleted the gh/zhenyan-zhang-meta/5/head branch May 7, 2025 02:53

facebook-github-bot temporarily deployed to cherry-pick-bot May 7, 2025 02:53 — with GitHub Actions Inactive

pytorchbot mentioned this pull request May 7, 2025

[ExecuTorch][#10375] Add extension.BundledModule to Wrap extension.Module with Bundled Program Logic #10744

Merged

zhenyan-zhang-meta added release notes: devtools Changes to dev tooling, for example the debugger & profiler and removed topic: not user facing labels May 12, 2025

Conversation

zhenyan-zhang-meta commented Apr 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Proposal

Uh oh!

pytorch-bot Bot commented Apr 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/10449

❌ 1 New Failure

Uh oh!

facebook-github-bot commented Apr 24, 2025

Uh oh!

facebook-github-bot commented Apr 24, 2025

Uh oh!

facebook-github-bot commented Apr 24, 2025

Uh oh!

facebook-github-bot commented Apr 29, 2025

Uh oh!

facebook-github-bot commented Apr 29, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented Apr 30, 2025

Uh oh!

facebook-github-bot commented May 5, 2025

Uh oh!

facebook-github-bot commented May 5, 2025

Uh oh!

Gasoonjia left a comment

Choose a reason for hiding this comment

Uh oh!

Gasoonjia May 6, 2025

Choose a reason for hiding this comment

Uh oh!

zhenyan-zhang-meta May 6, 2025

Choose a reason for hiding this comment

Uh oh!

facebook-github-bot commented May 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zhenyan-zhang-meta commented Apr 24, 2025 •

edited

Loading

pytorch-bot Bot commented Apr 24, 2025 •

edited

Loading