You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
julia> a = Matrix{Int}[[12; 34], [56; 78]];
julia>@save"test.jld" a
julia>@load"test.jld"
ERROR:`convert` has no method matching convert(::Type{Array{Int64,2}}, ::Array{Int64,1})
in convert at base.jl:13in copy! at abstractarray.jl:149in convert at array.jl:220in read at /home/simon/.julia/HDF5/src/jld.jl:358in read at /home/simon/.julia/HDF5/src/jld.jl:286in read at /home/simon/.julia/HDF5/src/jld.jl:241in anonymous at no file
hdfgroup.org appears to be down right now, but if my memory serves, HDF5 vlen types have to no way to encode >1 dimension, so we'd either need to go back to saving these as references or come up with an alternative way to encode the dimensions.
FWIW, I'm not entirely convinced that saving arrays of arrays as vlen types is a great idea. With #102 (which I've incorporated into my work on #27) we can actually preserve the relationships among Julia data structures when saving them and reading them back out, but I think this can only be made to work if arrays are stored as references. OTOH, if performance entirely sucks otherwise we may have to use vlens, and maybe investigate saving an additional ID so that we can determine when two vlens point to the same array when we read the data out. But with #27 the performance situation with references should be at least a little better since we will no longer have to save the type name with every dataset.
The text was updated successfully, but these errors were encountered:
I think we should do some benchmarks with #27 before making a final decision. (I can presently get through all of the write tests and about half of the read tests, so it shouldn't be too far off.) For now, the easiest fix is probably to restrict the write method signature to vectors, which I think should be sufficient. I'll do that momentarily.
e.g.:
Presumably broken by 3a95493
hdfgroup.org appears to be down right now, but if my memory serves, HDF5 vlen types have to no way to encode >1 dimension, so we'd either need to go back to saving these as references or come up with an alternative way to encode the dimensions.
FWIW, I'm not entirely convinced that saving arrays of arrays as vlen types is a great idea. With #102 (which I've incorporated into my work on #27) we can actually preserve the relationships among Julia data structures when saving them and reading them back out, but I think this can only be made to work if arrays are stored as references. OTOH, if performance entirely sucks otherwise we may have to use vlens, and maybe investigate saving an additional ID so that we can determine when two vlens point to the same array when we read the data out. But with #27 the performance situation with references should be at least a little better since we will no longer have to save the type name with every dataset.
The text was updated successfully, but these errors were encountered: