Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 2.2.0 Released

ruby-lang.org

Post reply on HN
Print view View original

61–70 of 82 posts

Re: Ruby 2.2.0 Released

#61

Post by xfalcox »

shadeslayer wrote: post #59
xfalcox wrote: post #53

Guys, I made a very simple pull request regarding auto proxy detection on the standard library of ruby, but it still open after a little while. Someone here have some directions on how to contribute correctly to the project?

I contributed a small patch earlier this month, but used their bug tracker to submit patch, turn around time was ~24 hours I think. See bugs.ruby-lang.org/issues/10551 So I think all of their patches need to go through the bug tracker.

Thank you! Just submitted it at https://bugs.ruby-lang.org/issues/10652

Hope it helps!

Re: Ruby 2.2.0 Released

#62

Post by gsnedders »

berdario wrote: post #52
jrochkind1 wrote: post #47

Earlier quoted context omitted.

> I'm under the impression that before ruby1.9, Ruby was simply encoding-oblivious, and for any encoding-sensitive piece of code, people simply relied on things like libuconv. True. > but by reading this blog post, I'm under the impression that most of the breakage that you'd get with the move to Ruby1.9 wouldn't be in exceptions, but in strings corruption. Eh... I don't know. In my experience, the encoding-related p…

> There's actually way more we can say about this, but this is a huge book already, haha. Yeah, so long for "I'll try to keep this short" :P > One difference in encoding between python and ruby I think is, in ruby 1.9+, if a string is tagged with an encoding but contains bytes invalid for that encoding (that do not represent a legal sequence of chars), you'll get an exception if you try to concat it to anything else…

> (obviously you can have codepoint U+FFFD, if you set errors='replace' when decoding)

Which is totally fine because U+FFFD REPLACEMENT CHARACTER is a totally valid character.

Re: Ruby 2.2.0 Released

#63

Post by ch4s3 »

kawsper wrote: post #4
mrmondo wrote: post #3

Great work to the ruby team, the improvements in Ruby's performance since 2.x have been very impressive to say the least. Well done and Merry Christmas to everyone that worked hard on this release.

Indeed, by upgrading Ruby from 1.9.3 to 2.1.2 we cut the time spent running our specs in half for our Rails project.

