-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add a new style of generated documentation #508
base: develop
Are you sure you want to change the base?
Conversation
…ink trivial subcontainers
if(isCollectionGroup(container.name()) && | ||
!sidreGroup->hasView(detail::STRUCT_COLLECTION_FLAG)) | ||
{ | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the user end up knowing this is a collection of primitives from the outputted documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not extremely clear (see https://axom.readthedocs.io/en/feature-essman-nested_docs/axom/inlet/docs/sphinx/mfem_coefficient_nested_documentation.html#attrs) but I can clean this up in a follow-up once we decide what that should look like (see also #482 (review))
functions.end(), | ||
[this, containerCount](const std::vector<std::string>& functionData) { | ||
// Insert a hyperlink target for the name | ||
m_oss << fmt::format(".. _{0}{1}:\n\n", functionData[0], containerCount); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
src/axom/inlet/SphinxWriter.hpp
Outdated
enum class Style | ||
{ | ||
// FIXME: These names are not clear at all | ||
Table, // Tables for the child Fields/Functions of each Container |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think nested is clear (at least how I see it) maybe focus on figuring out a better name for the overloaded "Table". Singular or Individuals? or possibly just non-nested.
Do you see anything that would be fall under nested/non-nested table? Are we jumping to complication before we need to. Would a simple boolean work for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's within the realm of possibility that we'd want a third style of Sphinx documentation - the other consideration is readability in the constructor call:
SphinxWriter("docs.rst", "My Docs", true);
// vs...
SphinxWriter("docs.rst", "My Docs", SphinxWriter::Style::Nested);
|
||
|
||
|
||
List of boundary conditions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is doubled for some reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, ended up just being a copy-paste error!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplication is still here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, from what I can see. Consider renaming the Style names, but that's only a style recommendation.
Looking at the generated RST output (https://github.com/LLNL/axom/blame/4eb53eea9c7ccf85190ea8287009ac2dc5c8d164/src/axom/inlet/docs/sphinx/example1_table_documentation.rst#L34-L50), it looks like Sphinx is adding these in. I can look into disabling them (or if there exists an option for that). |
|
||
|
||
-------------------- | ||
Collection contents: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is helpful from a user stand-point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to express that the following section contains the schema for individual elements of the collection. Would it be more helpful to make this more verbose (e.g., "Each element of the collection can contain the following:") or to remove it entirely?
Comments need to be addressed. Don't want it merged by accident.
It's hard to tell the structure from the nested version. We should talk about ways to improve this. |
|
||
**z** | ||
|
||
z-axis point to slice on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This additional section doesn't provide value over what is in the table above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to Inlet's current architecture (see #508 (comment)), there isn't any additional information available for this element. One solution would be to add logic to avoid creating a separate subsection when only the description is available - does that sound reasonable?
translate | ||
--------- | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there something missing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because Inlet doesn't have a separate phase for defining the schema and reading from the input file, collections (arrays/dicts) are implemented by adding schema components (scalars, etc) to each element. The docs generation logic just uses the schema from the first element, so unfortunately the documentation output will depend on what the input file looks like. In this case, the first element of this collection didn't have a "translate" member, so the information (type, etc) on this member will be incomplete.
Collection contents: | ||
-------------------- | ||
|
||
Translation vector |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... and here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @joshessman-llnl .
I think there are some nice ideas here, but perhaps the layout of the nested and flat tables should be improved a bit before we provide these to users?
Some specifics:
- I'm finding it difficult to understand the nested structure of the tables in both the "nested" and "flat" views.
- Maybe adding the subtable path as part of a table's header would help?
E.g. "operators
: subtable ofgeometry.shapes
" - The "Flat" table layout seems a bit too spread out relative to the information.
- Would it be possible to have a table for each container, but for the nested containers to have links to their subtable in the RST file?
- Similarly, it would be nice to have a back reference to the parent table.
Using the same ``documentation_generation.cpp`` example, the automatically generated schema can be used to assist | ||
with input file writing: | ||
|
||
.. image:: json_schema_example.gif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome!
========================================= | ||
Nested Structs Output: Input file Options | ||
========================================= | ||
================================== |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these rst
files have a comment that they were auto-generated by inlet?
|
||
|
||
|
||
List of shape operations to apply |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
List of shape operations to apply
List of shape operations to apply
Duplicated.
void SphinxWriter::writeNestedTables() | ||
{ | ||
// Used to avoid duplicate hyperlinks | ||
int containerCount = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This references a comment I made on the Conversation page)
It looks like the table indices are inlet
-generated.
My concern is that these indices are meaningful to the system (e.g. to generate unique links), but not to the user.
Is there a way to use these numbers but not display them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like Axom is enabling this explicitly:
Lines 91 to 93 in 858899f
# -- Option for numbering figures/tables/etc.----------------------------------- | |
# Note: numfig requires Sphinx (1.3+) | |
numfig = True |
See https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-numfig for a description of the option - should we just turn this off then (the default)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @joshessman-llnl -- I think so.
We might need to reword a few things in the mint docs, which, I think might be referencing these numbers.
(which seems a bit formal for sphinx docs to me).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've gone ahead and tried this out - see commit 8834021
Should this maybe be moved into a separate PR?
The "flat" layout is just the current style generated by the
If I understand correctly, this is what the "nested" style option does.
I think it would definitely be possible to add the parent path/link to the parent, were you thinking that this would be useful for both the new "nested" style and the existing "flat" style? |
Summary
Depends on #450 and should not be merged until that PR is merged.
See https://axom.readthedocs.io/en/feature-essman-nested_docs/axom/inlet/docs/sphinx/nested_structs_nested_documentation.html for an example, compared to the current style: https://axom.readthedocs.io/en/feature-essman-nested_docs/axom/inlet/docs/sphinx/nested_structs_table_documentation.html
This PR also fixes #500 by adding a Writer documentation page: https://axom.readthedocs.io/en/feature-essman-nested_docs/axom/inlet/docs/sphinx/writers.html