4 ms·

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wis

by irahul 15y ago

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

alphakappa 15y ago
matplotlib and numpy make Python really awesome. If only there was a way to get matplotlib to work on Lion.
- iuyterw 15y ago
  Until the patched version is released... pip install -e git+https://github.com/matplotlib/matplotlib#egg=matplotlib-dev https://github.com/matplotlib/matplotlib#egg=matplotlib-dev
- Nitrof 15y ago
  The solution with HomeBrew is shown here : http://sourceforge.net/mailarchive/message.php?msg_id=27888307 http://sourceforge.net/mailarchive/message.php?msg_id=278883...
- wynand 15y ago
  I'm using the Scipy superpack (http://stronginference.com/scipy-superpack/ http://stronginference.com/scipy-superpack/) on Lion and Matplotlib has given me no trouble so far.
- Derbasti 15y ago
  But they don't run on PyPy yet. Now that will be awesome!
deleted 15y ago
[deleted]
stephenjudkins 15y ago
Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ http://rubini.us/doc/en/virtual-machine/instructions/) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, parser, and parts that compile the AST to bytecode is all written in pure Ruby. Further, large parts of the standard library and Ruby language that are implemented in lower-level languages in other implementations are instead written as runtime-level Ruby. However, large and important parts of the infrastructure (including GC and memory allocation) are written in C++. PyPy takes an altogether different approach. It specifies a restricted subset of Python known as "RPython". Basically, it's statically-typed Python. There is also a "compiler" (also called a "JIT generator"), written in pure Python, that compiles an arbitrary interpreter written in RPython into a fast JIT. (See http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... for an example of writing a very simple, small interpreter in RPython.) A cool feature of RPython is that while there must a statically RPython AST to compile, during the "eval" stage you can leverage the full dynamic capabilities of Python. The second part of PyPy is a full Python interpreter written in RPython. Since RPython is a subset of Python, you can actually run this interpreter sandboxed inside any other Python implementation, albeit very slowly. The PyPy toolchain compiles this down to a very fast Python interpreter that features JIT compilation, among other cool features. The neat part of PyPy (in contrast to Rubinius) is that the toolchain part is largely decoupled and generalized away from Python-the-language. Conceivably, one could write ANY language in RPython (or what's compiled down to RPython) and have a fast JIT interpreter. Experimental language features can be added and changed (see the source code for the different garbage collectors in PyPy) with little mucking with the low-level VM. Rubinius is a neat, pragmatic project that could turn into one of the best Ruby implementations around. However, it's not breaking new ground like PyPy is.
- irahul 15y ago
  > Rubinius and PyPy take quite different approaches to solving the same general problem. > However, it's not breaking new ground like PyPy is. I know about the differences. My response was to the parent post "if there is something like PyPy for Ruby". Rubinius doesn't need to break new grounds, nor provide a toolset for implementing interpreters. All it needs to do is to provide a decent JIT with reasonable speed and low memory consumption, with the added benefit of large parts of it in Ruby, so that the contribution ecosystem is more active. That will be pretty much analogous(and all analogies, by definition, are inexact. Or else they won't be called ananlogy) to what PyPy is for Pythonistas.
luismgz 15y ago
> I wish something similar could be developed for Ruby. There's something like Pypy for Ruby already: It is Pypy itself. Pypy is a framework for implementing jitted dynamic languages (any language, not just python). You can generate interpreters for any language you want, as long as you write them in Rpython (restricted python). So, if you want a pypy for Ruby, just write a ruby interpreter in Rpython, and then use the pypy translation toolchain to compile it down to C, while automatically generating a just in time compiler for free.

by irahul 15y ago

alphakappa 15y ago

matplotlib and numpy make Python really awesome. If only there was a way to get matplotlib to work on Lion.

iuyterw 15y ago
Until the patched version is released... pip install -e git+https://github.com/matplotlib/matplotlib#egg=matplotlib-dev https://github.com/matplotlib/matplotlib#egg=matplotlib-dev
Nitrof 15y ago
The solution with HomeBrew is shown here : http://sourceforge.net/mailarchive/message.php?msg_id=27888307 http://sourceforge.net/mailarchive/message.php?msg_id=278883...
wynand 15y ago
I'm using the Scipy superpack (http://stronginference.com/scipy-superpack/ http://stronginference.com/scipy-superpack/) on Lion and Matplotlib has given me no trouble so far.
Derbasti 15y ago
But they don't run on PyPy yet. Now that will be awesome!

deleted 15y ago

[deleted]

stephenjudkins 15y ago

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ http://rubini.us/doc/en/virtual-machine/instructions/) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, parser, and parts that compile the AST to bytecode is all written in pure Ruby. Further, large parts of the standard library and Ruby language that are implemented in lower-level languages in other implementations are instead written as runtime-level Ruby. However, large and important parts of the infrastructure (including GC and memory allocation) are written in C++. PyPy takes an altogether different approach. It specifies a restricted subset of Python known as "RPython". Basically, it's statically-typed Python. There is also a "compiler" (also called a "JIT generator"), written in pure Python, that compiles an arbitrary interpreter written in RPython into a fast JIT. (See http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... for an example of writing a very simple, small interpreter in RPython.) A cool feature of RPython is that while there must a statically RPython AST to compile, during the "eval" stage you can leverage the full dynamic capabilities of Python. The second part of PyPy is a full Python interpreter written in RPython. Since RPython is a subset of Python, you can actually run this interpreter sandboxed inside any other Python implementation, albeit very slowly. The PyPy toolchain compiles this down to a very fast Python interpreter that features JIT compilation, among other cool features. The neat part of PyPy (in contrast to Rubinius) is that the toolchain part is largely decoupled and generalized away from Python-the-language. Conceivably, one could write ANY language in RPython (or what's compiled down to RPython) and have a fast JIT interpreter. Experimental language features can be added and changed (see the source code for the different garbage collectors in PyPy) with little mucking with the low-level VM. Rubinius is a neat, pragmatic project that could turn into one of the best Ruby implementations around. However, it's not breaking new ground like PyPy is.

irahul 15y ago
> Rubinius and PyPy take quite different approaches to solving the same general problem. > However, it's not breaking new ground like PyPy is. I know about the differences. My response was to the parent post "if there is something like PyPy for Ruby". Rubinius doesn't need to break new grounds, nor provide a toolset for implementing interpreters. All it needs to do is to provide a decent JIT with reasonable speed and low memory consumption, with the added benefit of large parts of it in Ruby, so that the contribution ecosystem is more active. That will be pretty much analogous(and all analogies, by definition, are inexact. Or else they won't be called ananlogy) to what PyPy is for Pythonistas.

luismgz 15y ago

> I wish something similar could be developed for Ruby. There's something like Pypy for Ruby already: It is Pypy itself. Pypy is a framework for implementing jitted dynamic languages (any language, not just python). You can generate interpreters for any language you want, as long as you write them in Rpython (restricted python). So, if you want a pypy for Ruby, just write a ruby interpreter in Rpython, and then use the pypy translation toolchain to compile it down to C, while automatically generating a just in time compiler for free.