[#23132] [Bug #1357] Fixing variables into specific CPU registers deemed overrated & may disturb compilers' optimizers — Ollivier Robert <redmine@...>
Bug #1357: Fixing variables into specific CPU registers deemed overrated & may disturb compilers' optimizers
[#23154] [Bug #1363] Wrong value for Hash of NaN — Heesob Park <redmine@...>
Bug #1363: Wrong value for Hash of NaN
Hi,
Hi,
Yukihiro Matsumoto wrote:
[#23168] [Bug #1367] flatten(0) is not consistent with flatten(), flatten(1), etc. — Paul Lewis <redmine@...>
Bug #1367: flatten(0) is not consistent with flatten(), flatten(1), etc.
Issue #1367 has been updated by Paul Lewis.
[#23174] [Feature #1371] FTPS Implicit — Daniel Parker <redmine@...>
Feature #1371: FTPS Implicit
[#23193] Regexp Encoding — James Gray <james@...>
I'm trying to document the Encoding Regexp objects receive for the =20
[#23194] [Feature #1377] Please provide constant File::NOATIME — Johan Walles <redmine@...>
Feature #1377: Please provide constant File::NOATIME
[#23231] What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file? — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>
Dear Ruby developers and users!
Wolfgang N叩dasi-Donner wrote:
Wolfgang N叩dasi-Donner wrote:
Michael Neumann schrieb:
[#23252] [Bug #1392] Object#extend leaks memory on Ruby 1.9.1 — Muhammad Ali <redmine@...>
Bug #1392: Object#extend leaks memory on Ruby 1.9.1
[#23267] StringIO: RubySpec violation — Hongli Lai <hongli@...99.net>
I ran RubySpec against the 1.8.6-p368 release. It seems that
[#23289] [Bug #1399] Segmentation fault is raised when you use a postgres gem — Marcel Keil <redmine@...>
Bug #1399: Segmentation fault is raised when you use a postgres gem
[#23297] Ruby Oniguruma question — Ralf Junker <ralfjunker@...>
I see that the Ruby source code contains modified and more recent version of the Oniguruma regular expression library.
[#23305] [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals — Gary Wright <redmine@...>
Bug #1403: Process.daemon should do a double fork to avoid problems with controlling terminals
Hi,
[#23311] [Bug #1404] Net::HTTP::Post failing when a post field contains ":" — Ignacio Martín <redmine@...>
Bug #1404: Net::HTTP::Post failing when a post field contains ":"
[#23318] [Feature #1408] 0.1.to_r not equal to (1/10) — Heesob Park <redmine@...>
Feature #1408: 0.1.to_r not equal to (1/10)
Issue #1408 has been updated by Roger Pack.
Issue #1408 has been updated by Marc-Andre Lafortune.
Issue #1408 has been updated by tadayoshi funaba.
Hi,
Hi.
[#23321] [Bug #1412] 1.8.7-p160 extmk.rb fails when cross compiling — Luis Lavena <redmine@...>
Bug #1412: 1.8.7-p160 extmk.rb fails when cross compiling
[ruby-core:23260] Re: [Feature #666](Rejected) Enumerable::to_hash
Thank you for this explanation. If I understand correctly, you want methods of Enumerable to remain as generic as possible and not assume anything of the elements (besides being comparable in some instances). I find this very reasonable indeed. Would Array#to_hash be more appropriate, then? Array has methods that assum= e some structure on elements of arrays. In particular, #assoc and #rassoc mak= e the exact same kind of assumptions that #to_hash would make, and #transpose too. As for the name, I believe that either #to_hash or #to_h would be the most appropriate names, and the choice between one or the other depending on if = a translation should occur automatically or not when calling Hash#replace and Hash::[]. (I think these are the only two?) If needed, I would be glad to reword this feature request for Array; it would be even simpler since no block would be needed and the behaviour the same as Hash::[]. I'm assuming that Hash::[] with an array of arrays is an official feature even though it's not yet documented (as per #1385), right? Thank you for your consideration, Marc-Andr=E9 On Sun, Apr 19, 2009 at 11:43 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wr= ote: > Hi, > > In message "Re: [ruby-core:23253] Re: [Feature #666](Rejected) > Enumerable::to_hash" > on Sun, 19 Apr 2009 08:52:54 +0900, trans <transfire@gmail.com> > writes: > > |I don't see why a corresponance in needed. It's simply a > |transformation. > > #to_hash (or whatever name of the method) can only transform > enumerable in certain format, e.g. enumerable of two-elements arrays. > I think this is too much assumption for a method of Enumerable. > > OK, I admit we already have some methods with presumption, e.g. > #sort, #min and #max to assume elements to be comparable, but their > usefulness is proven in the history of the language. Meanwhile, how > often do we need #to_hash? I haven't, at least. > > |I think the real problem lies in the name of the > |method proposed. Rather than #to_hash, for instance, in Facets this > |method is called #graph or #mash (for "map hash"). Maybe there is a > |better name to be had, but it certainly is a useful method to have at > |times. > > Any method can be useful for certain situation. The point is how > often and in what situation it is useful. I don't see that much > usefulness to make it built in. > > matz. > >