Ugh, hit the wrong reply button. On 24 December 2012 19:24, William ML Leslie <william.leslie.ttg@gmail.com> wrote:
On 24 December 2012 19:03, anatoly techtonik <techtonik@gmail.com> wrote:
Hi,
The PyPy description in getting started is still too scientific. I attach a patch with accessibility fix. =) But it is still not completely clear if PyPy's Python implementation is written in Python or in RPython?
They aren't mutually exclusive; all rpython is python.
'''And the second is one particular implementation that is so generated – an implementation of the Python programming language written in Python itself.'''
Maybe we could be even clearer - in my mind, implementations aren't generated, they do have to be written (:
If Python implementation is written in Python, and not in RPython then there is the missing link between the framework and implementation, which is confusing.
http://doc.pypy.org/en/latest/getting-started.html#what-is-pypy -- anatoly t.
-- William Leslie
-- William Leslie
On Mon, Dec 24, 2012 at 11:24 AM, William ML Leslie < william.leslie.ttg@gmail.com> wrote:
Ugh, hit the wrong reply button.
On 24 December 2012 19:24, William ML Leslie <william.leslie.ttg@gmail.com> wrote:
On 24 December 2012 19:03, anatoly techtonik <techtonik@gmail.com> wrote:
Hi,
The PyPy description in getting started is still too scientific. I attach a patch with accessibility fix. =) But it is still not completely clear if PyPy's Python implementation is written in Python or in RPython?
They aren't mutually exclusive; all rpython is python.
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.
'''And the second is one particular implementation that is so generated – an implementation of the Python programming language written in Python itself.'''
Maybe we could be even clearer - in my mind, implementations aren't generated, they do have to be written (:
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).
If Python implementation is written in Python, and not in RPython then there is the missing link between the framework and implementation, which is confusing.
http://doc.pypy.org/en/latest/getting-started.html#what-is-pypy
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.
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).
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.
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).
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.
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:
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?
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 1:49 PM, Armin Rigo <arigo@tunes.org> wrote:
Hi,
On Mon, Dec 24, 2012 at 11:35 AM, anatoly techtonik <techtonik@gmail.com> wrote:
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?
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.
All right. Got it. Thanks for the explanation. -- anatoly t.
participants (3)
-
anatoly techtonik -
Armin Rigo -
William ML Leslie