[#35631] [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230 — Tomoyuki Chikanaga <redmine@...>

23 messages 2011/04/06

[#35632] [Ruby 1.9 - Bug #4559][Open] Proc#== does not match the documented behaviour — Adam Prescott <redmine@...>

13 messages 2011/04/06

[#35637] [Ruby 1.9 - Bug #4561][Open] 1.9.2 requires parentheses around argument of method call in an array, where 1.8.7 did not — Dave Schweisguth <redmine@...>

9 messages 2011/04/07

[#35666] caching of the ancestor chain — Xavier Noria <fxn@...>

Why does Ruby cache the ancestors chain? I mean, not why the implementation implies that, but why it works that way conceptually.

9 messages 2011/04/09

[#35734] [Ruby 1.9 - Feature #4574][Open] Numeric#within — redmine@...

16 messages 2011/04/13

[#35753] [Ruby 1.9 - Bug #4576][Open] Range#step miss the last value, if end-exclusive and has float number — redmine@...

61 messages 2011/04/14
[#39566] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Marc-Andre Lafortune <ruby-core@...> 2011/09/15

[#39590] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Marc-Andre Lafortune <ruby-core@...> 2011/09/16

[#39593] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Tanaka Akira <akr@...> 2011/09/16

2011/9/17 Marc-Andre Lafortune <ruby-core@marc-andre.ca>:

[#39608] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Masahiro TANAKA <masa16.tanaka@...> 2011/09/17

I have not been watching ruby-core, but let me give a comment for this issue.

[#35765] [Ruby 1.9 - Bug #4579][Open] SecureRandom + OpenSSL may repeat with fork — redmine@...

27 messages 2011/04/15

[#35866] [Ruby 1.9 - Bug #4603][Open] lib/csv.rb: when the :encoding parameter is not provided, the encoding of CSV data is treated as ASCII-8BIT — yu nobuoka <nobuoka@...>

13 messages 2011/04/24

[#35879] [Ruby 1.9 - Bug #4610][Open] Proc#curry behavior is inconsistent with lambdas containing default argument values — Joshua Ballanco <jballanc@...>

11 messages 2011/04/25

[#35883] [Ruby 1.9 - Bug #4611][Open] [BUG] Segementation fault reported — Deryl Doucette <me@...>

15 messages 2011/04/25

[#35895] [Ruby 1.9 - Feature #4614][Open] [RFC/PATCH] thread_pthread.c: lower RUBY_STACK_MIN_LIMIT to 64K — Eric Wong <normalperson@...>

10 messages 2011/04/25

[ruby-core:35617] Re: [Ruby 1.9 - Feature #4539][Assigned] Array#zip_with

From: Benoit Daloze <eregontp@...>
Date: 2011-04-05 10:50:15 UTC
List: ruby-core #35617
> http://redmine.ruby-lang.org/issues/4539
>
> Author: Michael Kohl
>
> Inspired by Haskell's ((|zipWith|)) function, I hacked on together for Ruby:
>
> 1,2,3].zip_with([6,5,4], :+) #=> [7, 7, 7]
> 1,2,3].zip_with([6,5,4]) { |a,b| 3*a+2*b } #=> [15, 16, 17]
>
> So far I only have a Ruby version of it:
>
> https://gist.github.com/731702b90757e21cadcb
>
> My questions:
>
> 1. Would this method be considered a worthwhile addition to Array?
>
> 2. I've never hacked on the C side of Ruby (read some parts of the source though) and my C is quite rusty. I'd like to change that, would somebody be willing to help me turn this into a proper patch?

Hello,

I'm answering here since redmine won't answer to my requests (even got a 500).

I think this new method would be redundant with Array#zip.
But I agree doing c.zip(d).map { |a,b| a+b } is a bit long.

So I propose to change the return value of Array#zip (and
Enumerable#zip) with a block from nil to the result #map would give
(so an Array of all yielded elements).

An unconditional nil is anyway not useful here, the only concern I see
might be the cost of creating this Array.
But I think many cases with block simulate #map and it would avoid
creating the intermediate Array in a.zip(b).map {}.

This would not address the case with a Symbol, which could be easily
detected as last argument as it is not Enumerable.
But blocks simplified by Symbol have rarely been accepted and I think
only changing the return value would already improve #zip a lot.

Here is a gist with a Ruby implementation of the modifications for
Array#zip: https://gist.github.com/903388
I'm wishing to do a C implementation if this feels right for others,
but I'd like to have opinions first.

What do you think?

In This Thread