[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[ruby-core:59686] Re: [ruby-trunk - Feature #7688] Error hiding with rb_rescue() on Comparable#==, #coerce and others

From: Benoit Daloze <eregontp@...>
Date: 2014-01-10 21:14:56 UTC
List: ruby-core #59686
On 10 January 2014 18:30, Aaron Patterson wrote:
> Ya, it makes sense.  It seems the <=> in Rails is just blindly calling a
> method on the parameter without checking that it's possible to compare.
> It does make more sense to just return nil from <=>.
>
> FWIW, I just had to do this:
>
>
https://github.com/rails/rails/commit/b0acc77edced44e47c8570bf7dddd4ce19f06cb0

Great! I managed to run and make the tests pass as well and made one of the
possible fixes: https://gist.github.com/eregon/969d6d7afbf069d8b4d1.

For the first case I would consider the new behavior to be a strict
improvement (throwing exceptions and hiding is not only slow but likely
hard to track down as I think you experienced in
http://tenderlovemaking.com/2013/05/21/one-danger-of-freedom-patches.html).

I think comparing things that should not be compared (for instance a Time
instance with nil or false) is a right opportunity to raise an exception to
warn you about a possible bug, and rescuing like it was done before would
just hide you the fact and most likely have as a consequence a longer than
usual debugging session.

For the second case there are many possible ways to avoid comparing the
TimeWithZone and the String, and I think your check makes it more robust.
In my patch I made the conversion String->Zone in the calling method to
keep the possible optimization if the String happened to be the already
assigned zone (the conversion is done in #in_time_zone just after anyway)
but I am not sure at all if it is worth the added complexity.

This change is not an easy change, it is annoying to have your code broken
and it might impact some code (although I think there are not so many
usages of including Comparable, not defining #== and calling #== with a
quite different object). Yet I think it is a good change because it reveals
either bugs or bad practices. Raising exceptions in #<=> is a bad practice
to me for the reasons mentioned above. And finally the most compelling
reason is avoiding the exception hiding consequences, like for instance a
simple mistyped variable in #<=> could now make all your instances "!=" and
you have about no other way than "-d" to know about it.

The fix is not always trivial either, I had to learn quite a bit about the
context to fix the rdoc cases. But the reasoning (thinking about why we are
comparing these different types of objects) likely makes the code better as
it ensures the comparisons are now intended and meaningful.

In This Thread