For the moment this is solved by me having removed indexing.jl, which we didn’t
really need. So I don’t think you need to do anything for the moment.
But I’d broadly like to know if we have any strategy for avoiding these kinds
of conflicts moving forward. It’s such an odd experience to find my code raises
warnings because of changes external to it.
— John
On Jan 20, 2014, at 7:52 PM, Amit Murthy <amit.mur...@gmail.com> wrote:
> What would be the best way to solve this?
>
> A SharedArray type has a regular Array backing it and we should make it
> usable wherever a regular Array can be used.
>
> Would the right thing to do be
>
> - get a list of getindex methods that operate on a regular Array
> - generate the same definitions for a SharedArray with a pass through to the
> backing Array
> - this would ensure that any further getindex definitions for an Array are
> automatically generated for SharedArray too
>
>
>
>
>
> On Tue, Jan 21, 2014 at 1:04 AM, John Myles White <johnmyleswh...@gmail.com>
> wrote:
> The recent SharedArray change to Base created some new ambiguity warnings for
> DataFrames.
>
> Warning: New definition
> getindex(AbstractArray{T,1},Indexer) at
> /Users/johnmyleswhite/.julia/DataFrames/src/indexing.jl:195
> is ambiguous with:
> getindex(SharedArray{T,N},Any...) at sharedarray.jl:156.
> To fix, define
> getindex(SharedArray{T,1},Indexer)
> before the new definition.
>
> — John
>
>
