[ruby-core:42296] Re: [ruby-trunk - Bug #5663][Open] Combined map/select method

[ruby-core:42297] [ruby-trunk - Feature #5663] Combined map/select method

Issue #5663 has been updated by Thomas Sawyer.

In Facets it's called #compact_map, but that's only b/c I thought better of monkey patching #compact itself.

I think it would be a slick feature for #compact to take a block.

----------------------------------------
Feature #5663: Combined map/select method
https://bugs.ruby-lang.org/issues/5663

Author: Yehuda Katz
Status: Open
Priority: Normal
Assignee: 
Category: lib
Target version: 2.0.0

It is pretty common to want to map over an Enumerable, but only include the elements that match a particular
filter. A common idiom is:

enum.map { |i| i + 1 if i.even? }.compact

It is of course also possible to do this with two calls:

enum.select { |i| i.even? }.map { |i| i + 1 }

Both cases are clumsy and require two iterations through the loop. I'd like to propose a combined method:

enum.map_select { |i| i + 1 if i.even? }

The only caveat is that it would be impossible to intentionally return nil here; suggestions welcome. The
naming is also a strawman; feel free to propose something better.

--

-- 
http://bugs.ruby-lang.org/

[ruby-core:42298] Re: Fwd: RCR String#{last, first}

[ruby-core:42299] Re: [ruby-trunk - Feature #5663] Combined map/select method

Hi,

(12/02/01 11:18), Thomas Sawyer wrote:
> In Facets it's called #compact_map, but that's only b/c I thought better of monkey patching #compact itself.
> 
> I think it would be a slick feature for #compact to take a block.

Mere "compact" doesn't feel implying "map".

--

-- 
Nobu Nakada

[ruby-core:42300] [ruby-trunk - Feature #5903] Optimize st_table (take 2)

Issue #5903 has been updated by Nobuyoshi Nakada.

Another question about packing.
Why are PKEY_POS and PVAL_POS from the tail?
----------------------------------------
Feature #5903: Optimize st_table (take 2)
https://bugs.ruby-lang.org/issues/5903

Author: Yura Sokolov
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0

Given some of preparations to this patches already merged into ruby-trunk,
I suggest patches for improving st_table second time (first were #5789):

1) Usage of packing for st_table of any kind, not only for numeric hashes.

Most of hashes, allocated during page render in Rails are smaller than 6 entries.
In fact, during rendering "Issues" page of Redmine, 40% of hashes not even grows
above 1 entry. They are small options hashes, passed to numerous helper methods.

This patch packs hashes upto 6 entries in a way like numeric hashes from trunk.
Also it pack hashes of size 0 and 1 into `st_table` inself, so that there is no
need to allocate any "bins" at all.

https://github.com/ruby/ruby/pull/84.patch
https://github.com/ruby/ruby/pull/84

2) Usage of specialized pool for allocating st_table, st_table_entry structures
and st_table.bins of smallest size (11)

Usage of specialized pool for this allocations give great speedup for hash creation.
Also it gives countable reduction of memory consumption.

https://github.com/ruby/ruby/pull/83.patch
https://github.com/ruby/ruby/pull/83

First patch gives little overhead for creating hashes bigger than 6 entries when applied alone.
But both patches combined are not slower than ruby-trunk for hashes of any size.

Performance testing is here https://gist.github.com/1626602

--

-- 
http://bugs.ruby-lang.org/

[ruby-core:42301] [ruby-trunk - Feature #5663] Combined map/select method

Issue #5663 has been updated by Yura Sokolov.

I often wish to have methods, which likes to `inject` but do use return value of block for next iteration:

    class Enumerable
      def accum(container)
        each{|args| yield container, args}
        container
      end
    end

Then I could use it in following ways:
instead of

    enum.inject({}){|h, k| h[k] = true; h}
    enum.map{|ar| ar.select{|i| i.usefull?}}.flatten(1)
    enum.map{|i| i + 1 if i.even?}.compact

I could

    enum.accum({}){|h,k| h[k] = true}
    enum.accum([]){|res, ar| ar.each{|i| res << i if i.usefull?}}
    enum.accum([]){|res, i| res << i + 1 if i.even?}

Well, it is shorter only in case of `inject`, but I still will prefer such method, cause I don't stress GC with
many short living arrays.
And maybe two common `container`-s could have separate methods:

    class Enumerable
      def accum_hash(&block)
        accum({}, &block)
      end
      def accum_ar(&block)
        accum([], &block)
      end
    end

    enum.accum_hash{|h,k| h[k] = true}
    enum.accum_array{|res, ar| ar.each{|i| res << i if i.usefull?}}
    enum.accum_array{|res, i| res << i + 1 if i.even?}
----------------------------------------
Feature #5663: Combined map/select method
https://bugs.ruby-lang.org/issues/5663

Author: Yehuda Katz
Status: Open
Priority: Normal
Assignee: 
Category: lib
Target version: 2.0.0

It is pretty common to want to map over an Enumerable, but only include the elements that match a particular
filter. A common idiom is:

enum.map { |i| i + 1 if i.even? }.compact

It is of course also possible to do this with two calls:

enum.select { |i| i.even? }.map { |i| i + 1 }

Both cases are clumsy and require two iterations through the loop. I'd like to propose a combined method:

enum.map_select { |i| i + 1 if i.even? }

The only caveat is that it would be impossible to intentionally return nil here; suggestions welcome. The
naming is also a strawman; feel free to propose something better.

--

-- 
http://bugs.ruby-lang.org/

[ruby-core:42302] [ruby-trunk - Feature #5663] Combined map/select method

Issue #5663 has been updated by Nobuyoshi Nakada.

Yura Sokolov wrote:
> I often wish to have methods, which likes to `inject` but do use return value of block for next iteration:

Try each_with_object.

----------------------------------------
Feature #5663: Combined map/select method
https://bugs.ruby-lang.org/issues/5663

Author: Yehuda Katz
Status: Open
Priority: Normal
Assignee: 
Category: lib
Target version: 2.0.0

It is pretty common to want to map over an Enumerable, but only include the elements that match a particular
filter. A common idiom is:

enum.map { |i| i + 1 if i.even? }.compact

It is of course also possible to do this with two calls:

enum.select { |i| i.even? }.map { |i| i + 1 }

Both cases are clumsy and require two iterations through the loop. I'd like to propose a combined method:

enum.map_select { |i| i + 1 if i.even? }

The only caveat is that it would be impossible to intentionally return nil here; suggestions welcome. The
naming is also a strawman; feel free to propose something better.

--

-- 
http://bugs.ruby-lang.org/

[ruby-core:42303] [Ruby 1.8 - Bug #1693][Rejected] ARGF.rewind Doesn't Reset ARGF.lineno

Issue #1693 has been updated by Yui NARUSE.

Status changed from Open to Rejected

This WONTFIX on 1.8.
----------------------------------------
Bug #1693: ARGF.rewind Doesn't Reset ARGF.lineno
https://bugs.ruby-lang.org/issues/1693

Author: Run Paint Run Run
Status: Rejected
Priority: Low
Assignee: 
Category: 
Target version: 
ruby -v: ruby 1.9.2dev (2009-06-25 trunk 23854) [i686-linux]

=begin
 ARGF.rewind doesn't reset the current line number to 0. IO#rewind does. This happens on all Ruby versions I
have installed locally.

     $ ruby -ve 'p ARGF.lineno; ARGF.readline; ARGF.rewind; p ARGF.lineno' /etc/passwd
     ruby 1.9.2dev (2009-06-25 trunk 23854) [i686-linux]
     0
     1
=end

--

-- 
http://bugs.ruby-lang.org/

[ruby-core:42304] [ruby-trunk - Feature #5903] Optimize st_table (take 2)

Issue #5903 has been updated by Yura Sokolov.

Nobuyoshi Nakada wrote:
> Another question about packing.
> Why are PKEY_POS and PVAL_POS from the tail?

It allows hash values to be very close to each other, so that while loop in `find_packed_index` runs through
them very fast and does not touch another cache line of cpu.
And only when it found equal hash it jumps to check key. This allows searching in packed hash be even slightly
faster than in not packed hash of same size.

Initially I experiment with variable sized packed hashes, so that `num_bins` is used and they goes from
tail to avoid division by 3.
With fixed size this could be simplified.

I pushed a commit which places PKEY_POS and PVAL_POS after hashes, but in forward order.

They could be placed altogether (like `i*3`, `i*3+1`, `i*3+2`). `remove_packed_entry` should be
changed accordantly. I think, this could improve iteration over hash.
----------------------------------------
Feature #5903: Optimize st_table (take 2)
https://bugs.ruby-lang.org/issues/5903

Author: Yura Sokolov
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0

Given some of preparations to this patches already merged into ruby-trunk,
I suggest patches for improving st_table second time (first were #5789):

1) Usage of packing for st_table of any kind, not only for numeric hashes.

Most of hashes, allocated during page render in Rails are smaller than 6 entries.
In fact, during rendering "Issues" page of Redmine, 40% of hashes not even grows
above 1 entry. They are small options hashes, passed to numerous helper methods.

This patch packs hashes upto 6 entries in a way like numeric hashes from trunk.
Also it pack hashes of size 0 and 1 into `st_table` inself, so that there is no
need to allocate any "bins" at all.

https://github.com/ruby/ruby/pull/84.patch
https://github.com/ruby/ruby/pull/84

2) Usage of specialized pool for allocating st_table, st_table_entry structures
and st_table.bins of smallest size (11)

Usage of specialized pool for this allocations give great speedup for hash creation.
Also it gives countable reduction of memory consumption.

https://github.com/ruby/ruby/pull/83.patch
https://github.com/ruby/ruby/pull/83

First patch gives little overhead for creating hashes bigger than 6 entries when applied alone.
But both patches combined are not slower than ruby-trunk for hashes of any size.

Performance testing is here https://gist.github.com/1626602

--

-- 
http://bugs.ruby-lang.org/

[ruby-core:42305] [Backport87 - Backport #4339] Segmentation fault during Marshal.load

Issue #4339 has been updated by Jim Meyering.

Hello,
I encountered this bug on RHEL-6's ruby-1.8.7.299 and with .352 and
reported it against RHEL-6 via http://bugzilla.redhat.com/781561
Applying the patch,
  http://bugs.ruby-lang.org/attachments/2243/ruby-1.8.7-marshal.patch
solved our problem nicely.  Please consider it for upstream ruby 1.8.7.

The reproducer, http://bugs.ruby-lang.org/attachments/1446/REPRO4.rb
also triggers a segmentation fault with Fedora 16's ruby:

    $ ruby /t/REPRO4.rb
    /t/REPRO4.rb:35: [BUG] Segmentation fault
    ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

    zsh: abort (core dumped)  ruby /t/REPRO4.rb

----------------------------------------
Backport #4339: Segmentation fault during Marshal.load
https://bugs.ruby-lang.org/issues/4339

Author: Sean Bradly
Status: Feedback
Priority: Normal
Assignee: Shyouhei Urabe
Category: core
Target version: 

=begin
 Conditions that seem to have to be satisfied:

 1) A call to Marshal.load must be interrupted by a context switch.
 2) Another thread calls GC.start manually.
 3) The object being marshaled needs to have a lot of child objects to be reliable.

 This appears to be a thread-safety issue affecting Ruby 1.8.x only. It triggers reliably for me on:

 Ubuntu     -> ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-linux]
 Ubuntu-rvm -> ruby 1.8.7 (2010-12-23 patchlevel 330) [i686-linux]
 MacRuby    -> ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]
 Mac-rvm    -> ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-darwin10.4.0]
=end

--

-- 
http://bugs.ruby-lang.org/