Hi Jason,
Hmm, so you are registering your datatype conversion routine (with
H5Tregister) and then calling H5Dread on your dataset, expecting to get the
opaque values in your buffer?
Quincey
On Sep 25, 2012, at 12:07 PM, Jason Sommerville wrote:
> 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.
>>> [email protected]
>>> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> [email protected]
>> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
>
>
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> [email protected]
> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
