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

Reformat all Imath header comments to doxygen style #81

Merged
merged 5 commits into from
Feb 1, 2021

Conversation

cary-ilm
Copy link
Member

This is a large rewrite of all headers to reformat into doxygen style. Not yet final, still a work in progress so please review the style.

  • All members, methods, and functions are now documented, with the exception of half.
  • Some methods moved to new locations for better logical grouping.

The readthedocs output is here for work-in-progress reviewing:

https://cary-ilm-imath.readthedocs.io/en/latest/index.html

Some things still don't work:

  • I can't get sphinx to recognize certain functions when there are multiple functions with different signatures.
  • Not all functions are referenced in the rst docs yet.
  • Top-level information still needs some work

Signed-off-by: Cary Phillips <cary@ilm.com>
- All methods now have comments
- Some methods have been rearranged to fit into better logical groups

Still to do:
- Sphinx reports errors on some functions
- half not yet commented

Signed-off-by: Cary Phillips <cary@ilm.com>
@lgritz
Copy link
Contributor

lgritz commented Jan 28, 2021

I'll try to look this over tonight and give more detailed comments

Copy link
Contributor

@meshula meshula left a comment

Choose a reason for hiding this comment

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

That's a mighty diff! It looks good, I didn't spot anything needing a change.

Comment on lines 160 to 163
// ||||
// VVVV
/// ABCD
// Legend:
Copy link
Contributor

Choose a reason for hiding this comment

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

this is not going to be rendered in the docs in a way that makes any sense

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, the hex values don't show up, so I intended to leave these for just the header. The /// before the ABCD was a typo.

Comment on lines 7 to 15
/// @file ImathFrame.h
///
/// @brief Functions for computing reference frames.
///
/// These methods compute a set of reference frames, defined by their
/// transformation matrix, along a curve. It is designed so that the
/// array of points and the array of matrices used to fetch these
/// routines don't need to be ordered as the curve.
///
Copy link
Contributor

Choose a reason for hiding this comment

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

These comments will be lost. When you do a pure Doxygen run (to html), you end up with a "file by file" index (as well as class by class), and this stuff from @file will go to introduce each file. But the way you've arranged the docs through breathe and sphinx (which I approve), you are making class by class documentation, so the Doxygen comments on the files themselves will never show up anywhere.

I recommend transferring these @file comments to appropriate parts of the docs for the class themselves, or for just a collection of functions (not in a class), use a "group" appropriately to cluster functions and then these can become the group comments.

Copy link
Member Author

Choose a reason for hiding this comment

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

I removed the @file/@brief directives and left the introductory comments in non-doxygen style for the reader of the headers, and moved info to the appropriate to the class/functions as wel.

Comment on lines +21 to 35
/// Int64 - unsigned 64-bit integer
typedef unsigned __int64 Int64;
/// SInt64 - signed 64-bit integer
typedef __int64 SInt64;
#elif ULONG_MAX == 18446744073709551615LU
/// Int64 - unsigned 64-bit integer
typedef long unsigned int Int64;
/// SInt64 - signed 64-bit integer
typedef long int SInt64;
#else
/// Int64 - unsigned 64-bit integer
typedef long long unsigned int Int64;
/// SInt64 - signed 64-bit integer
typedef long long int SInt64;
#endif
Copy link
Contributor

Choose a reason for hiding this comment

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

Aside -- I can't quite remember, why do we still have these instead of using stdint?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is worth a bigger discussion, can we eliminate this type declaration altogether? At the very least, the names are inconsistent and confusing. But they're used throughout OpenEXR.

Comment on lines 7 to 17
/// @file ImathNamespace.h
///
/// @brief The Imath library namespace
///
/// The purpose of this file is to make it possible to specify an
/// IMATH_INTERNAL_NAMESPACE as a preprocessor definition and have all of the
/// Imath symbols defined within that namespace rather than the standard
/// Imath namespace. Those symbols are made available to client code through
/// the IMATH_NAMESPACE in addition to the IMATH_INTERNAL_NAMESPACE.
///
/// To ensure source code compatibility, the IMATH_NAMESPACE defaults to Imath
Copy link
Contributor

Choose a reason for hiding this comment

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

I think these are fine for documentation in the header itself for human readers, but none of the @file stuff will currently show up in your readthedocs.

Another strategy might be to put these introductory materials right into the .rst itself.

Copy link
Member Author

Choose a reason for hiding this comment

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

Converted to non-doxygen style.

Copy link
Contributor

Choose a reason for hiding this comment

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

It was fine as it was, it doesn't hurt anything to be doxygen style. I just wanted to be sure you knew that those weren't ending up anywhere in the final docs.

Copy link
Contributor

@lgritz lgritz left a comment

Choose a reason for hiding this comment

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

I made a number of comments. They are not comprehensive -- I just noted one instance of I saw for each class of issues I noticed. They are more food for thought than hard requests for change.

I'm fine with merging this as-is and we can always improve it over time to turn it into beautiful docs.

@lgritz
Copy link
Contributor

lgritz commented Jan 29, 2021

Some things seem to have broken in the rearrangement and the CI tests are failing.

@lgritz
Copy link
Contributor

lgritz commented Jan 30, 2021

Thought:

The top level organization of these html docs is simply a recitation of the classes and functions, one chapter per class or function group. Very Doxygen like, very flat. It's ok as a html rendering of the header files for reference -- if you know which method of which class you are interested in, you can look it up. But it has no "affordances" for one to treat it as expository documentation, for example, it's nothing like a book from which one can learn about Imath in a logical fashion.

Maybe a better arrangement would be to actually organize chapters by major topic, each of which may end up including multiple classes and function groups, as well as introductory discussion of the topic.

I might be inclined to break the docs into the following top-level chapters:

  • Introduction and history of Imath (the "why" of this library and how to use it)
  • Half-precision floating point numbers
  • Basic linear algebra for computer graphics: Vectors and matrices
  • Colors and color operations
  • Math helper functions (including root finding, random numbers, interval math, etc.)
  • More spatial helpers (Box, Line, Plane, Frustum, quaternions, euler angles, etc.)

Breathe/sphinx ignores @file doxygen comments, so they're now straight
C++ comments intended for the reader of the header file. Where
appropriate, relevent details are covered in the class/function
doxygen comments.

Also restores some comments lost in the translation, and fixes some typos.

Signed-off-by: Cary Phillips <cary@ilm.com>
@cary-ilm
Copy link
Member Author

The CI breakage was from a "constexpr" that should have been IMATH_CONSTEXPR.

I like the suggestion for high level "book-style" comments, but can be a project for another day.

Signed-off-by: Cary Phillips <cary@ilm.com>
@cary-ilm
Copy link
Member Author

The SonarCloud analysis is failed with "You're not authorized to run analysis", does anyone know what's up?

Copy link
Contributor

@lgritz lgritz left a comment

Choose a reason for hiding this comment

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

LGTM

Fine merge now and take our time to mull over any further changes for later possible introduction.

@cary-ilm cary-ilm merged commit 162afe5 into AcademySoftwareFoundation:master Feb 1, 2021
@cary-ilm cary-ilm added v3.0.0-beta documentation Improvements or additions to documentation labels Mar 17, 2021
@cary-ilm cary-ilm deleted the doxygen branch May 7, 2021 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation v3.0.0-beta
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants