When writing Rust documentation tests, is it possible to externalize parts of the code to an external file to keep the example short?
# include!("src/fragment.rs") appears to work and does not show up in the output. I have no idea how this interferes with Cargo's dependency processing, though.
I don't think it is officially supported at this moment; there is a related Cargo issue and a tool that attempts to allow it until it is introduced in Cargo (I haven't used it, though).
Related
We have a commercially sold application that is presently written in Java and Python. We are currently looking at moving to Rust for performance and non-crashy reasons.
In our present Java/Python architecture, we have a feature that manages customisations that particular customers want. This involves placing Java jars/classes and python files under a specific folder designated for customisation for specific customers. In the application configuration, the Java classpath and the PYTHON_PATH have this folder precede the folders containing the normal, uncustomised application code. Because of this, any code in this special folder will override the normal, uncustomised behaviour of the application.
We would like to keep this feature in some form when moving to Rust. We certainly want to avoid distributing source code to our customers for the core app (mostly Java now) and have customers compile, which is what we would need to do if we used Rust's module feature.
Is there a way we can we implement this feature when we go to Rust?
Target OS's are a mix of Linux and Windows.
Sounds like you want some kind of plugin architecture, with a dynamic library (also written in Rust) that's loaded at runtime.
Unfortunately, Rust doesn't have a stable ABI yet, meaning that those librarise would have to be compiled with the exact same compiler that built the main application. One workaround is to expose a C ABI from the plugin side, and use C FFI to call it, if you can live with the unsafety and hassle that entails. There's also the abi_stable crate, which might be safer/simpler to use.
Scripting languages might be another avenue to explore. For example, Rhai is a language specifically developed for use in Rust applications, and interoperates as seamlessly as these things get. Of course, performance of the scripted parts will not be as great as native Rust code.
I don't think that it is possible without recompiling it or at least compiling the config.rs file that you intend to create for individual users.
Assuming that the end user does not have Rust installed on their system, a few alternatives might be:
Using .yaml files for loading configs (similar to how GitHub Actions work)
Allowing users to run custom programs (you can use tokio::process to run them in an async manner)
Using rhaiscript (I personally prefer this option)
Taken from the official language docs for the modules feature
you could set up your commercial project in such a way that the source code is threated as an external crate, and then load it into the main project with the path attribute.
A minimal example, already on the docs:
#[path = "thread_files"]
mod thread {
// Load the `local_data` module from `thread_files/tls.rs` relative to
// this source file's directory.
#[path = "tls.rs"]
mod local_data;
}
How can I only include a package used for benchmarking when I run cargo bench?
The documentation for targets suggests that this is possible but I can't get it to work.
https://doc.rust-lang.org/cargo/reference/cargo-targets.html
Benchmark dependencies don't get their own section in cargo.toml. You need to put them in the [dev-dependencies] along with test dependencies.
As pointed out by #Dogbert in the comments, there is a related issue:
https://github.com/rust-lang/cargo/issues/1596
There is also this useful suggestion to move the benchmarks/quickcheck into a separate repository and use the public interface.
#bluss bluss commented on 2 May 2020 For such cases like benchmarks,
for now I'd recommend using an additional non-published crate that you
keep in the same repository, that depends on your library and contains
the benchmarks. It will need to use the public APIs, of course, but
that's ok in most cases. As an example of this, ndarray has a
subdirectory for blas-tests that runs tests that depend on BLAS.
I'd like to use WebGL Extensions from within Rust code that is compiled to WebAssembly. The web_sys::WebGlRenderingContext has a method get_extension which returns a JsValue.
I expect there is a way to either use the dyn_into method to get an ANGLE_instanced_arrays interface, which according to this webidl may be included in web_sys somewhere, but I can't seem to get at it. If it's not possible to get to the ANGLE_instanced_arrays interface, is it possible to call known methods and properties using the JsValue directly?
I noticed that you also posted your question on the wasm-bindgen issues log where they provided some useful information. For other people who come across this I thought I would share the link.
https://github.com/rustwasm/wasm-bindgen/issues/1257
As per this issue: wasm-bindgen issue 893 - Figure out how to support interfaces with NoInterfaceObject attribute The WebGL extensions should be available in the next release.
I'd like to use #Grape in my groovy program but my program consists of several files. The examples on the Groovy Grape page all seem to assume that your script will consist of one file. How can I do this? Should I just add it to one of the files and expect that the imports will work from the others? If so, then is it common to place all the #Grape calls in one file with no other code? Do I need to add the Grape call to all files that will import the package? Do I need to download the JAR and create a Gradle file, which I was getting away without at this point?
the grape engine and the #grab annotation were created as part of core groovy with single file scripts in mind, to allow a chunk of text to easily become a fully functional program.
for larger applications, gradle is an awesome build tool with lots of useful features.
but yes, you can manage all the application dependencies just with grape.
whether you annotate every file or a single one does not matter, just make sure the #grab annotated file is read before you try to use the external class.
annotating the main class is probably better as you will easily lose track of library versions if you have the annotations scattered.
and yes, you should consider gradle for any application with more than a dozen files or anything you might want to reuse elsewhere as a library.
In my opinion, it depends how your program is to be run...
If your program is to be run as a collection of standalone scripts, then I'd probably stick the #Grab required for each script at the top of each of them.
If your program is more of a standard style program with a single point of entry, then I'd go for using a build tool like Gradle (as you say), as you get a lot of easy wins by using it.
Firstly, it makes it easy to define your dependencies (and build a single large jar containing all of them)
Secondly, Gradle makes it really easy to start writing tests, include code coverage plugins, or useful tools like codenarc to suggest possible fixes or improvements to your code. These all become invaluable not only for improving your code (or knowing your code works), but also when refactoring your code, you know you've not broken anything that used to work.
My understanding is that when make executes, it generates a DAG internally to represent all the dependencies in the project. Is there a way to get at that DAG and graph it, say using something like graphviz?
I'm using gnu make on Ubuntu 8.04.
EDIT
I just ran across these tools called mamdag and mamdot. They're supposed to work with both nmake and gnu make, but I can't seem to find the options to get gnu make to spit out the mam file.
It can be downloaded here - these packages:
INIT
ast-base
ast-gpl
Just found this article by Glenn Fowler at AT&T describing the MAM language and the mamdot tool.
It seems like you have to patch gnu make for this to work, although I'm not 100% certain yet.
Maybe there's another way?
You should try using Makefile::GraphViz's gvmake utility to create the graphs you want
For the code side of things, doxygen will produce dependency diagrams between source and header files, if that is what you are interested in, without the use of make.