somehow bookaa was removed from the recipient list, so a quick rehearsal
with him added again
Armin wrote:
Hi,
On Mon, Apr 23, 2012 at 01:35, <s...@pobox.com> wrote:
Maciej> I would really like this sort of changes to come with it's own
Maciej> tests (ones that check what was compiled preferably).
What might such tests look like?
It is an issue: unit-testing this kind of "detail" is a bit hard, I
agree. And the sheer size of the proposed new file is daunting:
unless I'm wrong it is *bigger* than any other file in translator/c/.
There is still something we could do. For a start, making sure that
*all* tests pass everywhere, not just test_backendoptimized; including
a complete pypy translation, and including the fact that the
translated pypy seems to behave correctly (i.e. runs its own tests
fine). Then someone needs to make additional tests that stress all
branches in the new code --- additions in the same style as
test_backendoptimized, but written specifically to test uncommon paths
in your code. This is useful even if it only tests that the C
compiler is happy with the generated code and the generated code
behaves correctly.
Bookaa, the person to do that can be you. In that case you need to
learn about Mercurial version control and the http://bitbucket.org
repository. I would recommend that you register on bitbucket, and
create your own fork of "pypy/pypy" to play with. If you don't want
to do that, I fear that your code will remain unaccepted, unless
someone else jumps in and does it. (In all cases, in a fork, please.)
We cannot just take such a large file into the official pypy and be
happy. Fwiw we have a few pending bugs of the JIT optimizer's
unroller, which is another big piece of code full of "ifs" with
incomplete test coverage. I'm not harshly criticising, because in
that case the functionality (=speed) is great for the end user; but in
your situation you have to realize that it would be adding no
functionality at all for the end user, i.e. the user of PyPy. (I
don't consider making it easier to read the C code to be an additional
feature; if someone needs to read it, he is either busy chasing a
really obscure bug of the JIT or the GC (like me, about once a year),
or, more likely, he didn't properly test his source code.)
On 04/23/2012 05:30 PM, Antonio Cuni wrote:
Hi Bookaa,
On 04/23/2012 08:19 AM, Armin Rigo wrote:
Bookaa, the person to do that can be you. In that case you need to
learn about Mercurial version control and the http://bitbucket.org
repository. I would recommend that you register on bitbucket, and
create your own fork of "pypy/pypy" to play with. If you don't want
to do that, I fear that your code will remain unaccepted, unless
someone else jumps in and does it. (In all cases, in a fork, please.)
just an additional suggestion: even if you do a fork of pypy, make sure to do
your work inside a named branch (e.g. "better-c-sources" or something like
that). This way it's much easier for us to pull your code into the main pypy
repo and run all the tests using our buildbot.
ciao,
Anto
and as an additional note,
i'm available on irc or gtalk as ronny.pfannschm...@gmail.com to help
with getting into hg and the workflows pypy uses for
development/contribution
-- Ronny
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
