Sure.
Actually, my intention is, for all intents and purposes, identical to the old poster's. I
need to read from stored VLENs and write to an object that has a different memory layout.
(It's less critical, but it would also be nice to go the other way. I haven't tried that
yet.) I'm using an opaque datatype for the memory representation because that seemed to
be the best way to describe the data as far as HDF5 was concerned. Basically, all I'm
really trying to say is "Convert from a VLEN to this 'other' type of data, and I'll
tell you how to do it."
Specifically, I'm poking around at updating the LabVIEW<-> HDF5 library I
wrote several years back. The natural representation of the HDF5 VLEN is a LabVIEW
array (nearly all arrays in LabVIEW are variable length). However, the
representations of the two are different. As you know, a dataset containing HDF5
VLENs look like this in memory:
len 0
pointer 0 -> {data 0,0, data0,1, ...}
len 1
pointer 1 -> {data1,0, data1,1, ...}
...
However, LabVIEW's data looks (for the purposes of this discussion, anyway)
like this:
pointer0 -> {len 0, possible padding, data 0,0, data0,1 ...}
pointer1 -> {len 1, possible padding, data 1,0, data1,1 ...}
...
So, I create an opaque type to represent the LabVIEW pointer and register a
conversion function from the VLEN datatype to the opaque type. The theory was
that when the conversion function got called it would allocate the LabVIEW
arrays and convert the buffer from the vector of hvl_ts to a vector of LabVIEW
pointers.
I hadn't exactly figured out what would happen next. For atomic base types one
could simply copy the data. It's more complicated if the base type is compound
or something like that. In any case, it didn't matter because the buffer in the
conversion function didn't contain the correct (or at least expected) data in
the buffer when the conversion function was called.
Obviously one could call the read (e.g. H5Dread, H5Aread) function and then
after the fact convert from the hvl_t dataset to the LabVIEW dataset. However,
that has numerous downsides, e.g. what if this VLEN is a member of a compound
several levels down? How do I handle the multiple calls (attributes and
datasets, primarily) which could require this conversion? How do I efficiently
handle LabVIEW memory allocation?
Thanks,
Jason
On 9/25/2012 12:40 PM, Raymond Lu wrote:
Jason,
Could you explain more about your intention? Why do you want to convert VLEN
to opaque data? Thanks.
Ray
On Sep 25, 2012, at 10:14 AM, Jason Sommerville wrote:
I encountered a problem when attempting to register a conversion function to
convert VLENs to an opaque data type. After some digging, I came across this
three-year-old thread
http://hdf-forum.184993.n3.nabble.com/hdf-forum-VLEN-conversion-problems-td193957.html
which describes my problem exactly. To sum up, the memory buffer passed to my
conversion function appears to point to heap ids rather than to valid memory.
Also, and this was not mentioned in the older thread, the buf_stride parameter
is set to zero. Supposedly a bug report was filed (where?).
1) Has any progress been made on this issue?
2) Is there another way around this problem?
One idea that occurred to me is that it is conceivable that under normal
operation a built-in conversion function is normally called that converts from
the heap representation of VLENs to the memory representation. If so, is there
a way to call that function from my conversion?
Thanks,
Jason
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
