- Feb 21, 2025
-
-
Mitchell Kember authored
This means that lints configured in rust/Cargo.toml will apply to all crates within the workspace. Currently there are none but I plan to add some.
-
- Feb 18, 2025
-
-
Raphaël Gomès authored
This is the last module left to migrate to PyO3 from rust-cpython. We will remove the rust-cpython code at the start of the next cycle.
-
- Jan 06, 2025
-
-
Raphaël Gomès authored
This is useful when debugging/light instrumentation, we already use it all the time in other packages.
-
- Jan 07, 2025
-
-
Raphaël Gomès authored
These dependencies are not needed anymore, so trim them down.
-
- Dec 15, 2024
-
-
Georges Racinet authored
At this point, we have a full translation, with some tests. The tests are high level, demonstrating the case of iterating over `HashSet` as a doctest. The assertions are written as Python statements, in order not to be obscure and to resist later refactorings. The rust-cpython integration tests will be ported in a subsequent changeset. We find the example of iterating over `HashSet` to be more convincing than the iterating over `Vec`, the example provided in rust-cpython, because in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and an index. This would of course be reimplementing the iterator, but is simple enough that it leads the reader to believe that having a reference is the problem, whereas the problem is having a reference that is itself enclosed in a type with lifetime that can be arbitrary complex. It took us some time to remember that subtlety, and hence we reworded the documentation to stress that point. We decided to put this work a separate crate, which makes running `cargo test` work for the crate, but not for the entire workspace: the `extension-module` feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as default and run the tests with `--no-default-feature` in Makefile, hence in CI. An important difference with rust-cpython is that everything has to be `Sync`, hence we replace `RefCell` with `RwLock` and only speak of "interior mutability" in the documentation. Since everything happens in `hg-pyo3` behind the GIL, there is at this point no reason to use `read()` and `write()` instead of respectively `try_read()` and `try_write()`. But PyO3 is aiming to support free-threaded Python (without GIL), and `PySharedRef` should therefore allow waiting for its inner locks.
-
- Dec 05, 2024
-
-
Georges Racinet authored
The nice thing is that with PyO3, exceptions can be instantiated without holding the GIL. Hence the only thing that prevents us to implement `Into<PyErr>` for `hg::GraphError` is that neither is defined by the current crate. We could use a wrapping "newtype", but the compiler is not so clever yet that it could chain automatically to two needed `into()`, so we'll end up with some type conversion anyway, involving something like `GraphErrorWrapper`. At this point, explicitly named methods are just simpler.
-
- Nov 30, 2024
-
-
Georges Racinet authored
This allows PyO3-based code to use the InnerRevlog, access its shared data (core InnerRevlog), which will then allow, e.g., to retrieve references on the core Index. On the `hg-cpython` (`rusthg` crate, `rustext` Python extension module), we had to also build as a Rust library, and open up some accesses (see notably the public accessor for `inner`, the core `InnerRevlog`). Retrieving the Rust struct underlying a Python object defined by another extension module written in Rust is tricky because the Python type objects are duplicated in the extension modules, leading to failure of the normal type checking. See the doc-comment of `convert_cpython::extract_inner_revlog` for a complete explanation. To solve this, we import the Python type object of `rustext` (defined by `hg-cpython`) and perform a manual check. Checking the Python type is necessary, as PyO3 documentation clearly state that downcasting an object that has not the proper type is Undefined Behaviour. At this point, we do not have conversion facilities for exceptions (`PyErr` on both sides), hence the remaining unwraps).
-
Georges Racinet authored
Although the PyO3 API is indeed nicer and has derive macros, we still need the collection helpers. The `Result` issue is not very relevant any more, however the checking of incoming revisions for Python definitely is.
-
- Nov 20, 2024
-
-
Georges Racinet authored
Comes with significant API changes.
-
- Nov 27, 2023
-
-
Raphaël Gomès authored
Rebased by gracinet on top of cleanups for the Mercurial 7.0 development cycle.
-