[#33511] [Ruby 1.9-Bug#4108][Open] irb hangs on Windows with trunk — Heesob Park <redmine@...>
Bug #4108: irb hangs on Windows with trunk
[#33521] [Ruby 1.9-Feature#4111][Open] Add XLIST support to Net::IMAP — Geoff Youngs <redmine@...>
Feature #4111: Add XLIST support to Net::IMAP
[#33530] [Ruby 1.9-Bug#4113][Open] Cannot build trunk with MSVC. — Heesob Park <redmine@...>
Bug #4113: Cannot build trunk with MSVC.
[#33583] Initialization time — SASADA Koichi <ko1@...>
Hi,
[#33605] Why is SyncEnumerator in REXML? — Asher <asher@...>
in 1.8 SyncEnumerator is in lib/generator.rb; in 1.9 it is in =
On Dec 6, 2010, at 11:09 PM, Asher wrote:
If that is the case, it would make sense historically, but doesn't seem =
[#33628] [Ruby 1.8-Bug#4132][Open] Socket.close attempting to close the socket twice — Claudio Villalobos <redmine@...>
Bug #4132: Socket.close attempting to close the socket twice
[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>
Bug #4136: Enumerable#reject should not inherit the receiver's instance variables
Issue #4136 has been updated by Marc-Andre Lafortune.
Hi,
[#33648] Why doesn’t StringIO implement #freeze? — Nikolai Weibull <now@...>
IO implements #freeze, but StringIO doesn=E2=80=99t. =C2=A0What=E2=80=99s u=
Hi,
On Fri, Dec 31, 2010 at 03:09, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#33656] [Ruby 1.9-Bug#4141][Open] Tk extension is not accepting any type of parameter combination — Luis Lavena <redmine@...>
Bug #4141: Tk extension is not accepting any type of parameter combination
Hi,
On Sun, Dec 26, 2010 at 10:05 PM, Hidetoshi NAGAI
[#33661] [Ruby 1.9-Feature#4145][Open] The result of UTF-16 encoded string concatenation — Heesob Park <redmine@...>
Feature #4145: The result of UTF-16 encoded string concatenation
Issue #4145 has been updated by Yui NARUSE.
[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>
Bug #4149: Documentation submission: syslog standard library
Issue #4149 has been updated by mathew murphy.
[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>
Hi.
2010/12/12 "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp>:
Hello Akira,
2010/12/20 "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp>:
Hi!
2010/12/27 Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca>:
Hi!
[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>
Hey folks,
On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:
On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:
(2010/12/13 1:54), Haase, Konstantin wrote:
(2010/12/13 9:06), Ryan Davis wrote:
On Sun, Dec 12, 2010 at 6:33 PM, Ryan Davis <ryand-ruby@zenspider.com> wrot=
On Dec 14, 2010, at 09:47 , Charles Oliver Nutter wrote:
On Tue, Dec 14, 2010 at 2:54 AM, Haase, Konstantin
On Sun, Dec 12, 2010 at 7:09 PM, Ryan Davis <ryand-ruby@zenspider.com>wrote:
[#33690] [Ruby 1.9-Bug#4153][Open] Minitest or ruby bug - wrong return code — Robert Pankowecki <redmine@...>
Bug #4153: Minitest or ruby bug - wrong return code
[#33735] [Ruby 1.9-Bug#4163][Assigned] RubyGems uses deprecated API: YAML.quick_emit. — Yui NARUSE <redmine@...>
Bug #4163: RubyGems uses deprecated API: YAML.quick_emit.
On Thu, Dec 16, 2010 at 04:46:33AM +0900, Yui NARUSE wrote:
[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>
Bug #4168: WeakRef is unsafe to use in Ruby 1.9
Issue #4168 has been updated by Kurt Stephens.
[#33779] [Ruby 1.9-Bug#4174][Open] 1F1E on rdoc tests — Kouhei Yanagita <redmine@...>
Bug #4174: 1F1E on rdoc tests
[#33801] [Ruby 1.9-Feature#4183][Open] [ext/openssl] Timestamp support — Martin Bosslet <redmine@...>
Feature #4183: [ext/openssl] Timestamp support
On Wed, Dec 22, 2010 at 03:19:12AM +0900, Martin Bosslet wrote:
[#33814] [Ruby 1.9-Bug#4185][Open] ruby 1.9.2 p0 installation issue — ravish nayak <redmine@...>
Bug #4185: ruby 1.9.2 p0 installation issue
[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>
As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.
Hi,
[#33818] [Ruby 1.9-Bug#4188][Open] minitest warnings in 1.9.3 — Aaron Patterson <redmine@...>
Bug #4188: minitest warnings in 1.9.3
[#33825] PATCH: REE fast-thread.patch: stack_free() not called in rb_thread_die(). — Kurt Stephens <ks@...>
http://code.google.com/p/rubyenterpriseedition/issues/detail?id=57
Similar technique might be relevant in MRI 1.9 if fiber/continuation
> Similar technique might be relevant in MRI 1.9 if fiber/continuation stacks
[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, Dec 23, 2010 at 9:47 AM, Yuki Sonoda (Yugui) <yugui@yugui.jp> wrote=
On Thu, Dec 23, 2010 at 9:47 AM, Yuki Sonoda (Yugui) <yugui@yugui.jp> wrote=
[#33845] Getting involved in Ruby — Benoit Daloze <eregontp@...>
Hi dear Ruby core team !
[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>
Feature #4197: Improvement of the benchmark library
Issue #4197 has been updated by Yui NARUSE.
[#33852] [Ruby 1.9-Bug#4199][Open] make test ruby-1.9.2-p0 failed on Solaris10 x86 — Dmitry Perfilyev <redmine@...>
Bug #4199: make test ruby-1.9.2-p0 failed on Solaris10 x86
[#33864] [Backport92-Backport#4200][Open] minitest 2.0.2 on trunk — Ryan Davis <redmine@...>
Backport #4200: minitest 2.0.2 on trunk
Issue #4200 has been updated by Ryan Davis.
[#33880] As platform mantainer - what are my boundaries? — Luis Lavena <luislavena@...>
Hello,
Hello,
On Sun, Dec 26, 2010 at 9:50 PM, U.Nakamura <usa@garbagecollect.jp> wrote:
On Mon, Dec 27, 2010 at 11:05 AM, Luis Lavena <luislavena@gmail.com> wrote:
Luis,
On Wed, Dec 29, 2010 at 1:31 AM, Yugui <yugui@yugui.jp> wrote:
[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>
Feature #4211: Converting the Ruby and C API documentation to YARD syntax
Issue #4211 has been updated by Yui NARUSE.
On Mon, Dec 27, 2010 at 12:01:00PM +0900, Yui NARUSE wrote:
On Dec 26, 2010, at 13:00, Loren Segal wrote:
[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>
Bug #4214: Fiddle::WINDOWS =3D=3D false on Windows
Issue #4214 has been updated by Luis Lavena.
[#33948] Multi-line comments — Rodrigo Rosenfeld Rosas <rr.rosas@...>
I was always curious about the reasoning Ruby doesn't support
On Mon, Dec 27, 2010 at 8:55 PM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com
On 28-12-2010 01:54, Joshua Ballanco wrote:
[#33951] [Ruby 1.9-Bug#4217][Open] irb exits unexpectedly with non-ascii Regexp on Windows — Heesob Park <redmine@...>
Bug #4217: irb exits unexpectedly with non-ascii Regexp on Windows
Issue #4217 has been updated by Heesob Park.
[#33953] my redmine login is not working and wanted to submit a bug — deepak kannan <kannan.deepak@...>
hi,
[#34011] [Backport92-Backport#4228][Open] Backward gemspec compatibility change in r29663 broke rake gems — Luis Lavena <redmine@...>
Backport #4228: Backward gemspec compatibility change in r29663 broke rake gems
[#34023] ruby -h doesn't include --disable-gems — Ryan Davis <ryand-ruby@...>
Is there a reason why ruby -h doesn't show --disable-gems ?
2011/1/4 Ryan Davis <ryand-ruby@zenspider.com>:
On Tue, Jan 4, 2011 at 12:14 AM, KOSAKI Motohiro
[ruby-core:33921] Re: [feature:trunk] Enumerable#categorize
Hi!
On Sat, Dec 25, 2010 at 3:45 AM, Tanaka Akira <akr@fsij.org> wrote:
> I feel many people needs hash creation.
I fully agree.
This is why I didn't want to admit that, like others have said, I find
`categorize` overly complex.
I have an alternate proposition of a modified `categorize` which I
believe addresses the problems I see with it:
1) Complex interface (as was mentioned by others)
2) By default, `categorize` creates a "grouped hash" (like group_by),
while there is not (yet) a way to create a normal hash. I would
estimate that most hash created are not of the form {key =3D> [some
list]} and I would rather have a nicer way to construct the other
hashes too. This would make for a nice replacement for most
"inject({}){...}" and "Hash[enum.map{...}]".
My alternate suggestion is a simple method that uses a block to build
the key-value pairs and an optional Proc/lambda/symbol to handle key
conflicts (with the same arguments as the block of `Hash#merge`). I
would name this simply `associate`, but other names could do well too
(e.g. `mash` or `graph` or even `to_h`).
# enum.associate(merge =3D nil){ block } # =3D> a_hash
#
# Builds +a_hash+ by iterating on +enum+. If the result of the block
is an array,
# it is interpreted as [key, value]. Otherwise the value is the result
of the block
# and corresponding key is the (first) yielded item.
# In case of key duplication, `merge` will be used. If +nil+, the
value is overwritten;
# if it is a symbol, then it is sent to the first value with the other
value as argument
# otherwise `merge` is called with the arguments
# +key+, +first_value+, +other_value+ (see Hash#merge)
# and the value will be the result of the call.
# Passing no block is equivalent to the block {|v| v}
#
# (1..4).associate{|i| i ** i} # =3D> {1 =3D> 1, 2 =3D> 2, 3 =3D> 27, 4 =
=3D> 256}
# (1..4).associate{|i| ["HELLO"[i], i]} # =3D> {"E" =3D> 1, "L" =3D> 3, =
"O" =3D> 4}
# [[:foo, 10], [:bar, 30], [:foo, 32]].associate(:+) # =3D> {:foo =3D>
42, :bar =3D> 30}
# {1 =3D> :foo, 2 =3D> "bar"}.associate{|k, v| v.upcase} # =3D> {1 =3D>
:FOO, 2 =3D> "BAR"}
# {1 =3D> 2, 3 =3D> 4}.associate{|k, v| [k.to_s, v]} # =3D> {"1" =3D> 2,=
"3" =3D> 4}
# A Ruby implementation could look like:
module Enumerable
def associate(merge_func =3D nil)
if merge_func.is_a? Symbol
sym =3D merge_func
merge_func =3D ->(k, v1, v2){v1.send(sym, v2)}
end
h =3D {}
each do |key|
value =3D block_given? ? yield(key) : key
if value.is_a? Array
key, value =3D value
elsif key.is_a? Array
key =3D key.first
end
if h.has_key?(key) && merge_func
value =3D merge_func.call(key, h[key], value)
end
h[key] =3D value
end
h
end
end
It could of course be argued that both `associate` and `categorize`
should be added. That may very be; I just feel that `associate` should
be added in priority over `categorize`.
I find it very interesting that you posted some questions from
ruby-talk. I've recopied that list with the additional "solutions"
using associate. Some are longer, some are shorter, but I usually find
the associate solution more intuitive (except in the first example).
Thanks
--
Marc-Andr=E9
* [ruby-talk:351947]
orig =3D
{:day1 =3D> [[:name_person1, :room1], [:name_person2, :room2],
[:name_person3, :room2]],
:day2 =3D> [[:name_person1, :room1], [:name_person3, :room1],
[:name_person2, :room2]]}
# to
dest =3D
{:room1 =3D> [{:day1 =3D> [:name_person1]},
{:day2 =3D> [:name_person1, :name_person3]}],
:room2 =3D> [{:day1 =3D> [:name_person2, :name_person3]},
{:day2 =3D> [:name_person2]}]}
# This can be implemented as:
a =3D orig.map {|k, aa| aa.map {|e| [k, *e] }}.flatten(1)
dest =3D=3D a.categorize {|e| [e[2], e[0], e[1]] }
# For this first example, categorize is pretty natural.
# The funny thing is that the actual final output desired doesn't
require a hash;
# the poster is actually complicating his life. Anyways:
a =3D orig.flat_map{|day, list| list.associate(:+){|n, r| [r,
[n]]}.map{|r, l| [day, r, l]}}
dest =3D int.associate(:+){|day, room, list| [room, [{day =3D> list}]]}
# * [ruby-talk:347364]
orig =3D
[["2efa4ba470", "00000005"],
["2efa4ba470", "00000004"],
["02adecfd5c", "00000002"],
["c0784b5de101", "00000006"],
["68c4bf10539", "00000003"],
["c0784b5de101", "00000001"]]
dest =3D
{"2efa4ba470" =3D> ["00000005", "00000004"],
"02adecfd5c" =3D> ["00000002"],
"c0784b5de101" =3D> ["00000006", "00000001"],
"68c4bf10539" =3D> ["00000003"]}
p dest =3D=3D orig.categorize {|e| e }
p dest =3D=3D orig.associate(:+){|h, v| [h, [v]]}
# * [ruby-talk:372481]
orig =3D
[["A", "a", 1], ["A", "b", 2], ["B", "a", 1]]
dest =3D
{"A" =3D> {"a" =3D> 1, "b" =3D> 2},
"B" =3D> {"a" =3D> 1}}
dest =3D=3D orig.categorize(:op=3D>lambda {|x,y| y }) {|e| e }
dest =3D=3D orig.associate(:merge){|a, b, c| [a, {b=3D>c}]}
# * [ruby-talk:288931]
# Cut... is the same case as above
# * [ruby-talk:354519]
orig =3D
[["200912-829", 9],
["200912-893", 3],
["200912-893", 5],
["200912-829", 1],
["200911-818", 6],
["200911-893", 1],
["200911-827", 2]]
# to
dest =3D
[["200912-829", 10],
["200912-893", 8],
["200911-818", 6],
["200911-893", 1],
["200911-827", 2]]
This can be implemented as:
dest =3D=3D orig.categorize(:op=3D>:+) {|e| e }.to_a
dest =3D=3D orig.associate(:+).to_a
* [ruby-talk:344723]
a=3D[1,2,5,13]
b=3D[1,1,2,2,2,5,13,13,13]
# to
dest =3D
[[0, 0], [0, 1], [1, 2], [1, 3], [1, 4], [2, 5], [3, 6], [3, 7], [3, 8=
]]
# This can be implemented as:
h =3D a.categorize.with_index {|e, i| [e,i] }
b.map.with_index {|e, j| h[e] ? h[e].map {|i| [i,j] } : [] }.flatten(1=
)
# or
h =3D a.each_with_index.associate
b.map.with_index{|e, i| [h[e], i] }
# * [ruby-talk:327908]
orig =3D
[["377", "838"],
["377", "990"],
["377", "991"],
["377", "992"],
["378", "840"],
["378", "841"],
["378", "842"],
["378", "843"],
["378", "844"]]
# to
dest =3D
[["377", "838 990 991 992"],
["378", "840 841 842 843 844"]]
# This can be implemented as:
orig.categorize(:seed=3D>nil, :op=3D>lambda {|x,y| !x ? y.dup : (x << =
"
" << y) }) {|e| e }
# or
orig.associate(->(k, a, b){"#{a} #{b}"})
# or if duping the string is required (??):
orig.associate(->(k, a, b){a << " " << b}){|x, y| [x, y.dup]}
# * [ruby-talk:347700]
orig =3D ["a", "b", "a", "b", "b"]
# to
dest =3D [["a", "b"], [2, 3]]
# This can be implemented as:
h =3D orig.categorize(:op=3D>:+) {|e| [e, 1] }
dest =3D=3D [h.keys, h.values]
# or
h =3D orig.associate(:+){|e| 1}
dest =3D=3D [h.keys, h.values]
# * [ruby-talk:343511]
orig =3D
[1, 2, 3, 3, 3, 3, 4, 4, 5]
# to
dest =3D
{3=3D>4, 4=3D>2}
# This can be implemented as:
h =3D orig.categorize(:op=3D>:+) {|e| [e, 1] }
dest =3D=3D h.reject {|k,v| v =3D=3D 1 }
# or
h =3D orig.associate(:+){1}
dest =3D=3D h.reject {|k,v| v =3D=3D 1 }