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.) A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