I just popped off a branch of my production Rails 4.1.8 app (Can't quite do 4.2 yet), and upgraded it 2 Ruby 2.2. I ran 271 spec against it 5 times before the upgrade and 16 times after. I should have done more before :(

For 2.1.5

AVG: 18.02

MEDIAN: 18.11

MIN: 16.26

MAX: 19.6

For 2.2

AVG: 18.162~

MEDIAN: 15.23

MIN: 14.44 MAX: 47.03 It looks better, but I haven't profiled the app on Passenger yet to see how well it plays with the whole app.

Re: Ruby 2.2.0 Released

#64

Post by Xylakant »

MichaelGG wrote: post #58
jrochkind1 wrote: post #36

Earlier quoted context omitted.

Actually, the "ruby 1.9" solution is having Strings tagged with encoding at all -- prior to ruby 1.9 they were not, they were just bytes. This was a pretty major change, I think I'd call it a 'destructive' change, it was indeed a big pain upgrading apps from ruby 1.8 to 1.9, and character encoding was the major issue generally. I'm not sure I understand what you're saying about python 2 vs 3, or what you think needs…

Excuse my density here, but why not just force all strings to be UTF8 and call it a day? Anything in another encoding would need to get converted. What am I missing that Ruby and Python need these complicated problems but other platforms don't have these issues?

Han unification is the primary reason not to force utf8, especially in a language that has strong roots in Japan. (Sorry to be short, I'm on a smartphone. Googling should provide sufficient answers)

Re: Ruby 2.2.0 Released

#65

Post by [deleted] »

MichaelGG wrote: post #58
jrochkind1 wrote: post #36

Earlier quoted context omitted.

Actually, the "ruby 1.9" solution is having Strings tagged with encoding at all -- prior to ruby 1.9 they were not, they were just bytes. This was a pretty major change, I think I'd call it a 'destructive' change, it was indeed a big pain upgrading apps from ruby 1.8 to 1.9, and character encoding was the major issue generally. I'm not sure I understand what you're saying about python 2 vs 3, or what you think needs…

Excuse my density here, but why not just force all strings to be UTF8 and call it a day? Anything in another encoding would need to get converted. What am I missing that Ruby and Python need these complicated problems but other platforms don't have these issues?

[deleted]

Re: Ruby 2.2.0 Released

#68

Post by wycats »

Xylakant wrote: post #64
MichaelGG wrote: post #58

Earlier quoted context omitted.

Excuse my density here, but why not just force all strings to be UTF8 and call it a day? Anything in another encoding would need to get converted. What am I missing that Ruby and Python need these complicated problems but other platforms don't have these issues?

Han unification is the primary reason not to force utf8, especially in a language that has strong roots in Japan. (Sorry to be short, I'm on a smartphone. Googling should provide sufficient answers)

Han unification is one problem; another problem is that not all encodings can be round-tripped losslessly through Unicode. Shift-JIS, for example, has multiple separate characters that convert into the same character in Unicode, and therefore cannot be converted back into their original form reliably.

Re: Ruby 2.2.0 Released

#69

Post by wycats »

yxhuvud wrote: post #56
dagw wrote: post #34

Earlier quoted context omitted.

When the Ruby team makes changes the attitude is generally 'deal with it' However they complement this attitude by being a lot better at working with big 3rd party library developers and making sure they are on board. To the best of knowledge there has never been a Ruby release that was incompatible with RoR for any period of time. Compare to Python that jumped to python 3 without either numpy or Django on board.

Well, on the other hand I definitely remember a point release of 1.8.7 that broke Rails :)

Momentarily, and Matz appeared to feel so bad about it that they have been far more aggressive about tiny-version changes ever since.

Re: Ruby 2.2.0 Released

#70

Post by wycats »

jrochkind1 wrote: post #47
berdario wrote: post #45

Earlier quoted context omitted.

> Actually, the "ruby 1.9" solution is having Strings tagged with encoding at all -- prior to ruby 1.9 they were not, they were just bytes. Whoops, you're right... I confused the version, what I had in mind is the "source code as UTF-8 by default", which wasn't introduced in Ruby1.9, but in Ruby2.0 > If ruby ever decides to make things even more strict, I don't think it'll actually be as disruptive as the 1.8 to 1.9…

> I'm under the impression that before ruby1.9, Ruby was simply encoding-oblivious, and for any encoding-sensitive piece of code, people simply relied on things like libuconv. True. > but by reading this blog post, I'm under the impression that most of the breakage that you'd get with the move to Ruby1.9 wouldn't be in exceptions, but in strings corruption. Eh... I don't know. In my experience, the encoding-related p…

I agree with the vast majority of what you've said.

One thing worth noting is that there was a TREMENDOUS effort that I headed up in the Rails 3 era to very aggressively attempt to reduce the number of encoding-related problems in Rails, and to make sure that common mistakes produced clear error messages.

I wrote two somewhat lengthy blog posts at the time[1][2] for a contemporary historical perspective just as the difficulty with encodings started to heat up.

One of the goals of the Rails 3 effort was to make significant efforts to ensure that strings that made their way into Rails came in as UTF-8. That involved being very careful with templates (I wrote a bit of a novel in the docs that remains to this day[3]), figuring out how to ensure that browser forms submitted their data in UTF-8 (even in IE6[4]), and working with Brian Lopez on mysql2 to ensure that all strings coming in from Postgres were properly tagged with encodings.

I also did a lot of person-to-person evangelism to try to get C bindings to respect the `default_internal` encoding setting, which Rails sets to UTF-8.

The net effect of all of that work is that while people experienced a certain amount of encoding-related issues in Rails 3, it was dramatically smaller than the kinds of errors we were seeing when experimental Ruby 1.9 support was first added to Rails 2.3.

---

P.S. I completely agree that the ASCII-7 exception was critical to keeping things rolling in the early days, but I personally would have liked an opt-in setting that would raise an exception when concatenating BINARY that happened to contain ASCII-7-only bytes with an ASCII-compatible string. In practice, this exception allowed a number of obscure C bindings to continue to produce BINARY strings well into the encoding era, and they were responsible for a large percentage (in my experience) of weird production-only bugs.

Specifically, you would have development and test environments that only tested with ASCII characters (people's names, for example). Then, in production, the occasional user would type in something like "José", producing a hard-to-reproduce encoding compatibility exception. This kind of problem is essentially eliminated with libraries that are encoding-aware at the C boundary that respect `default_internal`.

[1]: http://yehudakatz.com/2010/05/05/ruby-1-9-encodings-a-primer...

[2]: http://yehudakatz.com/2010/05/17/encodings-unabridged/

[3]: https://github.com/rails/rails/blob/master/actionview/lib/ac...

[4]: http://stackoverflow.com/a/3348524

Post reply on HN