Ivzhh updated this revision to Diff 6724.
Ivzhh added a comment.
- merge with stable
- translate base85.c into rust code
- move hgbase85 into independent module
- add hgstorage crate
- hg status implementation in rust
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST UPDATE
Ivzhh added a comment.
Thank you @indygreg!
The OxidationPlan is my best reference when I started to make a move, and
this thread is even more helpful. I am really interested in exploring this ;-)
In 2014 I was trying to change the hg backend storage to Postgres, a silly and
failed
indygreg added a comment.
To be honest, we're not yet sure what we'll decide for the Python -> Rust
bridge. The problem is summarized in the `Rust <=> Python Interop` section on
https://www.mercurial-scm.org/wiki/OxidationPlan.
I suspect at some level we'll need a CPython extension for
Ivzhh added a comment.
As the author of this patch, actually I have the same concern. I started to
translate base85 as baby steps to find a way of integrating rust and cpython,
on my side, Today I modify setup.py, policy.py and makefile to run hg's test
suit with the new base85. For myself,
krbullock added a comment.
What would be the advantage of taking this? Since we already have the C
implementation, it's not likely to gain us any performance. On the other hand,
it might make a good test case for integrating Rust and Python, finding the
right API boundaries and
kevincox added a comment.
I agree with the splitting comments :) In fact there might already be a
base85 crate which can be used: https://docs.rs/zero85. Either way I'll hold
off on the review, feel free to ping me when you are ready for me to take a
look.
REPOSITORY
rHG Mercurial
Ivzhh added a comment.
Thank you @indygreg for your detailed explanation!
I understand the process now, and I will go back reading the developer's
guide thoroughly again. I will try my best to provide a relatively clean stack
of patches.
Thank you for you time!
REPOSITORY
rHG
indygreg added a comment.
We generally prefer that patches to Mercurial be small and do a single thing.
This makes it easier to review and understand changes, since each change can be
evaluated in isolation. If you submit changesets together using `hg phabsend`,
they automatically show up
Ivzhh added a comment.
Sure, thank you for the comments! I can definitely prepare makefile and
setup.py to make the building process work with rust part. I am planning to
change the policy.py module to support and try to load rust modules and run all
the tests. I will submit a new patch
indygreg added a comment.
Yes, we should definitely split things into multiple crates. Small,
narrowly-focused crates does seem to be the Rust way, after all.
`hgcli` should be for things specific to the Rust implementation of `hg`. I
think this can also include the feature set of `chg`
Ivzhh added a comment.
I am open to the three-crates plan. Oirginally I have hgcli and hgext
separately, and I was planning to replace CFFI. I am a pypy user too, so I will
be willing to provide a python C API free crate for pypy and others.
REPOSITORY
rHG Mercurial
REVISION DETAIL
durin42 added a subscriber: indygreg.
durin42 added a comment.
I'd be curious to see what @indygreg has to say about this, maybe wait on his
input before doing any work in response to my feedback?
I do wonder if we should have at least three crates:
1. hgcli
2. libmercurial
3.
Ivzhh created this revision.
Herald added subscribers: mercurial-devel, kevincox, durin42.
Herald added a reviewer: hg-reviewers.
REVISION SUMMARY
- python extension to encode/decode base85
- add test suits to call encode/decode base85 in rust-/python- convention
- add proper python
13 matches
Mail list logo
