[#79440] [Ruby trunk Bug#13188] Reinitialize Ruby VM. — shyouhei@...
SXNzdWUgIzEzMTg4IGhhcyBiZWVuIHVwZGF0ZWQgYnkgU2h5b3VoZWkgVXJhYmUuCgoKTWFydGlu
6 messages
2017/02/06
[#79441] Re: [Ruby trunk Bug#13188] Reinitialize Ruby VM.
— SASADA Koichi <ko1@...>
2017/02/06
On 2017/02/06 10:10, shyouhei@ruby-lang.org wrote:
[#79532] Immutable Strings vs Symbols — Daniel Ferreira <subtileos@...>
Hi,
15 messages
2017/02/15
[#79541] Re: Immutable Strings vs Symbols
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2017/02/15
Em 15-02-2017 05:05, Daniel Ferreira escreveu:
[#79543] Re: Immutable Strings vs Symbols
— Daniel Ferreira <subtileos@...>
2017/02/16
Hi Rodrigo,
[#79560] Re: Immutable Strings vs Symbols
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2017/02/16
Em 15-02-2017 22:39, Daniel Ferreira escreveu:
[ruby-core:79689] [Ruby trunk Bug#13237] Behavior for #dup and #clone on Rational/Complex/BigDecimal differs from Integer/Float
From:
ronnie@...
Date:
2017-02-22 16:17:29 UTC
List:
ruby-core #79689
Issue #13237 has been updated by Akira Matsuda. Will this be backported to 2.4? (IOW is this 2.4.0 bug or 2.5 new feature?) ---------------------------------------- Bug #13237: Behavior for #dup and #clone on Rational/Complex/BigDecimal differs from Integer/Float https://bugs.ruby-lang.org/issues/13237#change-63110 * Author: Marcus Stollsteimer * Status: Closed * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- Since the implementation of feature #12979, #dup and #clone on Integer and Float do not raise a `TypeError` anymore, and silently return self. Rational and Complex still raise an exception. I'm not sure whether this inconsistent behavior is intended or only an oversight. I guess all Numeric classes should behave in a similar way? Additionally, what is the intention regarding the returned object for non-immediate numeric values, should they return self or a new object? At the time being, BigDecimal (which already did allow #dup/#clone before the change) returns a new object, while Bignum integers return self. Current behavior: ``` ruby RUBY_VERSION # => "2.4.0" 1.dup # => 1 1.clone # => 1 1.5.dup # => 1.5 1.5.clone # => 1.5 Rational(1).dup rescue $! # => #<TypeError: can't copy Rational> Rational(1).clone rescue $! # => #<TypeError: can't copy Rational> Complex(1).dup rescue $! # => #<TypeError: can't copy Complex> Complex(1).clone rescue $! # => #<TypeError: can't copy Complex> require "bigdecimal" BigDecimal(1).dup # => 0.1e1 BigDecimal(1).clone # => 0.1e1 d = (1<<64) [d.object_id, d.dup.object_id, d.clone.object_id] # => [5134140, 5134140, 5134140] d = BigDecimal(1) [d.object_id, d.dup.object_id, d.clone.object_id] # => [5133040, 5132900, 5132840] ``` Old behavior: ``` ruby RUBY_VERSION # => "2.3.3" 1.dup rescue $! # => #<TypeError: can't dup Fixnum> 1.clone rescue $! # => #<TypeError: can't clone Fixnum> 1.5.dup rescue $! # => #<TypeError: can't dup Float> 1.5.clone rescue $! # => #<TypeError: can't clone Float> Rational(1).dup rescue $! # => #<TypeError: can't copy Rational> Rational(1).clone rescue $! # => #<TypeError: can't copy Rational> Complex(1).dup rescue $! # => #<TypeError: can't copy Complex> Complex(1).clone rescue $! # => #<TypeError: can't copy Complex> require "bigdecimal" BigDecimal(1).dup # => #<BigDecimal:101e270,'0.1E1',9(27)> BigDecimal(1).clone # => #<BigDecimal:101dfa0,'0.1E1',9(27)> ``` -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>