More fixes for core/array specs


#1

Hi,

This commit resolves the following failing specs:

Array#<=> properly handles recursive arrays (critical)
Array#initialize with (size, object=nil) uses the block value instead
of using the default value
Array#to_a does not return subclass instance on Array subclasses
Array#uniq! raises a TypeError on a frozen array if modification would
take place
Array#values_at returns an array of elements in the ranges when passes
ranges

From the commit message:

  • Removed unused allocateStorage argument from IListOps.First and
    IListOps.Last; Removed the manual protocol conversion bits in
    IListOps.Fetch
  • Fix IoOps.ToPrintedString to output a double converted to string
    using an invariant culture (Issue #597 NumericLiterals1 test fails
    under french culture)
  • IListOps.ValuesAt adds a null value to the result if the begin value
    of the specified range instance(s) is <= the length of the array and
    the end value is >= the length of the array.
  • Array#uniq! raises a TypeError on a frozen array if modification
    would take place.
  • Fixed ArrayOps.ToArray to return a new RubyArray instance with the
    elements of self if self is a RubyArray.Subclass.
  • Array#initialize with (size, object=nil) uses the block value
    instead of using the default value
  • Fixed IListOps.Compare to work with recursive arrays.

A diff is attached to this mail.

PS: This completes my previous commit by removing unused
allocateStorage arguments from IListOps.First and IListOps.Last.

Thanks,
Daniele


#2

Hi,

just a self-reply to point out that the changes in ArrayOps.ToArray
introduced a regression for Array#to_ary (reported by
core/array/to_ary) due to the different behaviour of Array#to_a and
Array#to_ary on subclasses of Array. I have already fixed this on my
local repository, I’m just waiting to have a few more commits to
rebase and push the next set of changes on github.

On Sat, Apr 18, 2009 at 13:31, Daniele A. removed_email_address@domain.invalid
wrote:

Array#uniq! raises a TypeError on a frozen array if modification would
under french culture)

http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN


Daniele A.
http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN


#3

Looks good!

In IListOps.UniqueSelf, any reason you do “bool frozen =
context.IsObjectFrozen(self);” upfront instead doing IsObjectFrozen when
you actually need it? If uniq! Is called on a
System.Collections.Generic.List, IsObjectFrozen will be expensive
since we have to keep the “frozen” bit on the side. (For RubyArray, we
will keep the bit as an instance field which will be cheap to access).
So for List objects which are already unique, it will be faster if
you can avoid doing IsObjectFrozen.

Note that simplicity trumps optimization unless you have hard data that
the optimization is required. I am only suggesting this optimization as
its trivial, and the code is as simple in either case…


#4

Good point, and I guess there is no real reason for doing that… it
wasn’t really an attempt to achieve optimization, it just turned out
like that as I honestly totally missed the case of already unique
lists :slight_smile: Adjustments scheduled for the next push of my commits.

On Sun, Apr 19, 2009 at 01:10, Shri B. removed_email_address@domain.invalid
wrote:

Subject: Re: [Ironruby-core] More fixes for core/array specs

Array#to_a does not return subclass instance on Array subclasses
using an invariant culture (Issue #597 NumericLiterals1 test fails

  • Fixed IListOps.Compare to work with recursive arrays.
    Daniele A.

Ironruby-core mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/ironruby-core


Ironruby-core mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/ironruby-core


Daniele A.
http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN