Fixing HDF-1.8 API for octave-3.2.x

[Kacper Kowalik]

Hi,
I've made a patch fixing HDF5 API in octave 3.2.x. It could be applied
when HDF5 is not compiled with backwards compatibility instead of
dropping --with-hdf5.
Best regards,
Kacper Kowalik


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

Kacper Kowalik wrote:
> Hi,
> I've made a patch fixing HDF5 API in octave 3.2.x. It could be applied
> when HDF5 is not compiled with backwards compatibility instead of
> dropping --with-hdf5.
> Best regards,
> Kacper Kowalik
>  

This patch will make Octave incompatible with older versions of HDF5 and
a minimum of HDF5 v1.8 will be required. Frankly, I don't see that as a
really bad thing as Octave will still build on older systems, just  
without HDF5 support. However, if this is done there is some code that
works around bugs or missing features in older versions of HDF5 that
should go. Basically anycode in

#ifndef HAVE_H5GGET_NUM_OBJS
#endif

or the else clause of the logical inverse of the above, and any code
that is run when the variable have_h5giterate_bug is true.

Also the autoconf test should be changed such that only HDF5 v1.8 or
later is considered as support, probably with a test of a function with
a v1.8 API..

Regards
David


--
David Bateman                                dbateman@...
35 rue Gambetta                              [phone] (Home)
92100 Boulogne-Billancourt FRANCE            [phone] (Mob)

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Kacper Kowalik]

Hi,
as I understood there was some kind of problem in <=hdf5-1.2.2 with
groups indexing in H5Giterate. Now it's long gone and things like !
HAVE_H5GGET_NUM_OBJS are obsolete and have_h5giterate_bug is always
false.
Initial cleaning is rather straightforward, but there is a catch...
Functions like H5Gget_num_objs and H5Giterate are depreciated in
HDF5-1.8, so the right way to do it would be to migrate to H5Gget_info
and H5Literate, already. However it's not that simple anymore. I could
look into it, but I would need some example HDF5 files or some simple
scripts for octave to check whether or not I've messed something up.
Best regards,
Kacper Kowalik

2009/8/22 David Bateman <dbateman@...>:

> This patch will make Octave incompatible with older versions of HDF5 and a
> minimum of HDF5 v1.8 will be required. Frankly, I don't see that as a really
> bad thing as Octave will still build on older systems, just  without HDF5
> support. However, if this is done there is some code that works around bugs
> or missing features in older versions of HDF5 that should go. Basically
> anycode in
>
> #ifndef HAVE_H5GGET_NUM_OBJS
> #endif
>
> or the else clause of the logical inverse of the above, and any code that is
> run when the variable have_h5giterate_bug is true.
>
> Also the autoconf test should be changed such that only HDF5 v1.8 or later
> is considered as support, probably with a test of a function with a v1.8
> API..
>
> Regards
> David
>
>
> --
> David Bateman                                dbateman@...
> 35 rue Gambetta                              [phone] (Home)
> 92100 Boulogne-Billancourt FRANCE            [phone] (Mob)
>
>

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

Kacper Kowalik wrote:

> Hi,
> as I understood there was some kind of problem in <=hdf5-1.2.2 with
> groups indexing in H5Giterate. Now it's long gone and things like !
> HAVE_H5GGET_NUM_OBJS are obsolete and have_h5giterate_bug is always
> false.
> Initial cleaning is rather straightforward, but there is a catch...
> Functions like H5Gget_num_objs and H5Giterate are depreciated in
> HDF5-1.8, so the right way to do it would be to migrate to H5Gget_info
> and H5Literate, already. However it's not that simple anymore. I could
> look into it, but I would need some example HDF5 files or some simple
> scripts for octave to check whether or not I've messed something up.
> Best regards,
> Kacper Kowalik
>
>  

Use the code is test/test_io.m in the testls function and modify it to
save to an hdf5 file and not delete it.. This will test most of the
types in octave with simple case and should catch most bugs if you port
completely to the HDF5 v1.8 API

D.


--
David Bateman                                dbateman@...
35 rue Gambetta                              [phone] (Home)
92100 Boulogne-Billancourt FRANCE            [phone] (Mob)

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On 23-Aug-2009, Kacper Kowalik wrote:

| as I understood there was some kind of problem in <=hdf5-1.2.2 with
| groups indexing in H5Giterate. Now it's long gone and things like !
| HAVE_H5GGET_NUM_OBJS are obsolete and have_h5giterate_bug is always
| false.
| Initial cleaning is rather straightforward, but there is a catch...
| Functions like H5Gget_num_objs and H5Giterate are depreciated in
| HDF5-1.8, so the right way to do it would be to migrate to H5Gget_info
| and H5Literate, already. However it's not that simple anymore. I could
| look into it, but I would need some example HDF5 files or some simple
| scripts for octave to check whether or not I've messed something up.

I would be in favor of cleaning things up.  How about doing it
incrementally, if possible, instead of submitting a jumbo patch that
tries to do everything at once?  How hard would it be to preserve
compatibility with older versions of HDF5?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Kacper Kowalik]

2009/8/27 John W. Eaton <jwe@...>:
> I would be in favor of cleaning things up.  How about doing it
> incrementally, if possible, instead of submitting a jumbo patch that
> tries to do everything at once?  How hard would it be to preserve
> compatibility with older versions of HDF5?

If you would like to preserve compatibility with 1.6 API it's rather
simple and I will do it that way.
As for the earlier versions (1.4, 1.2) I don't know, I haven't used
them but I would really recommend to drop the support for <1.6.
I'll try to divide changes into several patches.

