-
Notifications
You must be signed in to change notification settings - Fork 0
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
Documentation location #19
Comments
I think a general purpose manual/tutorial is very usefull. Lantz is a rich system, where many things are happening "automagically". Many of these things are not easy to find out from only reading the docstrings. I would say that the doc of the driver repro should only contain "apparatus"-driver specific documentation. All the possible features and standard practices around drivers should be documented in core (maybe with references to specific drivers for examples of the specific feature). |
I agree with vascotenner. The original Lantz docs did a decent job of this. Showing off the features of the system in a few page tutorial was extremely useful to get going. However, I do think it's important to show the "right" way to write a driver. IMO it's not useful to say go look at X driver and do something similar. People will look at the driver, make assumptions to what is actually going on, and at the end of the day there will lots of user drivers that may not live up to expectations because the dev didn't really understand how to implement the hardware features effectively. If I were writing a labpy driver (which I will be doing) I'd want to see the following:
|
While starting to write some docs for lantz_core I realized, that save for the very specific documentation concerning the internals of the system, it was not really making sense to document a number of things in lantz_core as basically using it alone without the drivers make no sense.
Specifically accessing a driver, instantiating it and using it belongs in lantz_drivers but defining the unit registry, setting global parameters (such UnitRegistry, ResourceManagers for the visa backend, etc) are in the core.
Should we have a generic purpose manual (installation, basic usage, configuration, writing drivers (as in this both drivers and core are interleaved), etc) and then cross-references to each package doc for the technical points (understanding Feature/channel/subsystem inner working) ?
The text was updated successfully, but these errors were encountered: