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

Minimal Object Reference Implementation #279

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

JamesMc86
Copy link
Contributor

This PR includes changes to support object references as requested in #98.

It adds ObjectReference1 as pre-1.12 object references and ObjectReference2 as the new reference types based on the STD_REF type.

I've tried to make this useful without being too large and can build on it further.

Key questions for me are around the terminology as I'm quite new to HDF5 - let me know if that makes sense.

Other possible issues to consider:

  • Could we store the location in the references as well as it gets passed on nearly every call?
  • There is a todo in the DynValue that @mulimoen included - I'm not familiar with this to know what to do but I assume a supported type needs adding before release.
  • ObjectReference2 can't be supported in VarArray due to not implementing a Copy. I would propose adding a TryClone type that VarArray can take so we can support this. I'm happy to do this in another release.
  • The same basic structure can be used to add Region references and Attribute references in a future version.

mulimoen and others added 14 commits April 3, 2024 22:09
Added a trait for object references and refactored the StdReference as a
newtype (ObjectReference2) and behind the trait so we can support
it side by side with the older object references.
This commit represents an MVP for object references.

This includes the implementation of Object1 for 1.8 and later, and
Object2 for 1.12 and later.
The wrapper to H5RCopy is causing issues in some enviroments.

This commit removes it for now as it isn't critical to the basic object
implementation.
There appear to be bugs in the v1.12.0 version which certainly break
ObjectReference2 is an element in compound type. Other bugs were seen
previously as well so this appears to be a more stable option.
@JamesMc86
Copy link
Contributor Author

Obviously got into a bit of a mess here still so will mark as draft. I thought I had it.

One problem is bugs in 1.12.0 with references so now flagged as 1.12.1 required.

Another is with the VarLenArray I believe. Going to back out the changes to make them work with Non-Copy types and the ObjectReference2 will just not be supported in them at this point.

I've successfully got conda replicating another issue on 1.8 so I'll work on that too!

@JamesMc86 JamesMc86 changed the title Minimal Object Reference Implementation Draft: Minimal Object Reference Implementation Apr 14, 2024
Copy link
Collaborator

@mulimoen mulimoen left a comment

Choose a reason for hiding this comment

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

This looks great, just move a couple of structs and this should be ready to merge.

@@ -703,6 +703,7 @@ impl<'a> DynValue<'a> {
FixedUnicode(_) => DynFixedString::new(buf, true).into(),
VarLenAscii => DynVarLenString::new(buf, false).into(),
VarLenUnicode => DynVarLenString::new(buf, true).into(),
Reference(_x) => todo!(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we support this?

hdf5/src/hl/references/legacy.rs Show resolved Hide resolved
hdf5/src/hl/references/legacy.rs Show resolved Hide resolved
hdf5/src/hl/references/standard.rs Show resolved Hide resolved
@mulimoen
Copy link
Collaborator

I think we can lift the restriction of Copy on H5Type if we require derived types to be Copy. But this depends on what sort of issues we got for VarLenArray<ref> which could suggest something worse going on.

@JamesMc86
Copy link
Contributor Author

I think we can lift the restriction of Copy on H5Type if we require derived types to be Copy. But this depends on what sort of issues we got for VarLenArray<ref> which could suggest something worse going on.

Yes I think there is a way - the main issue is the ptr lifetime and implementing our own drop routine. I've been trying to think if there is a way to treat it as a slice so we get some for free but I guess it will always have the problem of needing to be C compatible with the HDF5 library.

I'm happy to have a go with this as well but didn't want to grow this PR any bigger!

@mulimoen
Copy link
Collaborator

I'm more than OK with keeping this PR small. We have #232 which attempts to solve the Copy problem.

@JamesMc86 JamesMc86 changed the title Draft: Minimal Object Reference Implementation Minimal Object Reference Implementation Apr 21, 2024
Co-authored-by: Magnus Ulimoen <[email protected]>
Signed-off-by: James McNally <[email protected]>
@JamesMc86
Copy link
Contributor Author

Just wanted to check what was blocking this and #243 as they will start blocking my project. Happy to do work here to unblock it. I see the falling brew install was removed in another PR anyway. I can try and triage the MinGW issue too

@mulimoen
Copy link
Collaborator

I would like an approval from @aldanor, but for me this is looking good to go. Note that only @aldanor has rights to release as of now (and a release is long overdue).

It would be great if you managed to track down the mingw error, it is present also on master so could be a separate PR.

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.

2 participants