Valentin Churavy

Yes =, we do need a new release. I have been hesitant to do so because we currently lack tests (#105) and without them it is very hard to gauge...

Yes and no... Not having a release is a clear documentation that this package currently does not have a maintainer and I am kinda hoping that someone would like to...

@bjarthur yes that might be possible. I would also be more than happy to give people the commit bit if they want to contribute to ClusterManagers.jl There is also https://github.com/JuliaParallel/MPIClusterManagers.jl

@DrChainsaw I gave you access/

Hm yes, that seems feasible. Sounds like you would want to use something like a https://github.com/JuliaArrays/FillArrays.jl, the only problem is that we don't support heterogeneous chunk-types. #170 as an example...

#170 modifies exactly the core constructor that you would want to modify. Once you have a DArray that is constructed in the way you want it comes with the challenge...

Hm yes I suspect that there might be quite some functions written with the assumption that each chunk will be on a different processor, even though it clearly doesn't need...

Hm that fails for me on current master: ``` D = DArray(ras) ERROR: MethodError: no method matching Zeros{Float64,2,Tuple{Int64,Int64}}(::Array{Float64,2}) Stacktrace: [1] empty_localpart(::Type, ::Int64, ::Type) at /home/vchuravy/.julia/dev/DistributedArrays/src/darray.jl:66 [2] macro expansion at ./task.jl:264...

Ah it works on #175..., but we need a method to select the "right" array-type. Since right now it could happen that it chooses a different T as a primary...

> (Is there a good development cycle for working from the master branch of a local repo?) I generally use `]dev` for that which can also take a local path...