Ugh, hit the wrong reply button. On 24 December 2012 19:24, William ML Leslie <william.leslie.ttg@gmail.com> wrote:
-- William Leslie
On Mon, Dec 24, 2012 at 11:24 AM, William ML Leslie < william.leslie.ttg@gmail.com> wrote:
But it is still confusing, because the RPython doesn't include generators, which means Python implementation is still written in subset of Python and not using the real full fat Python.
I looks like the documentation is missing one more important aspect - RPython toolchain can be used to compile standalone programs written in RPython (which is why I've finally got to it at the moment).
Hi Anatoly, On Mon, Dec 24, 2012 at 9:35 AM, anatoly techtonik <techtonik@gmail.com> wrote:
But it is still confusing, because the RPython doesn't include generators,
I see your point --- but RPython does include generators nowadays. It does not include tons of other things though.
which means Python implementation is still written in subset of Python and not using the real full fat Python.
RPython is Python with restrictions about the allowed runtime behavior (but not the import-time behavior). The Python implementation of PyPy is written in RPython, yes.
That is theoretically correct but not mentioned on purpose. We don't support this. RPython is not meant as a general-purpose programming language, and it doesn't support a lot of things that would make it more convenient for that purpose. If you are using RPython because of performance issues only, PyPy has a good JIT nowadays which can get full Python close. If you are using RPython because you don't like dynamic languages, then pick Java or .NET instead. A bientôt, Armin.
On Mon, Dec 24, 2012 at 12:47 PM, Armin Rigo <arigo@tunes.org> wrote:
The Python implementation of PyPy
is written in RPython, yes.
That's exactly the answer I needed to hear. Thanks.
There is a bsdiff compression/decompression algorithm written in C. It is ported to Linux, Windows and other platforms many times. It requires several separate toolchains to compile and integrate and everything could be fine if not occasional crashes. According to Colin Percival the problem is in algorithm, but it is hard to debug in C after the Python. Maintainability is the sole reason I want to rewrite it. And I don't want to maintain C and Python code. It is not possible to bundle the whole 30+ megabytes of Python for this small task, so a translator that can put the algorithm directly into CPU code for the target machine ignoring the whole HARDWARE-BIOS-OS-C-OBJ-BIN (include/lib/flags/suffix) toolchain is highly interesting. I don't know if RPython can do this, but so far it is the closest thing. Maybe you know better alternatives for the experiment? http://debian.2.n7.nabble.com/Bug-409664-bsdiff-is-extremely-slow-on-some-fi... -- anatoly t.
Hi, On Mon, Dec 24, 2012 at 11:35 AM, anatoly techtonik <techtonik@gmail.com> wrote:
RPython is translated to C code that is then compiled with (for example) gcc using the standard toolchain. If the problem is compiling C code in the first place, looking at RPython is the wrong place. Well, that's just my opinion; feel free to play with RPython. I just believe it's very, very much the wrong tool. A bientôt, Armin.
On Mon, Dec 24, 2012 at 11:24 AM, William ML Leslie < william.leslie.ttg@gmail.com> wrote:
But it is still confusing, because the RPython doesn't include generators, which means Python implementation is still written in subset of Python and not using the real full fat Python.
I looks like the documentation is missing one more important aspect - RPython toolchain can be used to compile standalone programs written in RPython (which is why I've finally got to it at the moment).
Hi Anatoly, On Mon, Dec 24, 2012 at 9:35 AM, anatoly techtonik <techtonik@gmail.com> wrote:
But it is still confusing, because the RPython doesn't include generators,
I see your point --- but RPython does include generators nowadays. It does not include tons of other things though.
which means Python implementation is still written in subset of Python and not using the real full fat Python.
RPython is Python with restrictions about the allowed runtime behavior (but not the import-time behavior). The Python implementation of PyPy is written in RPython, yes.
That is theoretically correct but not mentioned on purpose. We don't support this. RPython is not meant as a general-purpose programming language, and it doesn't support a lot of things that would make it more convenient for that purpose. If you are using RPython because of performance issues only, PyPy has a good JIT nowadays which can get full Python close. If you are using RPython because you don't like dynamic languages, then pick Java or .NET instead. A bientôt, Armin.
On Mon, Dec 24, 2012 at 12:47 PM, Armin Rigo <arigo@tunes.org> wrote:
The Python implementation of PyPy
is written in RPython, yes.
That's exactly the answer I needed to hear. Thanks.
There is a bsdiff compression/decompression algorithm written in C. It is ported to Linux, Windows and other platforms many times. It requires several separate toolchains to compile and integrate and everything could be fine if not occasional crashes. According to Colin Percival the problem is in algorithm, but it is hard to debug in C after the Python. Maintainability is the sole reason I want to rewrite it. And I don't want to maintain C and Python code. It is not possible to bundle the whole 30+ megabytes of Python for this small task, so a translator that can put the algorithm directly into CPU code for the target machine ignoring the whole HARDWARE-BIOS-OS-C-OBJ-BIN (include/lib/flags/suffix) toolchain is highly interesting. I don't know if RPython can do this, but so far it is the closest thing. Maybe you know better alternatives for the experiment? http://debian.2.n7.nabble.com/Bug-409664-bsdiff-is-extremely-slow-on-some-fi... -- anatoly t.
Hi, On Mon, Dec 24, 2012 at 11:35 AM, anatoly techtonik <techtonik@gmail.com> wrote:
RPython is translated to C code that is then compiled with (for example) gcc using the standard toolchain. If the problem is compiling C code in the first place, looking at RPython is the wrong place. Well, that's just my opinion; feel free to play with RPython. I just believe it's very, very much the wrong tool. A bientôt, Armin.
participants (3)
-
anatoly techtonik -
Armin Rigo -
William ML Leslie