[#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:23235] Re: [Bug #1336] Change in string representation of Floats
Hi,
2009/4/17 Roger Pack <redmine@ruby-lang.org>:
> Issue #1336 has been updated by Roger Pack.
>
>
>> In addition, the change actually attacked my some scripts... :-(
>
> Does it still break them? Can anyone give an example where the "more honest" #to_s broke their scripts (for my curiosity sake).
The script deals with distance data of Japanese railroad.
Roughly speaking, it reads a file containing a sequence of float
number with one digit after the decimal point, makes an array of
float, compares them (without calculation), and prints some of
them.
More roughly speaking:
print "max: #{ DATA.map {|x| x.to_f }.max }\n"
__END__
10.1
5.2
82.9
I expect it prints "maz: 82.9" but current ruby prints
"max: 82.90000000000001". It's annoying.
Of course, I know that this issue can be solved easily by fixed-
point integer or sprintf("%.1f", val), and have already solved
actually.
Even so, I thought this is just a compatibility problem and wanted
to know a reason why `round-trip' feature is more important than
compatibility.
Currently, I understand that this change is not for `round-trip'
feature but for `harassment against ignorance :)' as matz said in
[ruby-core:23199].
> It seems the general thought currently is that to_s should be "dishonest" and inspect should be "honest"?
I think both are not always "honest".
In fact, String#inspect hides its encoding. So, it may provide
"dishonest" representation that is evaluated to the different
string:
s = "\u3042".encode("UTF-16LE")
p s == eval(s.inspect) #=> false
p s == eval(s.dump) #=> true
--
Yusuke ENDOH <mame@tsg.ne.jp>