[#69892] [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API — normalperson@...
Issue #11339 has been reported by Eric Wong.
8 messages
2015/07/07
[#69983] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/07/15
normalperson@yhbt.net wrote:
[#69990] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— SASADA Koichi <ko1@...>
2015/07/16
On 2015/07/16 4:41, Eric Wong wrote:
[#69995] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/07/16
SASADA Koichi <ko1@atdot.net> wrote:
[#69984] $SAFE inside an Array — Bertram Scharpf <lists@...>
Hi,
4 messages
2015/07/15
[#70001] [Ruby trunk - Bug #11336] [Open] TestProcess#test_exec_fd_3_redirect failed on Solaris 10 — ngotogenome@...
Issue #11336 has been updated by Naohisa Goto.
4 messages
2015/07/16
[#70005] Re: [Ruby trunk - Bug #11336] [Open] TestProcess#test_exec_fd_3_redirect failed on Solaris 10
— Eric Wong <normalperson@...>
2015/07/16
Sorry, but I think rb_divert_reserved_fd seems a racy fix. I think the
[#70011] [Ruby trunk - Bug #11362] [Open] [PATCH] ensure Process.kill(:STOP, $$) is resumable — normalperson@...
Issue #11362 has been reported by Eric Wong.
3 messages
2015/07/17
[#70016] [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg — merch-redmine@...
Issue #11364 has been reported by Jeremy Evans.
8 messages
2015/07/17
[#70052] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Eric Wong <normalperson@...>
2015/07/20
merch-redmine@jeremyevans.net wrote:
[#70055] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Jeremy Evans <code@...>
2015/07/20
On 07/20 10:46, Eric Wong wrote:
[#70056] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Eric Wong <normalperson@...>
2015/07/21
Jeremy Evans <code@jeremyevans.net> wrote:
[#70103] [Ruby trunk - Feature #11375] Decreased Object Allocation in Pathname.rb — richard.schneeman@...
Issue #11375 has been updated by Richard Schneeman.
3 messages
2015/07/23
[#70156] [Ruby trunk - Bug #11396] Bad performance in ruby >= 2.2 for Hash with many symbol keys — dunric29a@...
Issue #11396 has been updated by David Unric.
3 messages
2015/07/28
[ruby-core:69902] [Ruby trunk - Bug #10594] Numeric#clamp
From:
0x0dea+redmine@...
Date:
2015-07-08 16:08:09 UTC
List:
ruby-core #69902
Issue #10594 has been updated by D.E. Akers. > I think there is even another option: Swapping the min and max values if they are passed in the wrong order. I suspect there is little to no precedent for allowing "position-independent positional arguments". It's true that they could be tolerated and correctly handled in the case of `#clamp`, but doing so would likely hide some logic error elsewhere in the program. `#between?` is a query method and thus observes the widespread convention of returning *only* either `true` or `false`. That nothing exists between 2 on the left and 1 on the right means `#between?` is correct not to raise given such input. I confess that I only suggested returning the receiver to pad the list. It *would* potentially indicate to the caller that the requested operation couldn't be performed, but that's precisely what exceptions are for. Silently swapping is antithetical to the very notion of positional arguments, returning `nil` is just going to make something else fail, and returning the receiver goes against the method's *raison d'棚tre*. The only potential alternative I see to raising an `ArgumentError` in the case of `min` > `max` would be to make them keyword arguments, but that would break symmetry with `#between?` and feels heavy-handed besides. ---------------------------------------- Bug #10594: Numeric#clamp https://bugs.ruby-lang.org/issues/10594#change-53320 * Author: Chris Johnson * Status: Open * Priority: Normal * Assignee: * ruby -v: 2.1.2 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- This is basically a re-opening of the feature request of issue#4573 (https://bugs.ruby-lang.org/issues/4574), which was closed due a naming debate. It seems the standard naming for restricting a number to a specified range is indeed 'clamp'. (1)(2)(3) As such, can we use Yusuke Endoh's original patch with the naming adjustments? If so, I can provide accordingly. Cheers. (1) http://www.rubydoc.info/github/epitron/epitools/Numeric:clamp (2) http://stackoverflow.com/questions/12020787/is-there-a-limit-clamp-function-in-ruby (3) https://developer.gnome.org/glib/stable/glib-Standard-Macros.html#CLAMP:CAPS ---Files-------------------------------- num_clamp.c (427 Bytes) -- https://bugs.ruby-lang.org/