Errata

string.chr + string.chr + string.chr + string.chr + string.chr
should be:
string[3].chr + string[4].chr + string[5].chr + string[6].chr + string[7].chr

string.chr + string.chr + string.chr + string.chr + string.chr
should be:
string[3].chr + string[4].chr + string[5].chr + string[6].chr + string[7].chr

/(w+([-'.]w+)*/
should read:
/(w+([-'.]w+)*)/

/(w+([-'.]w+)*/
should read:
/(w+([-'.]w+)*)/

"Its extract_numbers method..." should be
"Its extract method..."

"Its extract_numbers method..." should be
"Its extract method..."

are subscripted. This is almost correct, but the "1" and "2" in "b1"
and "b2" need to be sub-sub-scripted, because "1" and "2" are
themselves subscripts of "b". To represent it as ASCII art:

log
b
1

In "The log base k of x, or logk(x)", the k is correctly subscripted,
but the "(x)" appears to be _superscripted_. As with the "logb1(x)"
and the other earlier examples, the (x) needs to be normal text, on
the same level as "log". Again, ASCII art to the rescue:

log (x)
k

are subscripted. This is almost correct, but the "1" and "2" in "b1"
and "b2" need to be sub-sub-scripted, because "1" and "2" are
themselves subscripts of "b". To represent it as ASCII art:

log
b
1

In "The log base k of x, or logk(x)", the k is correctly subscripted,
but the "(x)" appears to be _superscripted_. As with the "logb1(x)"
and the other earlier examples, the (x) needs to be normal text, on
the same level as "log". Again, ASCII art to the rescue:

log (x)
k

It should be normal text.

It should be normal text.

"...you'll get the same results whether you multiply A by B and then the result by C, or multiply B by C and then the result by A."

would be less confusing if it read

"...you'll get the same results whether you multiply A by B and then the result by C, or multiply B by C and then A by the result."

since multiplication of matrices is non-abelian.

"...you'll get the same results whether you multiply A by B and then the result by C, or multiply B by C and then the result by A."

would be less confusing if it read

"...you'll get the same results whether you multiply A by B and then the result by C, or multiply B by C and then A by the result."

since multiplication of matrices is non-abelian.

t.wday # => 3 # Numeric day of week; Sunday
is 0

It should look like this:

t.wday # => 3 # Numeric day of week; Sunday
# # is 0

t.wday # => 3 # Numeric day of week; Sunday
is 0

It should look like this:

t.wday # => 3 # Numeric day of week; Sunday
# # is 0

"Iterate over the array with Enumerable#each."
Change "Enumerable#each" to "Array#each".

"Iterate over the array with Enumerable#each."
Change "Enumerable#each" to "Array#each".

The given implementation of SortedArray changes the semantics of some
of Array's methods. For instance, SortedArray#insert and
SortedArray#push only take one argument, and SortedArray#reverse!
returns nil instead of an array. This implementation works more like
Array.

Replace the first code sample with this:

class SortedArray < Array

def initialize(*args, &sort_by)
@sort_by = sort_by || Proc.new { |x, y| x <=> y }
super(*args)
sort!(&sort_by)
end

def insert(ignore, *values)
values.each do |v|
# The next line could be further optimized to perform a
# binary search.
insert_before = index(find { |x| @sort_by.call(x, v) == 1 })
super(insert_before ? insert_before : -1, v)
end
end

def <<(v)
insert(0, v)
self
end

def push(*values)
insert(0, *values)
end
alias unshift push

Replace the second code sample with this:

%w[ []= collect! flatten! ].each do |method_name|
class_eval %{
def #{method_name}(*args)
super
sort!(&@sort_by)
end
}
end

def reverse
Array.new(super) # Return a normal array.
end

def reverse!
self
end
end

The given implementation of SortedArray changes the semantics of some
of Array's methods. For instance, SortedArray#insert and
SortedArray#push only take one argument, and SortedArray#reverse!
returns nil instead of an array. This implementation works more like
Array.

Replace the first code sample with this:

class SortedArray < Array

def initialize(*args, &sort_by)
@sort_by = sort_by || Proc.new { |x, y| x <=> y }
super(*args)
sort!(&sort_by)
end

def insert(ignore, *values)
values.each do |v|
# The next line could be further optimized to perform a
# binary search.
insert_before = index(find { |x| @sort_by.call(x, v) == 1 })
super(insert_before ? insert_before : -1, v)
end
end

def <<(v)
insert(0, v)
self
end

def push(*values)
insert(0, *values)
end
alias unshift push

Replace the second code sample with this:

%w[ []= collect! flatten! ].each do |method_name|
class_eval %{
def #{method_name}(*args)
super
sort!(&@sort_by)
end
}
end

def reverse
Array.new(super) # Return a normal array.
end

def reverse!
self
end
end

In the 'to_s' method of class Card:
"#{@suit} of #{@rank}" should be
"#{@rank} of #{@suit}"

In the 'initialize' method of class Deck, the parameters in the call to Card.new should be reversed, ie.
"Card.new(rank, suit)" should be
"Card.new(suit, rank)"

In the 'to_s' method of class Card:
"#{@suit} of #{@rank}" should be
"#{@rank} of #{@suit}"

In the 'initialize' method of class Deck, the parameters in the call to Card.new should be reversed, ie.
"Card.new(rank, suit)" should be
"Card.new(suit, rank)"

The XOR operator alone toggles permission bits rather than clearing
them. To clear bits it must be combined with the AND operator.

Replace the last paragraph before the first code sample with this:

Use the XOR (^) and the AND (&) operators to remove permissions from a
bitmap. Use the OR operator, as seen above, to add permissions:

Replace this line of code:

new_permission = File.lstat("my_file").mode ^ File::O_R

with this:

new_permission = File.lstat("my_file").mode & (0777 ^ File::O_R)

The XOR operator alone toggles permission bits rather than clearing
them. To clear bits it must be combined with the AND operator.

Replace the last paragraph before the first code sample with this:

Use the XOR (^) and the AND (&) operators to remove permissions from a
bitmap. Use the OR operator, as seen above, to add permissions:

Replace this line of code:

new_permission = File.lstat("my_file").mode ^ File::O_R

with this:

new_permission = File.lstat("my_file").mode & (0777 ^ File::O_R)

def between_setup_and_cleanup
setup
begin
yield
finally
cleanup
end
end

There is no such keyword as "finally" in Ruby. Substitute "ensure" for "finally".

def between_setup_and_cleanup
setup
begin
yield
finally
cleanup
end
end

There is no such keyword as "finally" in Ruby. Substitute "ensure" for "finally".

The paragraph starting "Your module can define an initialize method..." gives an inaccurate
picture. Add a sentence after the first sentence in the paragraph, like this:

...sometimes that doesn't work. If a module defines initialize, a
class that includes the module will no longer be able to call its
superclass's initialize method. There may also be a mismatch of
arguments. For instance, Taggable...

The paragraph starting "Your module can define an initialize method..." gives an inaccurate
picture. Add a sentence after the first sentence in the paragraph, like this:

...sometimes that doesn't work. If a module defines initialize, a
class that includes the module will no longer be able to call its
superclass's initialize method. There may also be a mismatch of
arguments. For instance, Taggable...

Similarly to the 317 erratum; this sentence is wrong: "When you call
super from within a method (such as initialize), Ruby finds every
ancestor that defines a method with the same name, and calls it too."

It should be this: "When you call super from within a method (such as
initialize), Ruby finds the first ancestor which defines a method with
the same name, and calls that method. That method may decide to call
super itself, sending Ruby searching even further back in the ancestor
tree, and so on."

The Class.included_modules method is redundant, because the Module
class already implements that method. This greatly simplifies the
code. The major difference is that newly included modules are
unshifted onto the beginning of the included_modules data structure,
rather than being pushed onto the end.

Replace the first code sample with this:

class Class
alias_method :old_new, :new
def new(*args, &block)
obj = old_new(*args, &block)
self.included_modules.each do |mod|
mod.initialize if mod.respond_to?(:initialize)
end
obj
end
end

Remove the second code sample.

Remove the references to Initializable in the third code sample:

module A
def self.initialize
puts "A's initialized."
end
end

module B
def self.initialize
puts "B's initialized."
end
end

Replace the final code sample with this:

class BothAAndB
include A
include B
end

both = BothAAndB.new
# B's initialized.
# A's initialized.

(The only change there is that B is now initialized before A. If this
disturbs you, you can substitute reverse_each for each in the first
code sample.)

The text of the Solution needs to be substantially rewritten to
accommodate this simplification; the Discussion a little less
so. Here's a rewrite of those two sections:

==Solution==

A class knows which modules it's included: you can get a list by
calling its Module#included_modules method.

```
Array.included_modules # => [Enumerable, Kernel]
```

To take advantage of this information when an object is initialized,
we need to redefine @Class#new@. Fortunately, Ruby's flexibility lets
us makes changes to the built-in @Class@ class (though this should
never be done lightly). Our new implemenation will call a module-level
@initialize@ method for each included module:

```
class Class
alias_method :old_new, :new
def new(*args, &block)
obj = old_new(*args, &block)
self.included_modules.each do |mod|
mod.initialize if mod.respond_to?(:initialize)
end
obj
end
end
```

We've redefined the @Class#new@ method so that it iterates through all
the modules in @included_modules@, and calls the module-level
@initialize@ method of each.

==Discussion==

Let's define a couple of modules which define @initialize@ module
methods:

```
module A
def self.initialize
puts "A's initialized."
end
end

module B
def self.initialize
puts "B's initialized."
end
end
```

We can now define a class that mixes in both modules:

```
class BothAAndB
include A
include B
end

BothAAndB.included_modules # => [B, A, Kernel]
```

Instantiating the class instantiates the modules, with not a single
@super()@ call in sight!

```
both = BothAAndB.new
# B's initialized.
# A's initialized.
```

The goal of this recipe is very similar to [[73160]]. In that recipe,
you call @super()@ in a class's @initialize@ method to call a mixed-in
module's @initialize@ method. That recipe doesn't require any changes
to built-in classes, so it's often preferable to this one.

But consider a case like the @BothAAndB@ class above. Using the
techniques from [[73160]], you'd need to make sure that both @A@ and
@B@ had calls to @super@ in their @initialize@ methods, so that each
module would get initialized. This solution moves all of that work
into the built-in @Class@ class. The other drawback of the previous
technique is that the user of your module needs to know to call
@super()@ somewhere in their @initialize@ method. Here, everything
happens automatically.

This technique is not without its pitfalls. Anytime you redefine
critical built-in methods like @Class#new@, you need to be careful:
someone else may have already redefined it elsewhere in your
program.

Similarly to the 317 erratum; this sentence is wrong: "When you call
super from within a method (such as initialize), Ruby finds every
ancestor that defines a method with the same name, and calls it too."

It should be this: "When you call super from within a method (such as
initialize), Ruby finds the first ancestor which defines a method with
the same name, and calls that method. That method may decide to call
super itself, sending Ruby searching even further back in the ancestor
tree, and so on."

The Class.included_modules method is redundant, because the Module
class already implements that method. This greatly simplifies the
code. The major difference is that newly included modules are
unshifted onto the beginning of the included_modules data structure,
rather than being pushed onto the end.

Replace the first code sample with this:

class Class
alias_method :old_new, :new
def new(*args, &block)
obj = old_new(*args, &block)
self.included_modules.each do |mod|
mod.initialize if mod.respond_to?(:initialize)
end
obj
end
end

Remove the second code sample.

Remove the references to Initializable in the third code sample:

module A
def self.initialize
puts "A's initialized."
end
end

module B
def self.initialize
puts "B's initialized."
end
end

Replace the final code sample with this:

class BothAAndB
include A
include B
end

both = BothAAndB.new
# B's initialized.
# A's initialized.

(The only change there is that B is now initialized before A. If this
disturbs you, you can substitute reverse_each for each in the first
code sample.)

The text of the Solution needs to be substantially rewritten to
accommodate this simplification; the Discussion a little less
so. Here's a rewrite of those two sections:

==Solution==

A class knows which modules it's included: you can get a list by
calling its Module#included_modules method.

```
Array.included_modules # => [Enumerable, Kernel]
```

To take advantage of this information when an object is initialized,
we need to redefine @Class#new@. Fortunately, Ruby's flexibility lets
us makes changes to the built-in @Class@ class (though this should
never be done lightly). Our new implemenation will call a module-level
@initialize@ method for each included module:

```
class Class
alias_method :old_new, :new
def new(*args, &block)
obj = old_new(*args, &block)
self.included_modules.each do |mod|
mod.initialize if mod.respond_to?(:initialize)
end
obj
end
end
```

We've redefined the @Class#new@ method so that it iterates through all
the modules in @included_modules@, and calls the module-level
@initialize@ method of each.

==Discussion==

Let's define a couple of modules which define @initialize@ module
methods:

```
module A
def self.initialize
puts "A's initialized."
end
end

module B
def self.initialize
puts "B's initialized."
end
end
```

We can now define a class that mixes in both modules:

```
class BothAAndB
include A
include B
end

BothAAndB.included_modules # => [B, A, Kernel]
```

Instantiating the class instantiates the modules, with not a single
@super()@ call in sight!

```
both = BothAAndB.new
# B's initialized.
# A's initialized.
```

The goal of this recipe is very similar to [[73160]]. In that recipe,
you call @super()@ in a class's @initialize@ method to call a mixed-in
module's @initialize@ method. That recipe doesn't require any changes
to built-in classes, so it's often preferable to this one.

But consider a case like the @BothAAndB@ class above. Using the
techniques from [[73160]], you'd need to make sure that both @A@ and
@B@ had calls to @super@ in their @initialize@ methods, so that each
module would get initialized. This solution moves all of that work
into the built-in @Class@ class. The other drawback of the previous
technique is that the user of your module needs to know to call
@super()@ somewhere in their @initialize@ method. Here, everything
happens automatically.

This technique is not without its pitfalls. Anytime you redefine
critical built-in methods like @Class#new@, you need to be careful:
someone else may have already redefined it elsewhere in your
program.

The code example that begins on page 338 and continues at the top of page 339. There are one too few end statements at the
top of page 339 to close all of the blocks in the example.

The code on those two pages should look like this:

class Object
def my_methods_only_no_mixins
self.class.ancestors.inject(methods) do |mlist, ancestor|
mlist = mlist - ancestor.instance_methods unless ancestor.is_a? Class
mlist
end
end
end

The code example that begins on page 338 and continues at the top of page 339. There are one too few end statements at the
top of page 339 to close all of the blocks in the example.

The code on those two pages should look like this:

class Object
def my_methods_only_no_mixins
self.class.ancestors.inject(methods) do |mlist, ancestor|
mlist = mlist - ancestor.instance_methods unless ancestor.is_a? Class
mlist
end
end
end

"Representing Data as MIDI Music" includes a line of
code to scale the data in an array of numbers so that it fits within
the range (21..108). This is the sixth line of code on page 444:

midi_note = (midi_min + ((number-midi_min) * (midi_max-low)/high)).to_i

This line is incorrect. It should be:

midi_note = (midi_min + ((number-low) * ((midi_max-midi_min)/(high-low)))).to_i

Recipe 12.5, "Adding Graphical Context with Sparklines" defines a
method called "scale" on page 421. This method is correct, but only
works when you need to scale a data set from 0 to 100. This
generalization works for any scale, making it reusable in recipe
12.14:

def scale(data, bottom=0, top=100)
min, max = data.min.to_f, data.max.to_f
scale_ratio = (top-bottom)/(max-min)
data.collect { |x| bottom + (x-min) * scale_ratio}
end

Omit the to_f calls if you want your data to be scaled using integer arithmetic.

Define that method, and you can write the loop on page 444 like this:

scale(self, midi_min, midi_max).each do |number|
midi_note = number.to_i

"Representing Data as MIDI Music" includes a line of
code to scale the data in an array of numbers so that it fits within
the range (21..108). This is the sixth line of code on page 444:

midi_note = (midi_min + ((number-midi_min) * (midi_max-low)/high)).to_i

This line is incorrect. It should be:

midi_note = (midi_min + ((number-low) * ((midi_max-midi_min)/(high-low)))).to_i

Recipe 12.5, "Adding Graphical Context with Sparklines" defines a
method called "scale" on page 421. This method is correct, but only
works when you need to scale a data set from 0 to 100. This
generalization works for any scale, making it reusable in recipe
12.14:

def scale(data, bottom=0, top=100)
min, max = data.min.to_f, data.max.to_f
scale_ratio = (top-bottom)/(max-min)
data.collect { |x| bottom + (x-min) * scale_ratio}
end

Omit the to_f calls if you want your data to be scaled using integer arithmetic.

Define that method, and you can write the loop on page 444 like this:

scale(self, midi_min, midi_max).each do |number|
midi_note = number.to_i

You can get cert validation in HTTPS even if you don't know where on
disk your certificates are located.

Replace the last paragraph on the page with this:

The OpenSSL library should know where your certificates are installed
on your computer. If you create an @OpenSSL::X509::Store@ object that
uses the default paths, you should be able to attach it to your
request object and then set the request's @verify_mode@ to
@OpenSSL::VERIFY_PEER@. Now OpenSSL can verify that you're really
talking to the web server you think you are, and not to an imposter:

Replace the code sample (spilling over onto the next page) with this:

request = Net::HTTP.new(uri.host, uri.port)
request.use_ssl = true
request.cert_store = OpenSSL::X509::Store.new
request.cert_store.set_default_paths
request.verify_mode = OpenSSL::SSL::VERIFY_PEER
response = request.get("/")
# => #<Net::HTTPOK 200 OK readbody=true>

You can get cert validation in HTTPS even if you don't know where on
disk your certificates are located.

Replace the last paragraph on the page with this:

The OpenSSL library should know where your certificates are installed
on your computer. If you create an @OpenSSL::X509::Store@ object that
uses the default paths, you should be able to attach it to your
request object and then set the request's @verify_mode@ to
@OpenSSL::VERIFY_PEER@. Now OpenSSL can verify that you're really
talking to the web server you think you are, and not to an imposter:

Replace the code sample (spilling over onto the next page) with this:

request = Net::HTTP.new(uri.host, uri.port)
request.use_ssl = true
request.cert_store = OpenSSL::X509::Store.new
request.cert_store.set_default_paths
request.verify_mode = OpenSSL::SSL::VERIFY_PEER
response = request.get("/")
# => #<Net::HTTPOK 200 OK readbody=true>

Query strings in fetched URLs are stripped (14.3, 14.20)

The code in Recipes 14.3 and 14.20 can't be used to request a URL that
contains a query string: the query string gets stripped. For instance,
if you tell it to retrieve "http://www.google.com/search?q=ruby", it
will actually retrieve "http://www.google.com/search".

The easiest way to solve this problem would be to pass the method that
makes the HTTP request the result of @URI#path_query@, instead of the
result of @URI#path@. Unfortunately, the @URI#path_query@ method is
private.

You have a couple options. You can modify the @URI@ class to make
@URI#path_query@ public. You can use the @send@ (Ruby 1.8) or
@funcall@ (Ruby 1.9) tricks to call the private method. You can also
duplicate the functionality of @URI@ (either within @URI@ or outside
it). This is the solution I've chosen.

If you want to create a new method that works like @URI#path_query@,
here's a simple standalone implementation:

```
def path_query(uri)
uri.path + (uri.query ? ('?' + uri.query) : '')
end
```

Otherwise, you can make the following in-place changes:

For 14.3, the first code chunk on page 505 contains this line:

```
return http.get(uri.path, headers)
```

Change it to look like this:

```
path_query = uri.path + (uri.query ? ('?' + uri.query) : '')
return http.get(path_query, headers)
```

Though it's not presented as reusable code, the first code chunk on
page 506 has the same problem. Change this:

```
request = Net::HTTP::Get.new(uri.path)
```

to this:

```
path_query = uri.path + (uri.query ? ('?' + uri.query) : '')
request = Net::HTTP::Get.new(path_query)
```

For 14.20, there's a code chunk on page 553 that looks like this:

```
response = request.send(action, uri.path, data)
```

Change it to this:

```
path_query = uri.path + (uri.query ? ('?' + uri.query) : '')
response = request.send(action, path_query, data)
```

A shorter solution is to send the whole URI: that is, the result of
@URI#to_s@. This worked well in my tests, but the HTTP 1.1 spec
(RFC2616) strongly implies that this format is only acceptable when
you're talking to an HTTP proxy.

Query strings in fetched URLs are stripped (14.3, 14.20)

The code in Recipes 14.3 and 14.20 can't be used to request a URL that
contains a query string: the query string gets stripped. For instance,
if you tell it to retrieve "http://www.google.com/search?q=ruby", it
will actually retrieve "http://www.google.com/search".

The easiest way to solve this problem would be to pass the method that
makes the HTTP request the result of @URI#path_query@, instead of the
result of @URI#path@. Unfortunately, the @URI#path_query@ method is
private.

You have a couple options. You can modify the @URI@ class to make
@URI#path_query@ public. You can use the @send@ (Ruby 1.8) or
@funcall@ (Ruby 1.9) tricks to call the private method. You can also
duplicate the functionality of @URI@ (either within @URI@ or outside
it). This is the solution I've chosen.

If you want to create a new method that works like @URI#path_query@,
here's a simple standalone implementation:

```
def path_query(uri)
uri.path + (uri.query ? ('?' + uri.query) : '')
end
```

Otherwise, you can make the following in-place changes:

For 14.3, the first code chunk on page 505 contains this line:

```
return http.get(uri.path, headers)
```

Change it to look like this:

```
path_query = uri.path + (uri.query ? ('?' + uri.query) : '')
return http.get(path_query, headers)
```

Though it's not presented as reusable code, the first code chunk on
page 506 has the same problem. Change this:

```
request = Net::HTTP::Get.new(uri.path)
```

to this:

```
path_query = uri.path + (uri.query ? ('?' + uri.query) : '')
request = Net::HTTP::Get.new(path_query)
```

For 14.20, there's a code chunk on page 553 that looks like this:

```
response = request.send(action, uri.path, data)
```

Change it to this:

```
path_query = uri.path + (uri.query ? ('?' + uri.query) : '')
response = request.send(action, path_query, data)
```

A shorter solution is to send the whole URI: that is, the result of
@URI#to_s@. This worked well in my tests, but the HTTP 1.1 spec
(RFC2616) strongly implies that this format is only acceptable when
you're talking to an HTTP proxy.

The paragraph at the bottom ("The @budget variable...") starts off
well-intentioned but rapidly becomes wrong. When the render method is
called the page is rendered with the current value of
@budget. Execution of the method continues, and the value of @budget
may change afterwards, but the page has already been rendered with the
old value. There is no "envelope".

Replace that paragraph (which spills over onto the next page) with the following:

The @budget variable gets set because execution of the current action
does not stop when you call render. Once render returns (having
rendered the page using the old value of @budget), the rest of the
index method runs and the value of @budget is changed.

The paragraph at the bottom ("The @budget variable...") starts off
well-intentioned but rapidly becomes wrong. When the render method is
called the page is rendered with the current value of
@budget. Execution of the method continues, and the value of @budget
may change afterwards, but the page has already been rendered with the
old value. There is no "envelope".

Replace that paragraph (which spills over onto the next page) with the following:

The @budget variable gets set because execution of the current action
does not stop when you call render. Once render returns (having
rendered the page using the old value of @budget), the rest of the
index method runs and the value of @budget is changed.

Refers to Recipe 16.7 as where the getQuote method was manually defined.
Should instead refer to Recipe 16.5.

Refers to Recipe 16.7 as where the getQuote method was manually defined.
Should instead refer to Recipe 16.5.

This code won't work and gives an inaccurate picture of what the
Logger class does:

# Keep data for today and the past 20 days
Logger.new('application.log', 20, 'daily')

If the second argument is a number, that number is the number of
logfiles to keep. In that case, the third argument is supposed to be
the maximum size of the logfile.

Replace the bad example with this one:

# Keep up to five logs, each of up to 100 megabytes in size.
Logger.new("application.log", 5, 100 * 1024 * 1024)

ISBN: 0-596-00797-3On page 671 I show how to customize the logger message by overriding
the @Logger::Formatter#call@ method. A less disruptive way to
customize the message is to subclass @Logger#Formatter@ and override
@call@ in the subclass. On page 671, replace the last code fragment
with this:

```
class MyLogger < Logger::Formatter
def initialize()
self.datetime_format=("%Y-%m-%d %H:%M:%S")
end
def call(severity, time, progname, msg)
Format % [severity, format_datetime(time), progname, msg]
end
end

$LOG.formatter = MyLogger.new
$LOG.error('This is much shorter.')
# ERROR [2006-03-31 19:35:01] This is much shorter.
```

To get a @Logger@ object to use a custom formatter, you need to set
its @formatter@ member, as seen above.

This code won't work and gives an inaccurate picture of what the
Logger class does:

# Keep data for today and the past 20 days
Logger.new('application.log', 20, 'daily')

If the second argument is a number, that number is the number of
logfiles to keep. In that case, the third argument is supposed to be
the maximum size of the logfile.

Replace the bad example with this one:

# Keep up to five logs, each of up to 100 megabytes in size.
Logger.new("application.log", 5, 100 * 1024 * 1024)

ISBN: 0-596-00797-3On page 671 I show how to customize the logger message by overriding
the @Logger::Formatter#call@ method. A less disruptive way to
customize the message is to subclass @Logger#Formatter@ and override
@call@ in the subclass. On page 671, replace the last code fragment
with this:

```
class MyLogger < Logger::Formatter
def initialize()
self.datetime_format=("%Y-%m-%d %H:%M:%S")
end
def call(severity, time, progname, msg)
Format % [severity, format_datetime(time), progname, msg]
end
end

$LOG.formatter = MyLogger.new
$LOG.error('This is much shorter.')
# ERROR [2006-03-31 19:35:01] This is much shorter.
```

To get a @Logger@ object to use a custom formatter, you need to set
its @formatter@ member, as seen above.

There is in fact a simple way to avoid deadlocking a thread with
itself: use the standard library's Monitor class instead of using Mutex.

Change "The second problem is harder to solve: a thread..." to "The second problem is that a thread..."

Replace "Short of hacking Mutex..." with "You can avoid this problem by using the Monitor class instead of Mutex."

Add the following code sample to the end of the Discussion:

require 'monitor'
$lock = Monitor.new
Thread.new do
$lock.synchronize { $lock.synchronize { puts 'I synchronized twice!' } }
end

There is in fact a simple way to avoid deadlocking a thread with
itself: use the standard library's Monitor class instead of using Mutex.

Change "The second problem is harder to solve: a thread..." to "The second problem is that a thread..."

Replace "Short of hacking Mutex..." with "You can avoid this problem by using the Monitor class instead of Mutex."

Add the following code sample to the end of the Discussion:

require 'monitor'
$lock = Monitor.new
Thread.new do
$lock.synchronize { $lock.synchronize { puts 'I synchronized twice!' } }
end

The file_mark and file_free functions should be defined above the file_allocate function.
Move the function bodies up so that the first code sample looks like this:

...
static void
file_mark(struct file *f)

The file_mark and file_free functions should be defined above the file_allocate function.
Move the function bodies up so that the first code sample looks like this:

...
static void
file_mark(struct file *f)

Cut the three paragraphs starting "There are some limitations you
should be aware of, though." The first limitation doesn't apply in
current versions (though the RubyInline README still talks about it),
and the second was described in a confusing way.

Replace the two paragraphs starting "Second, if you're..." with the
following:

When it comes time to distribute your program, RubyInline lets you
package a precompiled extension as a RubyGem (see the RubyInline docs
on the @inline_package@ script for details). If you don't distribute
a precompiled extension, your users will need to compile it
themselves. This means they'll need to have the Ruby development
libraries installed, along with a compiler to actually build the
extension.

Cut the three paragraphs starting "There are some limitations you
should be aware of, though." The first limitation doesn't apply in
current versions (though the RubyInline README still talks about it),
and the second was described in a confusing way.

Replace the two paragraphs starting "Second, if you're..." with the
following:

When it comes time to distribute your program, RubyInline lets you
package a precompiled extension as a RubyGem (see the RubyInline docs
on the @inline_package@ script for details). If you don't distribute
a precompiled extension, your users will need to compile it
themselves. This means they'll need to have the Ruby development
libraries installed, along with a compiler to actually build the
extension.