61–70 of 73 posts
i.e.
rubyc test.rb
ruby-do test.rbc
in .bashrc:
function rubyc() {
ruby -e "File.open('$1c', 'wb').write(RubyVM::InstructionSequence.compile_file('$1').to_binary)"
}
function ruby-do() {
ruby -e "RubyVM::InstructionSequence.load_from_binary(File.open('$1', 'rb').read).eval"
}
Earlier quoted context omitted.
For me: because nothing else approaches it in terms of linguistic flexibility. I learned Ruby about two years ago, after learning...a dozen-ish languages? Something like that. I don't write web applications in it, because Rails grinds my gears for a whole host of reasons, but for my money it is the can-opener language. If I have a problem, I feel like I can generally explore it faster in Ruby (holla, Pry) and build a…
You should take a look at Crystal!
I love that it exists, and as it matures I will totally consider it for Big Time Web Application Development (for me that's Kotlin right now). But I don't think it'll ever be quite as "stretchy" as Ruby is, and Ruby's a good all-purpose language, for me, because of that stretch.
Earlier quoted context omitted.
(IBMer working on said JIT here) As Chris Seaton points out as well, we're not really open source yet. Working on getting there, but it's going to take time. The important thing now is that we can start talking with the community and making it more likely that when we do get open source, it can happen in a way consumable by the Ruby community.
do you have any status of the project? Or any dates when we can expect?
nobody noticed the bytecode section?
yes. care to elaborate? first thing that came to mind was "APC-style" ( https://secure.php.net/manual/en/intro.apc.php ) caches. but im not super up on deployment, i thought YARV was already supposed to achieve this.
In theory it might allow for faster loading of Ruby code (more analogous to Python's .pyc files), but IIRC early experiments (in the early 2.0 days) showed it to be counterproductive in many cases.
Earlier quoted context omitted.
Why? Genuinely curious.
'try' is relatively slow compared to other control logic, as allowing an exception to be thrown involves constructing an exception stack trace. This is slow in all VMs I know. Theoretically you could detect that the trace isn't used and remove it through escape analysis, but this is not easy, or you could do some crazy thing with lazily creating the stack trace, but that's a research project.
Earlier quoted context omitted.
For me: because nothing else approaches it in terms of linguistic flexibility. I learned Ruby about two years ago, after learning...a dozen-ish languages? Something like that. I don't write web applications in it, because Rails grinds my gears for a whole host of reasons, but for my money it is the can-opener language. If I have a problem, I feel like I can generally explore it faster in Ruby (holla, Pry) and build a…
What about Elixir?
Anyone knows if Ruby has accepted IBM's contribution of JIT for Cruby?? https://news.ycombinator.com/item?id=10715610 And below is the Presentation from Ko1 on compiling Ruby http://rubykaigi.org/2015/presentations/ko1
(IBMer working on said JIT here) As Chris Seaton points out as well, we're not really open source yet. Working on getting there, but it's going to take time. The important thing now is that we can start talking with the community and making it more likely that when we do get open source, it can happen in a way consumable by the Ruby community.
Fingers crossed to seeing this hit mainline soon.
This is actually a really great release. `&.` removes the really annoying (and slow) `try`. And I think the string literals freezing is going to solve a lot of problems with memory allocations. Check out this PR for Rails that covered a lot of similar performance problems created by too many string allocations. https://github.com/rails/rails/pull/21057/files I wish Rails 5 could go all in on Ruby 2.3.0 and frozen str…
Keep in mind string literal freezing is still off by default. I like that they did it this way, give a chance to see if it actually brings performance improvements in real world scenarios before imposing it on all code.
But I think the real benefits will always be in framework code.