Best regards,
Kacper Kowalik

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Kacper Kowalik]

Attached patches do the following:

1) octave-3.2.2-drop-ancient-hdf5.diff - removes now obsolete code
under 'HAVE_H5GGET_NUM_OBJS'
and 'have_h5giterate_bug' since hdf5>=1.6 includes H5GGET_NUM_OBJS and
is free of the h5giterate_bug.
As results it drops compatibility with hdf5-1.2 and hdf5-1.4

2) octave-3.2.2-simplify_and_prep_for_hdf5-18.diff - small changes in
configure.in and config.h.in,
now if HDF5>=1.8 is present on the system, new flag (HAVE_HDF5_18) is defined.
Unless HDF5-1.8 library was compiled with --with-default-api-version=v16

3) octave-3.2.2-add-hdf5_18.diff - brings HDF5-1.8 API octave while
retaining compatibility with HDF5-1.6

Best regards,
Kacper Kowalik




_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

Kacper Kowalik wrote:

Attached patches do the following:

1) octave-3.2.2-drop-ancient-hdf5.diff - removes now obsolete code
under 'HAVE_H5GGET_NUM_OBJS'
and 'have_h5giterate_bug' since hdf5>=1.6 includes H5GGET_NUM_OBJS and
is free of the h5giterate_bug.
As results it drops compatibility with hdf5-1.2 and hdf5-1.4

2) octave-3.2.2-simplify_and_prep_for_hdf5-18.diff - small changes in
configure.in and config.h.in,
now if HDF5>=1.8 is present on the system, new flag (HAVE_HDF5_18) is defined.
Unless HDF5-1.8 library was compiled with --with-default-api-version=v16

3) octave-3.2.2-add-hdf5_18.diff - brings HDF5-1.8 API octave while
retaining compatibility with HDF5-1.6

Best regards,
Kacper Kowalik

Were these patches ever applied? It would be nice to have them in the development tree to allow the use of HDF 1.8 natively..

D.

[John W. Eaton-3]

On 28-Oct-2009, dbateman wrote:

| Kacper Kowalik wrote:
| >
| > Attached patches do the following:
| >
| > 1) octave-3.2.2-drop-ancient-hdf5.diff - removes now obsolete code
| > under 'HAVE_H5GGET_NUM_OBJS'
| > and 'have_h5giterate_bug' since hdf5>=1.6 includes H5GGET_NUM_OBJS and
| > is free of the h5giterate_bug.
| > As results it drops compatibility with hdf5-1.2 and hdf5-1.4
| >
| > 2) octave-3.2.2-simplify_and_prep_for_hdf5-18.diff - small changes in
| > configure.in and config.h.in,
| > now if HDF5>=1.8 is present on the system, new flag (HAVE_HDF5_18) is
| > defined.
| > Unless HDF5-1.8 library was compiled with --with-default-api-version=v16
| >
| > 3) octave-3.2.2-add-hdf5_18.diff - brings HDF5-1.8 API octave while
| > retaining compatibility with HDF5-1.6
| >
| > Best regards,
| > Kacper Kowalik
| >
| >
|
| Were these patches ever applied? It would be nice to have them in the
| development tree to allow the use of HDF 1.8 natively..

No, I don't think they were applied.  Do they look OK to you?  If so,
I have no objection to applying them, though it would be slightly
easier to do that if they were hg changesets relative to the current
sources instead of simple context diffs relative to Octave 3.2.2.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

John W. Eaton wrote:
> No, I don't think they were applied.  Do they look OK to you?  If so,
> I have no objection to applying them, though it would be slightly
> easier to do that if they were hg changesets relative to the current
> sources instead of simple context diffs relative to Octave 3.2.2.
>
>  

Ok, I've started applying and pushing these patches

D.

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

John W. Eaton wrote:

> On 28-Oct-2009, dbateman wrote:
>
> | Kacper Kowalik wrote:
> | >
> | > Attached patches do the following:
> | >
> | > 1) octave-3.2.2-drop-ancient-hdf5.diff - removes now obsolete code
> | > under 'HAVE_H5GGET_NUM_OBJS'
> | > and 'have_h5giterate_bug' since hdf5>=1.6 includes H5GGET_NUM_OBJS and
> | > is free of the h5giterate_bug.
> | > As results it drops compatibility with hdf5-1.2 and hdf5-1.4
> | >
> | > 2) octave-3.2.2-simplify_and_prep_for_hdf5-18.diff - small changes in
> | > configure.in and config.h.in,
> | > now if HDF5>=1.8 is present on the system, new flag (HAVE_HDF5_18) is
> | > defined.
> | > Unless HDF5-1.8 library was compiled with --with-default-api-version=v16
> | >
> | > 3) octave-3.2.2-add-hdf5_18.diff - brings HDF5-1.8 API octave while
> | > retaining compatibility with HDF5-1.6
> | >
> | > Best regards,
> | > Kacper Kowalik
> | >
> | >
> |
> | Were these patches ever applied? It would be nice to have them in the
> | development tree to allow the use of HDF 1.8 natively..
>
> No, I don't think they were applied.  Do they look OK to you?  If so,
> I have no objection to applying them, though it would be slightly
> easier to do that if they were hg changesets relative to the current
> sources instead of simple context diffs relative to Octave 3.2.2.
>
>  

Ok, I've added these patches, including changelogs and keeping Kacper as
the author in the changelog, the commit and added him to the
contributors file.

Under the v1.6 and v1.8 builds I tested that appeared to work as advertised.

Regards
David
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave