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

Add a new style of generated documentation #508

Open
wants to merge 18 commits into
base: develop
Choose a base branch
from

Conversation

joshessman-llnl
Copy link
Member

@joshessman-llnl joshessman-llnl commented Mar 29, 2021

Summary

  • This PR is a feature
  • It does the following:
    • Adds a new style of Sphinx documentation generation

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

  • Implement hashing or something similar to avoid collisions with hyperlinks

@joshessman-llnl joshessman-llnl added Inlet Documentation Issues related to documentation labels Mar 29, 2021
@joshessman-llnl joshessman-llnl changed the title WIP: Add a new style of generated documentation Add a new style of generated documentation Apr 19, 2021
if(isCollectionGroup(container.name()) &&
!sidreGroup->hasView(detail::STRUCT_COLLECTION_FLAG))
{
return;
Copy link
Member

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?

Copy link
Member Author

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);
Copy link
Member

Choose a reason for hiding this comment

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

👍

enum class Style
{
// FIXME: These names are not clear at all
Table, // Tables for the child Fields/Functions of each Container
Copy link
Member

@white238 white238 Apr 26, 2021

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?

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 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);

white238
white238 previously approved these changes Apr 27, 2021



List of boundary conditions
Copy link
Member

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.

Copy link
Member Author

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!

Copy link
Member

Choose a reason for hiding this comment

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

Duplication is still here.

Copy link
Member

@agcapps agcapps left a 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.

src/axom/inlet/SphinxWriter.hpp Show resolved Hide resolved
@kennyweiss
Copy link
Member

kennyweiss commented May 3, 2021

Quick question: Where do the indices come from in the "Table Mode" ?
E.g. "Table 2 Fields" and "Table 3 Fields" in the following:
image

Externally, it seems like an implementation detail that the user wouldn't understand or be able to reference in their input decks.
Or am I missing something?

EDIT: Or is this a sphinx-generated index, unrelated to inlet ? Since they're not referenced, perhaps our sphinx should disable the indices?

@joshessman-llnl
Copy link
Member Author

Quick question: Where do the indices come from in the "Table Mode" ?
E.g. "Table 2 Fields" and "Table 3 Fields" in the following:

Externally, it seems like an implementation detail that the user wouldn't understand or be able to reference in their input decks.
Or am I missing something?

EDIT: Or is this a sphinx-generated index, unrelated to inlet ? Since they're not referenced, perhaps our sphinx should disable the indices?

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:
Copy link
Member

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.

Copy link
Member Author

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?

@white238 white238 dismissed their stale review May 3, 2021 23:29

Comments need to be addressed. Don't want it merged by accident.

@white238
Copy link
Member

white238 commented May 3, 2021

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
Copy link
Member

@white238 white238 May 3, 2021

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.

Copy link
Member Author

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
---------


Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

Choose a reason for hiding this comment

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

... and here?

Copy link
Member

@kennyweiss kennyweiss left a 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 of geometry.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
Copy link
Member

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
=========================================
==================================
Copy link
Member

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
Copy link
Member

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;
Copy link
Member

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?

Copy link
Member Author

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:

axom/src/conf.py

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)?

Copy link
Member

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).

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've gone ahead and tried this out - see commit 8834021

Should this maybe be moved into a separate PR?

@joshessman-llnl
Copy link
Member Author

  • Maybe adding the subtable path as part of a table's header would help?
    E.g. "operators: subtable of geometry.shapes"
  • The "Flat" table layout seems a bit too spread out relative to the information.

The "flat" layout is just the current style generated by the SphinxWriter class - after some discussion with the Serac team a while back it was determined that it might still be useful, hence why I opted to leave it as an option. Of course, that doesn't mean it can't be improved, either as part of this PR or a separate one.

  • 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?

If I understand correctly, this is what the "nested" style option does.

  • Similarly, it would be nice to have a back reference to the parent table.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Issues related to documentation Inlet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inlet: Add dedicated Writer documentation page
4 participants