Skip to content
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

Merged
merged 12 commits into from
Apr 25, 2015
Merged

Fix tuple types for 0.4 #232

merged 12 commits into from
Apr 25, 2015

Conversation

rened
Copy link
Contributor

@rened rened commented Apr 24, 2015

Continuing here from #228 to allow for collaborative editing.

@fundamental
Copy link

@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.

@rened
Copy link
Contributor Author

rened commented Apr 24, 2015

@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)
Copy link
Member

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...

@simonster
Copy link
Member

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))
Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

@simonster simonster changed the title WIP: fix tupe types for 0.4 WIP: fix tuple types for 0.4 Apr 24, 2015
@simonster
Copy link
Member

Filed JuliaLang/julia#10995 with test case

@simonster
Copy link
Member

Filed JuliaLang/julia#10998. This one I think I can work around.

@sebastiang
Copy link

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 SimpleVector issue myself, but perhaps you have a workaround? It caused me to file JuliaLang/julia#10999

@simonster
Copy link
Member

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.

@sebastiang
Copy link

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.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling e7e0594 on tuplefix into * on master*.

1 similar comment
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling e7e0594 on tuplefix into * on master*.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling ad00d79 on tuplefix into * on master*.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling ad00d79 on tuplefix into * on master*.

@timholy
Copy link
Member

timholy commented Apr 25, 2015

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).

@simonster
Copy link
Member

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.

@coveralls
Copy link

Coverage Status

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
@simonster simonster changed the title WIP: fix tuple types for 0.4 Fix tuple types for 0.4 Apr 25, 2015
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 64b9c30 on tuplefix into * on master*.

1 similar comment
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 64b9c30 on tuplefix into * on master*.

@simonster
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise here?

Copy link
Member

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.

@timholy
Copy link
Member

timholy commented Apr 25, 2015

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
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 12479c5 on tuplefix into * on master*.

simonster added a commit that referenced this pull request Apr 25, 2015
@simonster simonster merged commit 74d7f05 into master Apr 25, 2015
@simonster simonster deleted the tuplefix branch April 25, 2015 21:37
@rened
Copy link
Contributor Author

rened commented Apr 27, 2015

Thanks to you two for tackling the hard parts!

@timholy
Copy link
Member

timholy commented Apr 27, 2015

I didn't do anything, you two deserve the thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants