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 environm
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
http
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 afte
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 Mer
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,
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 expe
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
https://phab
Ivzhh added a comment.
Hi all,
Based on the discussion a few weeks ago, I come up with a solution for review
and discussion. After reading the Oxidation plan, the first thought is to
bypass python engine and current plugin system IFF on request. If user (maybe
background checker of IDE)
Ivzhh added a comment.
Hi everyone,
Thank you for your encouragements and comments! I will follow up with all
comments and update the code soon.
@indygreg It is a great idea to test on Mozilla repo, actually I found
several things interesting:
1. I found a bug in my code (shame
Ivzhh added a comment.
In https://phab.mercurial-scm.org/D2057#44269, @yuja wrote:
> >> Reading that page it seems to claim that filenames should be utf8, not
bytes. If utf8, this is what the code does, but if it is bytes that definitely
won't work.
> >
> > IIRC it's bytes everyplac
Ivzhh updated this revision to Diff 7188.
Ivzhh added a comment.
- add revlog and mpatch facilities
- add changelog parsing
- add manifest parsing
- path encoding for data store
- add dirstate and matcher facilities
- add local repository and the supporting modules
- use cargo fmt t
Ivzhh marked 45 inline comments as done.
Ivzhh added inline comments.
INLINE COMMENTS
> kevincox wrote in base85.rs:23
> `&str` can only hold valid utf8 data? Does it make more sense to have `&[u8]`
> here for a list of bytes?
It should be any &[u8], but the current cpython crate doesn't wrap f
Ivzhh marked 4 inline comments as done.
Ivzhh added a comment.
In https://phab.mercurial-scm.org/D2057#46726, @yuja wrote:
> >> I think the only place where you would need to do os-specific code is
when
> >> doing serialization and serialization
> >
> > Yes, that will be feasible
13 matches
Mail list logo
