When I woke up to this news, I rushed past the presents straight to my laptop to install 2.1. Thank you ruby team for the great Christmas present. PS. Thanks RVM for getting the stable ruby 2.1 ready so fast.
Nice, On a Side note Rubinius 2.2.1 was out and i didn't notice they had a 2.2 release at all. Wasn't even a announcement from Rubinius Twitter or any news on HN either.
Now i am waiting for someone doing some benchmarks with the two ( & JRuby ).
I am pleased someone else is excited about String#scrub.
For those who need #scrub behavior in ruby 1.9 or 2.0, I wrote a gem a while ago to do this -- I wrote it before I was aware of the upcoming String#scrub api -- I'll maybe change it to provide a String#scrub 'backfill' now, with monkey patching even?
awesome, thanks. Looks like that backport may be only for ruby 2.0 (not 1.9), and is a compiled C extension.
It won't take many lines of pure ruby code to do it for ruby 1.9 too, although presumably not performing quite as well as a C version.
At any rate, this is definitely something I and people I know need to do all the time, although apparently most ruby devs never need to do it; but I'm glad it's finally made it into stdlib.
I've completed a pure-ruby polyfill that should work on 1.9 as well as 2.0, any ruby interpreter including jruby. (It does have some issues mentioned in the readme).
Oh wow, I actually ran into this recently, I couldn't figure out what to search for to fix it though. Nice to see that it's built in now.
(It was for a tiny weekend project where I was reading logs from the ZNC IRC bouncer to present a nice web UI for them, for some reason sometimes there were invalid characters and I didn't really understand why - possible that I was just reading them with the wrong input encoding but I think I tried a few different ones.)
Same here, had the same issues when working on a simple irc client. Basically what I did to make it work was: read the string with a given encoding(say UTF8), them check if the read string was a valid string with said encoding (no invalid characters). If this was the case, that means it found the correct encoding otherwise loop again and try with another encoding (I used cp1252 as a second guess), until the resulting string had no invalid characters. Used to work pretty good and didn't crash anymore when facing "unexpected" characters... I am curious on whether String#scrub is implemented in a similar way?
String#scrub does not try to identify a proper encoding from a mystery encoding.
Rather, Strin#scrub simply removes invalid bytes from the input, by default replacing them with the unicode replacement char � (or simply "?" if not in a unicode encoding).
This is, for instance, what many editors and other software I've used will do too -- if you say to open a file in encoding X, and some bytes in it are invalid for encoding X, they will be replaced with � or ? in display.
I find it a pretty useful thing in my own software, where input is _supposed_ to be a given known encoding, but upstream providers sometimes provide data with corrupt bytes, errors, or sub-passages in wrong encoding. It's not really my software's job to come up with the 'real' encoding -- and there may be no 'correct' encoding, often the error is corrupt bytes or mixed encodings -- but it is my software's job to show what can be shown without raising.
Thanks for the clarification on #scrub. With regards to guessing a given encoding, I remember trying some (or probably all) of those gems or those that were around at the time I was writing the app, but for a reason or another (I think some were not recently updated) I couldn't get them working so I came up with my own little solution.
Anyway, thanks for taking the time to list them.
Please stop posting links to file locations. Announcements or changelogs would be more useful! If I would like to download it, I'll just use package manager. Personally, I just want to read what's new.
OP here: The announcement hadn't been written at the time I posted this link. I figured people would rather install it, and when the announcements became available, I'd add them as comments. They are both posted here if you scroll down.
Do that many people install Ruby through a source code package that they manually download? Why not just hold off on posting until there's useful information?
in unofficial benchmarks with Rails (running different rake tasks and benchmarking them). 2.1.0 seems to be 20% faster than 2.0.0 and 2.0 was about 60/70% faster than 1.9.3 so that would make 2.1.0 about twice as fast as 1.9.3.
Rails was only about 5-6% faster in the last few nights of development builds (based on what is installed with rvm reinstall ruby-head). I would be surprised if the released 2.1.0 is more than one percentage point different from that.
I will add 2.1.0 right now and hopefully we will have confirmed data in the morning.
EDIT: You mention 20% improvement on Rake tasks. Simple Rake tasks are dominated by Rails' startup time. My benchmark reads about a 15% improvement in startup time, which agrees with what you are saying.
However, the 1.9 series was a significant step back from 1.8.7 for out-of-the-box Rails startup time. Ruby 2.0.0 pretty much matched Ruby 1.8.7. Now with 2.1.0, Ruby is finally categorically faster than 1.8.7 for starting Rails. (Rails itself has also made improvements; but my benchmark has been locked at Rails 3.1.3)
Thanks for adding that information, I didn't know about slower Rails startup times with Ruby 1.9 v 1.8.
And, you were right, I put Ruby 2.1.0 live on one of my web apps last night, and didn't really get any kind of significant speed boost, what I did get was a significant decrease in garbage collection. here's the new relic graph, ruby 2.1.0 went live at 17:45 on the chart https://cloudup.com/ifosPh4rX4v
I find it strange that JRuby would be the worst of all for all 4 categories though. Startup time I can understand, but given the right conditions, it's known to be pretty damn fast.
I understand the importance of Rails in the Ruby ecosystem, but at the same time, I would really like it not being the only measure of Ruby's performance.
I agree. However, when I sat down two years ago to make a benchmark, I couldn't think of anything better to benchmark than Rails. Micro-benchmarks don't predict large application performance very well. I don't like micro-benchmarks.
A micro-benchmark suite is better than a few micro-benchmarks, but really I would like a suite of real-world micro-applications.
I'm willing to add more benchmarks so it's not just Rails, but I simply don't know what to add.
I actually thought that the new feature of def yielding the symbolic name of the newly defined function was interesting, if for anything to open up new areas where there was a limit before on building lookup tables for macro and meta programming techniques with either DSL creation and|or basic ruby hacking for fun.
52 comments
[ 2.9 ms ] story [ 22.0 ms ] threadNow i am waiting for someone doing some benchmarks with the two ( & JRuby ).
String#scrub: https://github.com/ruby/ruby/blob/1e8a05c1dfee94db9b6b825097...
String#freeze example:
https://github.com/rails/rails/pull/12879
For those who need #scrub behavior in ruby 1.9 or 2.0, I wrote a gem a while ago to do this -- I wrote it before I was aware of the upcoming String#scrub api -- I'll maybe change it to provide a String#scrub 'backfill' now, with monkey patching even?
https://github.com/jrochkind/ensure_valid_encoding
It was mentioned in the changelog.
It won't take many lines of pure ruby code to do it for ruby 1.9 too, although presumably not performing quite as well as a C version.
At any rate, this is definitely something I and people I know need to do all the time, although apparently most ruby devs never need to do it; but I'm glad it's finally made it into stdlib.
I've completed a pure-ruby polyfill that should work on 1.9 as well as 2.0, any ruby interpreter including jruby. (It does have some issues mentioned in the readme).
https://github.com/jrochkind/scrub_rb
(It was for a tiny weekend project where I was reading logs from the ZNC IRC bouncer to present a nice web UI for them, for some reason sometimes there were invalid characters and I didn't really understand why - possible that I was just reading them with the wrong input encoding but I think I tried a few different ones.)
Rather, Strin#scrub simply removes invalid bytes from the input, by default replacing them with the unicode replacement char � (or simply "?" if not in a unicode encoding).
This is, for instance, what many editors and other software I've used will do too -- if you say to open a file in encoding X, and some bytes in it are invalid for encoding X, they will be replaced with � or ? in display.
I find it a pretty useful thing in my own software, where input is _supposed_ to be a given known encoding, but upstream providers sometimes provide data with corrupt bytes, errors, or sub-passages in wrong encoding. It's not really my software's job to come up with the 'real' encoding -- and there may be no 'correct' encoding, often the error is corrupt bytes or mixed encodings -- but it is my software's job to show what can be shown without raising.
I think I've seen other gems that try to use heuristics to guess or discover an appropriate encoding for text with no known encoding. But String#scrub is not that. Here's some gems that say they'll do that (I have no experience with any of tem): https://github.com/brianmario/charlock_holmes ; https://github.com/jmhodges/rchardet ; https://github.com/janx/chardet2
Pretty graphs here: http://www.isrubyfastyet.com/ (I run a nightly benchmark.)
I will add 2.1.0 right now and hopefully we will have confirmed data in the morning.
EDIT: You mention 20% improvement on Rake tasks. Simple Rake tasks are dominated by Rails' startup time. My benchmark reads about a 15% improvement in startup time, which agrees with what you are saying.
However, the 1.9 series was a significant step back from 1.8.7 for out-of-the-box Rails startup time. Ruby 2.0.0 pretty much matched Ruby 1.8.7. Now with 2.1.0, Ruby is finally categorically faster than 1.8.7 for starting Rails. (Rails itself has also made improvements; but my benchmark has been locked at Rails 3.1.3)
And, you were right, I put Ruby 2.1.0 live on one of my web apps last night, and didn't really get any kind of significant speed boost, what I did get was a significant decrease in garbage collection. here's the new relic graph, ruby 2.1.0 went live at 17:45 on the chart https://cloudup.com/ifosPh4rX4v
A micro-benchmark suite is better than a few micro-benchmarks, but really I would like a suite of real-world micro-applications.
I'm willing to add more benchmarks so it's not just Rails, but I simply don't know what to add.
Running with a more modern VM might yield better results.
EDIT: rbenv-update'='(cd ~/.rbenv/plugins/ruby-build && git pull) did the trick.
=> :foo
2.1.0p0 :002 > def eval_it_now_bitch! lulz
2.1.0p0 :003?> eval lulz.to_s
2.1.0p0 :004?> end
=> :eval_it_now_bitch!
2.1.0p0 :005 > eval_it_now_bitch! x
hello
=> nil
Merry Xmas.
http://www.ruby-lang.org/en/news/2013/12/25/ruby-2-1-0-is-re...
There's a world of difference when something is unsigned because it's impossible to prove that it was what the developer(s) signed off to release.
Ruby 2.0-p353
Transactions: 934 hits Availability: 100.00 % Elapsed time: 76.66 secs Data transferred: 0.43 MB Response time: 3.19 secs Transaction rate: 12.18 trans/sec Throughput: 0.01 MB/sec Concurrency: 38.92 Successful transactions: 934 Failed transactions: 0 Longest transaction: 3.93 Shortest transaction: 0.67
Ruby 2.1 Transactions: 1136 hits Availability: 100.00 % Elapsed time: 76.41 secs Data transferred: 0.53 MB Response time: 2.64 secs Transaction rate: 14.87 trans/sec Throughput: 0.01 MB/sec Concurrency: 39.30 Successful transactions: 1136 Failed transactions: 0 Longest transaction: 3.18 Shortest transaction: 0.56