Comments (4)
My personal opinion is that the README
might contain one or two motivating examples, but further examples should rather reside in a dedicated location. The examples
folder is a pretty solid place for this, I believe. Although one can also make the case for including examples in doc tests. In fact, you could do both: I think you could do (just sketching out)
#[doc = include_str!("../examples/hex.rs")]
mod examples {}
whether or not this is a good idea, I don't know, but thought I'd throw it out there.
from vtkio.
I second that we should keep the readme concise, with a few select (definitely non-exhaustive) examples for how to use this lib (e.g. import/export examples, and how to build meshes). We can simply link to the examples directory (or a readme there that will summarize the what examples we have).
I am not opposed to including the examples in docs. This way folks can get most of the usage info without leaving docs.rs, and most importantly without digging through the code. However I think I would prefer a dedicated module solely for documenting these examples to which we can link from lib.rs.
I suspect many of the cell types can be grouped together into a single example.
from vtkio.
I am not opposed to including the examples in docs. This way folks can get most of the usage info without leaving docs.rs, and most importantly without digging through the code. However I think I would prefer a dedicated module solely for documenting these examples to which we can link from lib.rs.
Coud you elaborate this more in detail? You are not talking about rustdoc, no or yes?
My personal opinion is that the
README
might contain one or two motivating examples, but further examples should rather reside in a dedicated location. Theexamples
folder is a pretty solid place for this, I believe. Although one can also make the case for including examples in doc tests. In fact, you could do both: I think you could do (just sketching out)#[doc = include_str!("../examples/hex.rs")] mod examples {}whether or not this is a good idea, I don't know, but thought I'd throw it out there.
Have a look at #19 . So you mean in vertex.rs should be addional a doctest example?
from vtkio.
Coud you elaborate this more in detail? You are not talking about rustdoc, no or yes?
Yes exactly! I'm referring to rustdoc, which can be generated with cargo doc
, which is served by docs.rs for free for all published crates on crates.io.
Have a look at #19 . So you mean in vertex.rs should be addional a doctest example?
I'd love to have @Andlon weigh in on this, but my preference is to keep the "examples" directory for complete use-case type of examples. For instance an example of how one might use vtkio to do something specific like load a vtk file, change it or render it with a third party library, or simply create a vtk file of a complex mesh for some purpose. I expect the examples for building all the different kinds of cell types to be short, so I would just put in an examples module like you did, but just use //!
in examples/mod.rs
and add a short description for each cell type.
Adding the example code as
#[doc = include_str!("../examples/hex.rs")]
mod examples {}
will not be formatted correctly as code and will be missing the ability to add formatted descriptions around the examples, so I would suggest to avoid that method altogether.
These are just suggestions, I would be happy to accept a PR with examples in whatever format you think is most appropriate so long as they are clear and concise.
from vtkio.
Related Issues (20)
- Improve version handling
- Update references to vtk file format docs
- VTKIO Real-World Video Tutorial
- Extracting Data HOT 2
- creating a Circle approximated by a BezierCurve HOT 7
- Clarify the connection between xml VTK file extensions and VTKFile tag type
- Unable to import various VTK and VTU file types HOT 10
- The Paraview import issue for exported compressed VTU and VTI files HOT 6
- ParaView cannot read XML vtp files whose `connectivity` and `offsets` are `UInt64`. HOT 2
- Future compatibility for nom version 3 HOT 2
- Error importing VTU with `<AppendedData encoding="raw">` block HOT 3
- Support for CRLF line endings in legacy VTK files
- unresolved imports `vtkio::export_ascii`, `vtkio::import` HOT 1
- Request an example of constructing a VTK object containing point/cell data in Legacy style HOT 2
- Exported data for point cloud is not readable by Paraview 5.11 HOT 3
- Add configuration options for exporting files
- Improve documentation for creating point clouds
- Too many complex enum types, sometimes unnecessarily HOT 2
- `0.7.0` is not available on crates.io
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vtkio.