Open ConnectedSystems opened 1 month ago
This seems to come from the show functions and might have been introduced in newer versions. You can try to suppress the printing by adding a semicolon at the end of the line. Then we would at least know, that it is constructing the YAXArray correctly.
Hi @felixcremer
Yes, suppressing the output makes the error go away:
julia> YAXArray(test_x);
┌ Warning: Can not determine size of element type. Using DiskArrays.fallback_element_size[] = 100 bytes
└ @ DiskArrays C:\Users\tiwanaga\.julia\packages\DiskArrays\bZBJE\src\chunks.jl:305
The problem is not only with AbstractTypes.
I have proposed a fix here: https://github.com/JuliaDataCubes/YAXArrays.jl/pull/421
This error is caused by this call to sizeof(T)
https://github.com/JuliaDataCubes/YAXArrays.jl/blob/eb75dfc2ed163e0bf31018061ed0534d6bd99404/src/Cubes/Cubes.jl#L502
The error message comes from the output of sizeof(Union{Int,String})
julia> sizeof(Union{Int,String})
ERROR: Argument is an abstract type and does not have a definite size.
Stacktrace:
[1] sizeof(x::Type)
@ Base .\essentials.jl:631
[2] top-level scope
@ REPL[61]:1
But that also happens when the type is String
, but the message is slightly different (meaning it doesn't happen only with AbstracTypes
):
julia> sizeof(String)
ERROR: Type String does not have a definite size.
Stacktrace:
[1] sizeof(x::Type)
@ Base .\essentials.jl:631
[2] top-level scope
@ REPL[60]:1
I understand that we don't want to prevent users to create YAXArrays of String
s and Union
s containing String
s, so I suggest we catch this error and don't show the file size in this specific cases. If the problem was only with AbstractTypes
we could use isabstracttype
instead, but that doesn't fix the String
case.
Not sure if I'm creating false memories but I thought in the past I could create YAXArrays with mixed types?