[#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:23189] Re: [Bug #1336] Change in string representation of Floats
I'm not sure I understand the difference between "mere string" and "human readable" representations. Could you give an example? 1.8 is similar enough to 1.9 that many straightforward scripts will run without change. However, Float#to_s is likely used in almost every script that uses Floats, even those that would otherwise run unchanged under 1.9. I think changing it introduces bugs in these for no great gain. Others on this thread have already said the same. I'm sure you meant that 0.1.inspect would produce "0.1" for the current trunk. I could see how careful string conversion could ensure that simple constant literals would always be preserved. The trouble really begins only after one starts doing arithmetic with them. What does the current trunk output for (2.1-3.0).to_s ? Consider that (here at least): 2.1-3.0+0.9 == 1.110223024625156540e-16 I'd like to be proven wrong, but I currently believe that the one cannot create a human friendly Float string conversion that is also a regenerating representation. - brent Yukihiro Matsumoto wrote: > > > to_s for arrays and hashes are changed in 1.9. > > Perhaps we need 3 ways for string representation: > > * mere string representation > * human readable representation > * regenerating representation (as in [ruby-core:23128]) > > |As a practical matter, changing Float#to_s at this point will cause many > no > |longer maintained Ruby scripts to output confusing long trains of digits > |after the decimal. And, consider the bugs that will emerge when data > base > |queries on ranges of values like 0.1 to 0.9, if the string > representations > |actually passed (from Ruby via Float.to_s) into the data base engine > (which > |for all we know is using decimal floats) are in fact 0.10000000000000001 > to > |0.90000000000000002 > > I'm not sure what you mean by "at this point". The point we move 1.8 > from 1.9 is the only point where we can make such changes. In > addition, the latest trunk gives you "0.1" for 1.0.inspect. > > matz. > > > -- View this message in context: http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23017694.html Sent from the ruby-core mailing list archive at Nabble.com.