-
Notifications
You must be signed in to change notification settings - Fork 12
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 documentation for dynamical.ops
and dynamical.handlers
#439
Conversation
docs/source/type_aliases.rst
Outdated
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.
Not sure if we actually want this, but this was the cleanest way I could find (after looking only a little bit) to document these type aliases. Happy to remove if not desired. Am currently linking to these from the simulate
docs.
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.
When I build the docs I get this warning.
checking consistency... /Users/sam-basis/Desktop/Research/chirho/docs/source/type_aliases.rst: WARNING: document isn't included in any toctree
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.
Ya I was thinking that we don't want it in the doctree, and just to be linked? Not sure if there's a way to supress the warning...or if we should just include it in the doctree.
@azane , could you address the lint failure? Thanks! |
@SamWitty done |
@azane have you built docs locally and confirmed that everything renders correctly? |
One thing I notice in the above rendering is that the |
@azane , I'll look into a fix for this. If you can come up with one as well feel free. |
Yes — sorry should have mentioned that! |
@SamWitty ya, so this happens in the actual signature but I haven't been able to figure out how to "unpack" the alias in the docstring itself. If you click the hyperlinks there it takes you to the type alias page that shows the underlying type. My primary question here is whether we just want to take those non-unpacked type aliases out of the docstring. I think I am leaning toward that at the moment...
|
done |
dynamical.ops
and dynamical.handlers
@azane and I figured out a workaround, but will plan on submitting a follow-up |
…sal_pyro into az-dynsys-docs
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 great! We can nitpick about the verbiage in future PRs. Also, we'll make a global change to how type aliases are used in docs for all modules as a separate PR, as that applied beyond just this block of documentation.
Partly addresses #337 by adding documentation for
simulate
,LogTrajectory
StaticBatchObservation
and all user-facing interruptions.