Issue: import error on newest pypy on push (with hg-git resp. dulwich as extension)

Sergey Brester serg.brester at sebres.de
Wed Jun 3 02:15:37 CDT 2015


 

I use pypy, because for example by push from large hg-repo to large
git-repo (hg-git + dulwich) using cpython, I can wait sometimes up to
serveral minutes (dependent on commit size). With pypy the same is ready
in few seconds.
Additionaly, modern pypy jit wurm up very quickly and it byte code will
be written (.pyc-file) by pypy also. 

But pypy or not, such issue can occur on cpython also (for example using
any hg-extension module). 

I think, it can be possible if one class will be imported via complex
path and `fromlist` together: 

 from A.B import C 

Or because A.B is imported twice and it loses the first one? But I
think, it misses `mod.extend` somewhere in demandimport... 

Regards, sebres. 

02.06.2015 22:43, wrote Matt Mackall: 

> On Tue, 2015-06-02 at 21:49 +0200, Sergey Brester wrote:
> 02.06.2015 21:20, wrote Matt Mackall: On Tue, 2015-06-02 at 20:22 +0200, Sergey Brester wrote: Hi, I have found (and little bit researched) an annoying bug with demandimport-module: Demand import error on newest pypy on push (with hg-git resp. dulwich as extension).

> Pypy = not supported. It's currently a good way to get a significantly slower, less reliable Mercurial.
 Not supported - Ok. But "pypy = slower as python"? Ha-ha-ha. I can
understand "reliable", but slower... Don't believe and never will... 

Well.. you could just try it. Mercurial is not a pure Python program. It
has a bunch of carefully optimized C extensions. If you use Pypy, it has
to use the pure Python version of this code.. which is not match for the
C code even after passing through Pypy. And it has to recompile /
optimize itself every time you run it, which means quick commands like
"status" are going to be dominated by start-up time.

Mercurial doesn't run on Pypy by accident. Various people including Pypy
developers have spent significant time getting it to run on Pypy and
discovered it wasn't useful for performance. What it's mostly useful for
is a benchmark of where Pypy could be better.

> Suggested workaround resp. fix with small test case can be found on https://github.com/sebres/hg/pull/1 [1] [1] [1] No one's ever tried submitting a github pull request to hg before, so bravo, sir, on your creative trollin'.
 Bravo, sir, such treatment to "contributor", even if it gone "wrong"
for the contribution, you will still lose the last other also. 

Oh, you weren't doing it to be funny? My bad.

 

Links:
------
[1] https://github.com/sebres/hg/pull/1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150603/ff6a4089/attachment.html>


More information about the Mercurial-devel mailing list