10 things to be aware of in 1.8 -> 1.9 transition

[David A. Black]

Hi --

I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:

http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-ruby-1-9

I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Joel VanderWerf]

Hi --

I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:

http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-ruby-1-9


I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.


David

I do appreciate it, having been slow to test on 1.9.

There is a small bug in the text though:

x = 1
{|x| }

Maybe there should be an "x=3" in the block?

 

[James Gray]

Hi --

I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:

= http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-=
ruby-1-9

I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.

Double-check your examples in "Block variables scope." It looks like =20=

they may be cut off.

I also think you need to add a section on this error, which seems very =20=

likely to be the first thing programmers encounter in the new m17n code:

$ echo "R=E9sum=E9" > utf8.rb
$ ruby_dev utf8.rb
utf8.rb:1: invalid multibyte char (US-ASCII)

I love the idea overall though. Thanks for sharing!

James Edward Gray II=

 

[David A. Black]

Hi --

Sigh -- I forgot to wrap some of them in <pre>.

Everyone please look at it again for those block examples


David

I do appreciate it, having been slow to test on 1.9.

There is a small bug in the text though:

x = 1
{|x| }

Maybe there should be an "x=3" in the block?

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[F. Senault]

Le 14 janvier 2009 à 20:14, James Gray a écrit :

I also think you need to add a section on this error, which seems very
likely to be the first thing programmers encounter in the new m17n code:

Oh yeah.

And this :
Encoding::CompatibilityError: incompatible character encodings:
ASCII-8BIT and UTF-8
from (irb):8
from /usr/local/bin/irb:12:in `<main>'

Fred
Who is still having trouble with utf-8 in one of his rails models...

 

[Robert Dober]

Hi --

I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:

I believe this is something lots of folks want desperately, YHS included.
So please keep the good work up.
A small comment on hash key ordering:
As you said it is insertion order, not update order, thus in the
(unlikely) case that one wants to change that, one
has to delete the key.
h = { a: 42, b: 42 }
h.update a: 42
h --> { a: 42, b: 42 }
vs.
h.delete a:
h.update a: 42
h --> { b: 42, a: 42 }

It seems to be true too that the hash literal is insertion order
preserving, thus the read syntax and write
syntax for hashes seem identical .
Can anybody confirm this please?
Cheers
R

 

[Ollivier Robert]

Oh yeah.

I agree, everything encoding-related will bite people. This is complicated in
1.9.

 

[Brian Candler]

There is a small bug in the text though:

x = 1
{|x| }

Maybe there should be an "x=3" in the block?

No, it's correct as it is. The point is that in ruby 1.8, |x| is
assigned to each time the block is called, and if x existed before the
block, it remains after the block as the last value. This is regardless
of whether you actually use or assign to x inside the block.

$ irb
irb(main):001:0> x = 1
=> 1
irb(main):002:0> [2,3].each{|x| }
=> [2, 3]
irb(main):003:0> x
=> 3

But in ruby1.9, |x| is a local block argument, independent of any local
variable x outside the block.

$ irb19
irb(main):001:0> x = 1
=> 1
irb(main):002:0> [2,3].each{|x| }
=> [2, 3]
irb(main):003:0> x
=> 1

 

[James Gray]

http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-=
ruby-1-9

As a quick fix you can do

$ ruby -KU utf8.rb

but a guide summarizing the encoding features and possible problems
would be very helpful.

Yeah, I've been working on such a guide:

http://blog.grayproductions.net/articles/understanding_m17n

I just haven't got to the 1.9 sections yet. I will eventually though=85

James Edward Gray II=

 

[Michael Fellinger]

Hi --

I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:

http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-ruby-1-9

I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.

You might also want to mention (around the point of block-parameters
have def syntax) that procs can take a block now.
The Enumerator stuff is in 1.8.7 already, not sure if it's that
notable. Maybe some things instead about String (#each, Enumerable,
[0], ?a, ...) would be more helpful.

^ manveru

 

[David A. Black]

Hi --

Hi --

I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:

http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-ruby-1-9

I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.

You might also want to mention (around the point of block-parameters
have def syntax) that procs can take a block now.
The Enumerator stuff is in 1.8.7 already, not sure if it's that
notable. Maybe some things instead about String (#each, Enumerable,
[0], ?a, ...) would be more helpful.

I'm not really dealing with 1.8.7 in my book (nor much in general).
[0] is a good idea. I do mention in my list that strings aren't
enumerable any more.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Phlip]

h = { a: 42, b: 42 }

I thought the new label: syntax was worth a top-level citation.

That syntax sugar, together with stringy symbols and hashes in hashed order,
produce an emergent "named argument" system that makes DSLs much easier to
invent on the end of your method arguments.

 

[Brian Candler]

I thought the new label: syntax was worth a top-level citation.

But that isn't going to break any existing code, and I believe the main
thrust of this article is changes to be wary of - although some aren't
in that category, like def foo(a,*b,c).

 

[Joel VanderWerf]

No, it's correct as it is.

Well, it's correct *now*:

x = 1
[2,3].each {|x| }

(it wasn't even parsing before)

 

[David A. Black]

Hi --

I thought the new label: syntax was worth a top-level citation.

It's cool but it doesn't belong on the original list, because it's not
something that might make your existing code fail to work, which is
(mostly what the list is. The mention of ordered hashes is
questionable on those grounds too in fact.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[David A. Black]

Hi --

But that isn't going to break any existing code, and I believe the main
thrust of this article is changes to be wary of - although some aren't
in that category, like def foo(a,*b,c).

Yes -- that one and the ordered hash one are a bit out of step with
the overall idea of the post. I guess I just include them among the
new stuff in almost any context out of habit.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Brian Candler]

Yes -- that one and the ordered hash one are a bit out of step with
the overall idea of the post. I guess I just include them among the
new stuff in almost any context out of habit.

BTW, I think the blog post should link to the presentation by David
Thomas and yourself:
http://rubyconf2008.confreaks.com/ruby-19-what-to-expect.html

I watched this a while back and enjoyed it, but had to search hard to
find it again.

 

[Phlip]

It's cool but it doesn't belong on the original list, because it's not
something that might make your existing code fail to work, which is
(mostly what the list is. The mention of ordered hashes is
questionable on those grounds too in fact.

Maybe we need two lists:

- warnings, gotchas, and incompatibilities
- new conveniences and benefits

 

[David A. Black]

Maybe we need two lists:

- warnings, gotchas, and incompatibilities
- new conveniences and benefits

Well, my whole book is about 1.9


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Robert Dober]

Hi --



It's cool but it doesn't belong on the original list, because it's not
something that might make your existing code fail to work, which is

Ah there is one tiny little thing which bite me quite hard, maybe you
wanna mention it

580/206 > ruby186 -v -e 'p [?*, ?\ ] '
ruby 1.8.6 (2009-01-06 patchlevel 291) [i686-linux]
[42, 32]
robert@siena:~/tmp 02:40:59
581/207 > ruby187 -v -e 'p [?*, ?\ ] '
ruby 1.8.7 (2009-01-06 patchlevel 78) [i686-linux]
[42, 32]
robert@siena:~/tmp 02:41:04
582/208 > ruby191 -v -e 'p [?*, ?\ ] '
ruby 1.9.1 (2009-01-06 patchlevel-5000 trunk 21356) [i686-linux]
["*", " "]

R.