[#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
[#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 tadayoshi funaba.
Hi,
Hi.
Issue #1408 has been updated by Marc-Andre Lafortune.
Issue #1408 has been updated by Roger Pack.
[#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:23120] Re: [Bug #1336] Change in string representation of Floats
brian ford wrote: > So, this decision takes a marginal case for which a perfectly good > mechanism already exists and promotes it to the common case. But > that's not all. The consequence for the common case is that 2.4 is > unnecessarily and uselessly echoed back to me as 2.3999999999999999. > > It is very poor interface design to promote a marginal case above a > common case. There is nothing that this change in representation makes > better in the common case. It makes the common case hideous. > > Floats are what they are. Use them as you will. Ruby used to have > nice, friendly representations of floats for humans. Nothing gained, > much lost. The decision should be reversed. Except that it was all a lie. If a float can't be represented accurately, Ruby should not mask that, because it further perpetuates the mistaken belief that floats are accurate in Ruby. Treating 2.39999999999999 as 2.4 accomplishes exactly one thing: it hides the true nature of floats. I can appreciate the desire to have arbitrary-precision floating-point math as the default in Ruby, but that's not the case right now. What we have in Ruby 1.8 and 1.9 before this change is the horrible middle ground of imprecise floats *pretending* to be precise. And we have run into real-world bugs where JRuby's original lack of float-masking caused application failures; people believed they could expect 2.4 in all cases instead of 2.399999999999999. We should not have had to make our floats lie. I would say either floats should always be arbitrary precision, or they should be honest about their imprecision. Anything else is doing the developer a disservice.