[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...
Issue #14357 has been reported by vo.x (Vit Ondruch).
11 messages
2018/01/15
[#85364] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
[email protected] wrote:
[#85368] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
Eric Wong wrote:
[#85442] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Eric Wong <[email protected]> wrote:
[#85451] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Vladimir Makarov <vmakarov@...>
2018/02/06
On 02/06/2018 05:00 AM, Eric Wong wrote:
[#85455] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Vladimir Makarov <[email protected]> wrote:
[#84874] [Ruby trunk Bug#14360] Regression CSV#open method for writing from Ruby 2.4.3 to 2.5.0 — shevegen@...
Issue #14360 has been updated by shevegen (Robert A. Heiler).
3 messages
2018/01/15
[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...
Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).
10 messages
2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/23
[email protected] wrote:
[#85081] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
Eric Wong <[email protected]> wrote:
[#85082] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
> Thinking about this even more; I don't think it's possible to
[#85088] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — danieldasilvaferreira@...
Issue #13618 has been updated by dsferreira (Daniel Ferreira).
3 messages
2018/01/25
[#85107] [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is? — eregontp@...
Issue #14222 has been updated by Eregon (Benoit Daloze).
3 messages
2018/01/25
[#85136] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/01/26
[ruby-core:85123] [Ruby trunk Feature#14399] Add Enumerable#product
From:
jzakiya@...
Date:
2018-01-25 18:41:18 UTC
List:
ruby-core #85123
Issue #14399 has been updated by jzakiya (Jabari Zakiya). That's interesting because I never intuitively understood the use of `inject`, especially for numerical purposes, and always now use `reduce`, which was (I believe) created by Haskell (the person and programming language), and has long been a concept in functional programming. To me it says that an array of numbers (items) will be reduced|collapsed into a single value based on the given operation. Also, after reading your comment and thinking about it, there is a way to reclaim the `product` method name and recast it for this new (better) use. A better name for the current `Array#product` is `Array#combine`, which has the same number of characters, so it can replace the word inplace in code without the need to possibly reformat it. ``` [1,2,3].product [5,6,7] which seems like a vector|matrix operation can be renamed as [1,2,3].combine [5,6,7] or even [1,2,3].combine_with [5,6,7} ``` I think this is much clearer indication of its intent and purpose. Here's a proposed path to reclaim and recast `product` as proposed. Ruby 2.6 Introduce `Array#combine(_with)` as an alias to the current `Array#product`. Replace its use in the Ruby core and stdlib code. Make announcement to deprecate use of `Array#product` to give people time to change. Introduce `Enumerable#multiply` to act as proposed `Enumerable#product`. Ruby 2.7 Eliminate use of `Array#product` Create `Enumerable#product` as alias of `Enumerable#multiply` Since everyone knows Ruby 3 is going to be a breaking some old code change, if people are weaned off old code use then this change really won't create problems. On one hand you are creating a new capability in `Enumerable#[product|multiply]` while keeping, but renaming, a current capability. Plus, I can't think that alot of code|people currently use `Array#product`, so I doubt it affects a lot of code|people. (Is this ever used in Rails, etc?) Python went through this going from 2 to 3, famously with the `print` method change. Basically what I'm illustrating, if there is a will there is a way to make this change, without a lot of disruption and pain. ---------------------------------------- Feature #14399: Add Enumerable#product https://bugs.ruby-lang.org/issues/14399#change-69837 * Author: jzakiya (Jabari Zakiya) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- For similar reasons for creating `Enumerable#sum` a companion method `Enumerable#product` is also very useful. Taking the product of numbers in arrays is a common operation in many numerical algorithms, especially in number theory and cryptography, and its optimization in Ruby will make it more conducive to math heavy algorithms and tasks. This ``` > [2,3,5,7].reduce(:*) => 210 ``` can be optimized to this ``` > [2,3,5,7].product => 210 ``` It should also allow an initial value ``` > [2,3,5,7].product(2) => 420 > [2,3,5,7].product(0.5) => 105 ``` Crystal already has this `method`. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
