I find pypy translator output c files consist too many 'goto' statement. Its hard to read and understand these c files. I try to make it output with c keywords: if..else.. while...break...continue and now the output c file looks pretty better. my pypy version is pypy-pypy-2346207d9946 download from: https://bitbucket.org/pypy/pypy/get/release-1.8.zip test sample input file a2.py: import sys def entry_point(argv): a = [1,2,3,4] a.extend([4,5]) print a return len(a) def target(*args): return entry_point, None if __name__ == '__main__': entry_point(sys.argv) after run command: translator\goal\translate.py a2.py I can find file a2.c in my temperary directory. The funcion pypy_g_entry_point in it is 662 lines and contains 103 goto. after replace 2 attach files : pypy\translator\c\funcgen.py pypy\translator\c\bookaa_cpp.py and run the command again, I get a2.c with pypy_g_entry_point is 539 lines and only contains 20 goto. I am still work hard try to improve pypy to get readable c++ output. Anyone interest in this ? Bookaa
On Fri, Apr 20, 2012 at 6:13 AM, gmail <rorsoft@gmail.com> wrote:
** I find pypy translator output c files consist too many 'goto' statement. Its hard to read and understand these c files. I try to make it output with c keywords: if..else.. while...break...continue and now the output c file looks pretty better.
my pypy version is pypy-pypy-2346207d9946 download from: https://bitbucket.org/pypy/pypy/get/release-1.8.zip
test sample input file a2.py:
import sys
def entry_point(argv): a = [1,2,3,4] a.extend([4,5]) print a return len(a)
def target(*args): return entry_point, None
if __name__ == '__main__': entry_point(sys.argv)
after run command: translator\goal\translate.py a2.py
I can find file a2.c in my temperary directory. The funcion pypy_g_entry_point in it is 662 lines and contains 103 goto.
after replace 2 attach files : pypy\translator\c\funcgen.py pypy\translator\c\bookaa_cpp.py and run the command again, I get a2.c with pypy_g_entry_point is 539 lines and only contains 20 goto.
I am still work hard try to improve pypy to get readable c++ output. Anyone interest in this ?
Bookaa
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Hi. Your code does not contain any tests - we won't accept code that's untested. Second, please send your patches in diff format so we can have a better look on what you have changed (hg diff sounds like a good plan) Cheers, fijal
What is the purpose? For the target c/c++ compiler it is all the same, is not it? Or is the purpose to make a python->c++ converter? Cheers, Alex perjantai 20 huhtikuu 2012 09:09:12 Maciej Fijalkowski kirjoitti: On Fri, Apr 20, 2012 at 6:13 AM, gmail <rorsoft@gmail.com> wrote: I find pypy translator output c files consist too many 'goto' statement. Its hard to read and understand these c files. I try to make it output with c keywords: if..else.. while...break...continue and now the output c file looks pretty better. my pypy version is pypy-pypy-2346207d9946 download from: https://bitbucket.org/pypy/pypy/get/release-1.8.zip test sample input file a2.py: import sys def entry_point(argv): a = [1,2,3,4] a.extend([4,5]) print a return len(a) def target(*args): return entry_point, None if __name__ == '__main__': entry_point(sys.argv) after run command: translator\goal\translate.py a2.py I can find file a2.c in my temperary directory. The funcion pypy_g_entry_point in it is 662 lines and contains 103 goto. after replace 2 attach files : pypy\translator\c\funcgen.py pypy\translator\c\bookaa_cpp.py and run the command again, I get a2.c with pypy_g_entry_point is 539 lines and only contains 20 goto. I am still work hard try to improve pypy to get readable c++ output. Anyone interest in this ? Bookaa _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev Hi. Your code does not contain any tests - we won't accept code that's untested. Second, please send your patches in diff format so we can have a better look on what you have changed (hg diff sounds like a good plan) Cheers, fijal
yes, pypy's output c files is enough for c compilers. But its terrible if you want to read the c source codes. I really very interest in make a python to c++ converter, based on pypy translator. thanks Bookaa From: Alexander Pyattaev Sent: Saturday, April 21, 2012 6:54 AM To: pypy-dev@python.org Subject: Re: [pypy-dev] output readable c What is the purpose? For the target c/c++ compiler it is all the same, is not it? Or is the purpose to make a python->c++ converter? Cheers, Alex perjantai 20 huhtikuu 2012 09:09:12 Maciej Fijalkowski kirjoitti: On Fri, Apr 20, 2012 at 6:13 AM, gmail <rorsoft@gmail.com> wrote: I find pypy translator output c files consist too many 'goto' statement. Its hard to read and understand these c files. I try to make it output with c keywords: if..else.. while...break...continue and now the output c file looks pretty better. my pypy version is pypy-pypy-2346207d9946 download from: https://bitbucket.org/pypy/pypy/get/release-1.8.zip test sample input file a2.py: import sys def entry_point(argv): a = [1,2,3,4] a.extend([4,5]) print a return len(a) def target(*args): return entry_point, None if __name__ == '__main__': entry_point(sys.argv) after run command: translator\goal\translate.py a2.py I can find file a2.c in my temperary directory. The funcion pypy_g_entry_point in it is 662 lines and contains 103 goto. after replace 2 attach files : pypy\translator\c\funcgen.py pypy\translator\c\bookaa_cpp.py and run the command again, I get a2.c with pypy_g_entry_point is 539 lines and only contains 20 goto. I am still work hard try to improve pypy to get readable c++ output. Anyone interest in this ? Bookaa _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev Hi. Your code does not contain any tests - we won't accept code that's untested. Second, please send your patches in diff format so we can have a better look on what you have changed (hg diff sounds like a good plan) Cheers, fijal -------------------------------------------------------------------------------- _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
2012/4/20 gmail <rorsoft@gmail.com>
I am still work hard try to improve pypy to get readable c++ output. Anyone interest in this ?
The result is much better, especially with long functions. Yes, this is interesting! Continue! Your code needs to be polished though: comments, better names, pep8 convention... And also an explanation of the algorithms. Try to run the tests, you will see a missing import, and some tests fail (in translator/c/test/test_backendoptimized.py, the ones with "switch") Also I've seen a duplicate label when translating targetnopstandalone.py fijal, I don't think it's easy to write tests for funcgen. Or maybe only count the goto statements, like JIT tests count external calls? In the end someone will have to check the generated assembler in some cases. I remember that the "_back" labels were added to have loops look like loops, and help gcc. -- Amaury Forgeot d'Arc
thank you for encourage! as for the bugs, please tell me exacty how to run, which test. My system is Win7, pypy tests get many error even without any change. Bookaa From: Amaury Forgeot d'Arc Sent: Saturday, April 21, 2012 7:48 AM To: gmail Cc: pypy-dev@python.org Subject: Re: [pypy-dev] output readable c 2012/4/20 gmail <rorsoft@gmail.com> I am still work hard try to improve pypy to get readable c++ output. Anyone interest in this ? The result is much better, especially with long functions. Yes, this is interesting! Continue! Your code needs to be polished though: comments, better names, pep8 convention... And also an explanation of the algorithms. Try to run the tests, you will see a missing import, and some tests fail (in translator/c/test/test_backendoptimized.py, the ones with "switch") Also I've seen a duplicate label when translating targetnopstandalone.py fijal, I don't think it's easy to write tests for funcgen. Or maybe only count the goto statements, like JIT tests count external calls? In the end someone will have to check the generated assembler in some cases. I remember that the "_back" labels were added to have loops look like loops, and help gcc. -- Amaury Forgeot d'Arc -------------------------------------------------------------------------------- _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
2012/4/21 bookaa <rorsoft@gmail.com>
** thank you for encourage!
as for the bugs, please tell me exacty how to run, which test.
My system is Win7, pypy tests get many error even without any change.
Tests in the translator/c directory should pass. For example: c:\python27\python pytest.py pypy\translator\c\test\test_backendoptimized.py And to translate the small (!) "hello world" target: c:\python27\python pypy\translator\goal\translate.py -O2 pypy\translator\goal\targetnopstandalone.py -- Amaury Forgeot d'Arc
Now I can pass the test_backendoptimized and targetnopstandalone. Files attached. Please tell me if any bugs thanks Bookaa From: Amaury Forgeot d'Arc Sent: Saturday, April 21, 2012 3:51 PM To: bookaa Cc: pypy-dev@python.org Subject: Re: [pypy-dev] output readable c 2012/4/21 bookaa <rorsoft@gmail.com> thank you for encourage! as for the bugs, please tell me exacty how to run, which test. My system is Win7, pypy tests get many error even without any change. Tests in the translator/c directory should pass. For example: c:\python27\python pytest.py pypy\translator\c\test\test_backendoptimized.py And to translate the small (!) "hello world" target: c:\python27\python pypy\translator\goal\translate.py -O2 pypy\translator\goal\targetnopstandalone.py -- Amaury Forgeot d'Arc
Hi. I would really like this sort of changes to come with it's own tests (ones that check what was compiled preferably). On Sun, Apr 22, 2012 at 7:01 AM, bookaa <bookaa@rorsoft.com> wrote:
** Now I can pass the test_backendoptimized and targetnopstandalone.
Files attached.
Please tell me if any bugs
thanks
Bookaa
*From:* Amaury Forgeot d'Arc <amauryfa@gmail.com> *Sent:* Saturday, April 21, 2012 3:51 PM *To:* bookaa <rorsoft@gmail.com> *Cc:* pypy-dev@python.org *Subject:* Re: [pypy-dev] output readable c
2012/4/21 bookaa <rorsoft@gmail.com>
** thank you for encourage!
as for the bugs, please tell me exacty how to run, which test.
My system is Win7, pypy tests get many error even without any change.
Tests in the translator/c directory should pass. For example:
c:\python27\python pytest.py pypy\translator\c\test\test_backendoptimized.py
And to translate the small (!) "hello world" target:
c:\python27\python pypy\translator\goal\translate.py -O2 pypy\translator\goal\targetnopstandalone.py
-- Amaury Forgeot d'Arc
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
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? That is, how would they be different than tests which demonstrate that the current translation code is correct? (Are there translation-only unit tests for the current translator?) Wouldn't passing the existing tests be sufficient? I'm not at all familiar with the current code base, so I might be way off-base here. If so, my apologies. -- Skip Montanaro - skip@pobox.com - http://www.smontanaro.net/
Hi, On Mon, Apr 23, 2012 at 01:35, <skip@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.
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
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, <skip@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.Pfannschmidt@gmail.com to help with getting into hg and the workflows pypy uses for development/contribution -- Ronny
participants (10)
-
Alexander Pyattaev -
Amaury Forgeot d'Arc -
Antonio Cuni -
Armin Rigo -
bookaa -
bookaa -
gmail
-
Maciej Fijalkowski -
Ronny Pfannschmidt -
skip＠pobox.com