-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix tuple types for 0.4 #232
Conversation
@rened if you need a hand getting this to work let me know where to start modifying as this issue is a blocker for me as I need to get at my data to start debugging/replicating a gc bug somewhere deep inside the base julia. |
@fundamental Thanks! I am waiting to see whether Jeff's recent fix now works for @simonster |
!isa(T, (Union(Tuple, DataType)...)) && unknown_type_err(T) | ||
T = T::(Union(Tuple, DataType)...) | ||
function h5type(parent::JldFile, T::TupleType, commit::Bool) | ||
@assert isa(T, TupleType) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is supposed to be a no-op, right? Seeing as this is asserting, it seems like the wrong method is getting dispatched...
Jeff's fix helped a bit, but I think the underlying issue is actually a dispatch bug that I need to track down, and that was just something I noticed while trying to work around it. |
isopaque(t::DataType) = isempty(t.names) | ||
isopaque(t::TupleType) = t == EMPTY_TUPLE_TYPE | ||
# isopaque(t::DataType) = isempty(fieldnames(t)) | ||
isopaque(t::DataType) = isa(t, TupleType) ? t == EMPTY_TUPLE_TYPE : isempty(fieldnames(t)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how I noticed JuliaLang/julia#10978, but I think isopaque(t::TupleType)
should be called if isa(t, TupleType)
, and not this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests still fail without it, so the answer seems to be yes, although I'm not sure why.
Filed JuliaLang/julia#10995 with test case |
Filed JuliaLang/julia#10998. This one I think I can work around. |
Wish I'd looked earlier to see this work going on! Was hacking away at it a bit myself. Let me know if you need any help. I just got to the |
The SimpleVector issue is not really a bug, just an implementation change. It was among the easier things to handle. The PR here currently passes the test suite (although not the JLDArchives tests yet). However, you probably don't want to use it yet because I can't guarantee that any files you save with it will be readable by when this is in a state to be merged to master. Anything not involving tuples or types with fields that are tuples is probably okay, but anything else might not work. I also need to add more backwards compatibility tests to JLDArchives to see how badly this breaks reading older files, and fix that as best as I can. |
Understood! I have an aversion to magical reflection based serialization in any language, so was just planning on using the raw HDF5 interfaces mostly anyway. |
Changes Unknown when pulling e7e0594 on tuplefix into * on master*. |
1 similar comment
Changes Unknown when pulling e7e0594 on tuplefix into * on master*. |
Changes Unknown when pulling ad00d79 on tuplefix into * on master*. |
Changes Unknown when pulling ad00d79 on tuplefix into * on master*. |
Thanks a bunch for this, everyone! I'll also link JuliaLang/julia#10999 (comment) as a general issue of growing concern to me (but without me yet having carved out the time to find a general solution solution). |
I added test files to JLDArchives that have our entire test suite saved with 0.3 and master. Those tests all pass (files written with both versions can be read by both versions), except for the SubArray tests, which fail because the structure of the type has changed. (Maybe we should reconstruct the type in this case too instead of throwing an error.) This doesn't mean everything works, because covering all our code paths isn't actually sufficient to make sure that all old files can be read by newer Julia, but at least the situation is not too bad. |
Changes Unknown when pulling d596a3d on tuplefix into * on master*. |
It seems that tuples are now allowed as type parameters (and have been for some time; 0.3 works) so this can be simplified. This also fixes a test failure in readremote.jl on 0.4
Changes Unknown when pulling 64b9c30 on tuplefix into * on master*. |
1 similar comment
Changes Unknown when pulling 64b9c30 on tuplefix into * on master*. |
I can't figure out what's going on with the release build on OS X, which is intermittently failing with a completely empty log (??), but I suspect that's not related to the package at all. Other than that I think this is ready to merge. |
@@ -631,6 +659,9 @@ function jldatatype(parent::JldFile, dtype::HDF5Datatype) | |||
if T == UnsupportedType | |||
warn("type $typename not present in workspace; reconstructing") | |||
T = reconstruct_type(parent, dtype, typename) | |||
elseif T == Type | |||
# https://github.com/JuliaLang/julia/issues/10998 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not. I'll check.
It all looks great. Thanks to both of you! Merge at will. |
Converts between Tuple{} and () types depending on Julia version. Also fixes #218
On 0.4, we can't differentiate between these and tuples of types that were saved by earlier versions of Julia. In earlier versions of Julia, such tuples were not bits typed so they would not have been usable anyway. We can revisit this when we're ready to change the file format (perhaps as part of #204/#218)
This is a bit of a hack, but necessary to avoid collision
Changes Unknown when pulling 12479c5 on tuplefix into * on master*. |
Thanks to you two for tackling the hard parts! |
I didn't do anything, you two deserve the thanks! |
Continuing here from #228 to allow for collaborative editing.