131–140 of 190 posts
I'm probably in the minority but I would love to see a dialect of ruby that has significant whitespace. Death to unnecessary 'end's
Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s
Whenever I see frontpages for these kinds of projects like "a faster X" or "X written in Blub", the first thing I want to see on the frontpage is how this new project compares to X in terms of quality and performance. Even specious benchmarks would help more than zero benchmarks. I wish more frontpages for these kinds of projects would do that.
So you are saying you would prefer wrong information?
At least once a year there's a maelstrom of posts about a new Ruby implementation with stellar numbers. These numbers are usually based on very early experimental code, and they are rarely accompanied by information on compatibility. And of course we love to see crazy performance numbers, so many of us eat this stuff up.
Earlier quoted context omitted.
https://bitbucket.org/cfbolz/pyrolog/ https://bitbucket.org/pypy/lang-smalltalk/ https://bitbucket.org/pypy/lang-js/ https://bitbucket.org/pypy/lang-scheme/
http://tratt.net/laurie/tech_articles/articles/fast_enough_v... is probably the best example, because — as far as I know — outside of having reimplemented his Converge in RPython Laurence Tratt is not affiliated with the pypy project in any way, shape or form.
http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht... At least once a year there's a maelstrom of posts about a new Ruby implementation with stellar numbers. These numbers are usually based on very early experimental code, and they are rarely accompanied by information on compatibility. And of course we love to see crazy performance numbers, so many of us eat this stuff up.
It would be nice to see Rpython/pypy turned into a project not unlike WebKit where many different projects benefit from the same open-source core. If pypy is flexible enough to implement all of ruby and all of Python, has a reasonable amount of maturity, and is already rather fast it seems like a good candidate for such a thing.
1. (optional) install PyPy "JIT compiler" binaries [0]
2. get and extract the PyPy source[1] from bitbucket release packages, which includes the RPython translator, written itself in Python and, although working on CPython, best run under PyPy as installed on step 1.
3. write a (R)Python module including a def target returning the entry point function[2], and call the translator upon your module, like so:
python ./pypy/pypy/translator/goal/translate.py example2.py
[0]: http://pypy.org/download.html
[1]: https://bitbucket.org/pypy/pypy/get/release-1.9.tar.bz2
[2]: http://morepypy.blogspot.fr/2011/04/tutorial-writing-interpr...
It would be nice to see Rpython/pypy turned into a project not unlike WebKit where many different projects benefit from the same open-source core. If pypy is flexible enough to implement all of ruby and all of Python, has a reasonable amount of maturity, and is already rather fast it seems like a good candidate for such a thing.
Quick how-to: 1. (optional) install PyPy "JIT compiler" binaries [0] 2. get and extract the PyPy source[1] from bitbucket release packages, which includes the RPython translator, written itself in Python and, although working on CPython, best run under PyPy as installed on step 1. 3. write a (R)Python module including a def target returning the entry point function[2], and call the translator upon your module, like s…