On Mon, Dec 24, 2012 at 12:47 PM, Armin Rigo <[email protected]> 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-files-sometimes-hangs-td1738215.html -- anatoly t.
_______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
