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 (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
David A. Black wrote:
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?
On Jan 14, 2009, at 12:40 PM, David A. Black wrote:
run it up the flagpole first.
Double-check your examples in “Block variables scope.” It looks like
they may be cut off.
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:
$ echo “Résumé” > 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 G. II
Le 14 janvier 2009 à 20:14, James G. 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 :
require “yaml”
=> true
a = “héhé”
=> “héhé”
b = a.to_yaml
=> “— !binary |\naMOpaMOp\n\n”
c = YAML.load(b)
=> “h\xC3\xA9h\xC3\xA9”
c << “héhé”
Encoding::CompatibilityError: incompatible character encodings:
ASCII-8BIT and UTF-8
from (irb):8
from /usr/local/bin/irb:12:in `’
Fred
Who is still having trouble with utf-8 in one of his rails models…
Hi –
Sigh – I forgot to wrap some of them in
.
Everyone please look at it again for those block examples 
David
On Thu, 15 Jan 2009, Joel VanderWerf wrote:
writing an appendix with more or less this content, so I thought I’d
x = 1
{|x| }
Maybe there should be an “x=3” in the block?
–
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
On Wed, Jan 14, 2009 at 7:40 PM, David A. Black [email protected]
wrote:
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
2009/1/14 James G. [email protected]:
$ echo “Résumé” > utf8.rb
$ ruby_dev utf8.rb
utf8.rb:1: invalid multibyte char (US-ASCII)
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.
Thanks
Michal
In article [email protected],
F. Senault [email protected] wrote:
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.
I agree, everything encoding-related will bite people. This is
complicated in
1.9.
Joel VanderWerf wrote:
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
On Thu, Jan 15, 2009 at 3:40 AM, David A. Black [email protected]
wrote:
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
On Jan 15, 2009, at 5:18 AM, Michal S. wrote:
http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-ruby-1-9
very
$ 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…
James Edward G. II
Hi –
On Fri, 16 Jan 2009, Michael F. wrote:
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 (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
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.
I’m not really dealing with 1.8.7 in my book (nor much in general).
The problem with that theory that certain Rails sites (I’m not naming
any
names!) run 1.8.7 on their servers, for the latest patches, but their
developers
still use 1.8.6 on their workstations, for all the mature tools…
Phlip wrote:
h = { a: 42, b: 42 }
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).
Brian C. wrote:
Joel VanderWerf wrote:
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.
Well, it’s correct now:
x = 1
[2,3].each {|x| }
(it wasn’t even parsing before)
Hi –
On Fri, 16 Jan 2009, Phlip wrote:
h = { a: 42, b: 42 }
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 (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
Hi –
On Fri, 16 Jan 2009, Brian C. wrote:
Phlip wrote:
h = { a: 42, b: 42 }
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).
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 (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
David A. Black wrote:
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.
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.
what the list is. The mention of ordered hashes is