Monday, May 21, 2018

What could the HDFGroup do to improve HDF5 (and HDF4)

Back in 2014, I tried to do a bit of cleanup on HDF4 & HDF5.  I'm sure my comments are long out of date...


A few things would accelerate contributions from the community:

  • Mirror the git repos to github and set them up to automatically get updated
  • Setup continuous integration (VI) with travis-ci, appveyor, coveralls, and/or other providers
  • Allow bugs and pull requests on github.  Then people can propose patches and make sure they don't break the builds
  • Make sure primary development is going towards the "master" branch.  That's were people expect to look for the latest changes with git based code.  That's what people expect to send you patches against.

Even and I wrote down some of what we do for GDAL, but it's getting out of date after a few years.  Use these and any other tool you can (e.g. clang-tidy modernize).

http://erouault.blogspot.com/2016/01/software-quality-improvements-in-gdal.html

Other things that I personally think would be great for the HDF team to do:

  • Sign up for OSS Fuzz.  Use google resources try to crash the code and send you bug reports
  • Change the tests to only write into a user controllable temp location.  I run tests from a CAS filesystem that is read only and the runner gets passed the location of where it is allowed to write.
  • Define what the acronyms are in files.  I don't remember what the "AC" means even when I'm in H5AC.c.
  • Drop things like who created each file and when.  Those things are in the version control history and are noise when debugging
  • Have more tests that try to do things in isolation - true unit tests.  e.g. just test a single function.  I usually expect that testing code should be as long or longer than each file.  And each test case only tests one thing
  • Make sure that the code becomes and stays whitespace clean.  Best is to use clang-format, but things like perl -pi -e 's/\s+\n/\n/g' work quite well
  • Don't use line feed characters in the source.  That makes viewing on large screens harder with some tools
  • Consider using a test framework like googletest/gunit.  Many people are experienced with these frameworks and can better follow your tests and contribute back
  • Switch to C++11 as the minimum version of C++.  So many things get easier/better e.g. https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11

Monday, May 7, 2018

Paywalled docs

"Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 460: Multiple talkers and multiple listeners - Ethernet interconnection - Safety and security"

This doc is out, but I have never read it. If the maritine community wants this stuff to really work, you need to be engaging security experts.  None of us that work on computer security are going to pay for this doc or any of it's siblings. It is time for the IEC to release all AIS/eNav standards as free docs. You need to get them in as many hands as possible if you want to get towards better systems.   Not just the big hardware and software providers...