I'm writing benchmark for a pallet, in which I need to generate key pairs as input. However with --features runtime-benchmarking, I seems not able to use full-crypto and sp_core::Pair.
So the only way I found is to use RuntimeAppPublic::generate_pair, but it needs a keystore registered for the ext. But with benchmark! macro I wasn't able to do this.
So are there any suggestions? Either on generating keypairs without std or registering a keystore extension within the benchmark! framework.
Edit: I found something may be helpful in the doc.
/// You can construct benchmark by using the `impl_benchmark_test_suite` macro or
/// by manually implementing them like so:
///
/// ```ignore
/// #[test]
/// fn test_benchmarks() {
/// new_test_ext().execute_with(|| {
/// assert_ok!(Pallet::<Test>::test_benchmark_dummy());
/// ...
/// });
/// }
/// ```
From this doc, I think we can manipulate the test_ext easily for the test. But there are no information about the bench_xxx functions. As far as I can see in the cargo expand file, it maybe a bit different for benchmark.
It's about genesis config, closing.
Related
I'm looking at the official Diesel documentation on this page: https://docs.diesel.rs/diesel/expression_methods/trait.PgArrayExpressionMethods.html#example. The example uses a variable tags, but I cannot see where it is defined. How should I understand this code snippet?
let cool_posts = posts.select(id)
.filter(tags.contains(vec!["cool"]))
.load::<i32>(&conn)?;
assert_eq!(vec![1], cool_posts);
let amazing_posts = posts.select(id)
.filter(tags.contains(vec!["cool", "amazing"]))
.load::<i32>(&conn)?;
Where does the tags variable come from?
Examples in Rust docs can hide parts of the code using #. This is usually done to reduce noise of repeated boilerplate, like main functions and imports.
If you view the source for that trait, you can see the full code contains:
/// # table! {
/// # posts {
/// # id -> Integer,
/// # tags -> Array<VarChar>,
/// # }
/// # }
The lines starting with # are not rendered in the documentation, but are still compiled when you run the documentation tests.
Presumably, in the context of Diesel examples, this is common enough or perhaps considered "obvious" enough that the authors thought the example was clearer without it. This is probably a matter of opinion, which not everybody will agree with.
Does anyone know if the VLC project has a defined state machine for the libvlc_state_t states? The state machine states are exposed via libvlc and then again via bindings into other languages (for example, LibVLCSharp). The enum is documented here, but I can't find a description of transitions or other details.
Update
I'd like to see this get rolled into VLC docs at some point. While the state machine might seem obvious, I am encountering small oddities like the Buffering event getting called but the Media not seeming to pass through the Buffering state - it's still in the Playing state.
These little things add up and it would probably help improve developer experience to get them added. What I'm looking for as a solution is a typical state machine that includes at a minimum the states, the transitions, and notes about which events are actually fired on which transitions (and if they happen before or after the state actually changes). Anything around threading concerns (e.g. sync vs. async transitions) and allowable actions while in a given state are a bonus.
I did some work to capture the observed behavior. This is incomplete and imperfect, but perhaps it may help others as they build on top of libvlc/LibVLCSharp (I was on v3.5.1, VideoLAN.LibVLC.Windows v3.0.14). The dashed arrows pointing to the right are to show when certain events fire. Note that some of these behaviors are potentially specific to the type of media or the fact that reading is occurring through the MediaInput interface, so your mileage may vary.
A few notes:
Things did not seem to always work properly if you tried to e.g. seek while the media was Opening. For example, I saw .Time and .Position fall permanently out of sync. I strongly recommend waiting until after a Play() operation before doing much.
The Buffering state was not seen to be in use, but the Buffering event would fire at least the Opening and Playing states.
As others have noted, you can't simply call Play() once the media ends. You need to Stop() after EndReached fires, and - as with many of the callbacks - you need to make sure you handle this in a non-deadlocking way. It can and will silently deadlock. Even using Dispatcher may choose to run on the same thread, so you have to guarantee a separate thread. So far I've had good luck with e.g. ThreadPool.QueueUserWorkItem(_ => yourMediaPlayer.Stop()); You can then hook Stopped to trigger further behavior like Play().
I'm still not sure the exact behavior around ErrorEncountered and recovery to Play() again; it wasn't easy to trigger this behavior.
Ultimately this state machine allowed me to build one on top of it to handle behaviors like "make the file playable again when the end is reached".
Thanks #mfkl and many others for the hard work - with a bit of digging this has been a great library to build on!
media.State
Should give you what you want.
The libvlc_state_t C enum is simply defined as a C# enum in libvlcsharp, like so:
/// <summary>Note the order of libvlc_state_t enum must match exactly the order of</summary>
/// <remarks>
/// <para>mediacontrol_PlayerStatus,</para>
/// <para>input_state_e enums,</para>
/// <para>and VideoLAN.LibVLCSharp.State (at bindings/cil/src/media.cs).</para>
/// <para>Expected states by web plugins are:</para>
/// <para>IDLE/CLOSE=0, OPENING=1, PLAYING=3, PAUSED=4,</para>
/// <para>STOPPING=5, ENDED=6, ERROR=7</para>
/// </remarks>
public enum VLCState
{
/// <summary>
/// Nothing special happening
/// </summary>
NothingSpecial = 0,
/// <summary>
/// Opening media
/// </summary>
Opening = 1,
/// <summary>
/// Buffering media
/// </summary>
Buffering = 2,
/// <summary>
/// Playing media
/// </summary>
Playing = 3,
/// <summary>
/// Paused media
/// </summary>
Paused = 4,
/// <summary>
/// Stopped media
/// </summary>
Stopped = 5,
/// <summary>
/// Ended media
/// </summary>
Ended = 6,
/// <summary>
/// Error media
/// </summary>
Error = 7
}
You can also subscribe to the StateChanged event on the Media to get notified of changes in the State status.
A simple example:
/// ```
/// println!("hello");
/// ```
And what I see when I run cargo doc:
It would be useful to show the output. Well, obviously not in this example. 😊
This is currently not possible, see this issue calling for the support of cargo test's --nocapture flag for doctests.
I'm creating a procedural macro that auto-generates a library from some configuration file (it's a register layout, but that's not important for the question).
I would like the library to auto-generate the documentation accompanying the auto-library and include doc tests that should run with cargo test. Now, I've implemented most of this, but there is one issue I can't see a solution to.
Say we have a library called my_lib in which we invoke the macro to populate it:
use my_macro_lib::hello;
hello!();
which expands to something like:
/// `foo` will always return `true`
/// ```
/// use my_lib;
/// assert!(my_lib::foo());
/// ```
pub fn foo() -> bool {
true
}
This will run as expected - cargo doc will do the right thing and cargo test will run the doctests as expected.
The problem is that in this example, use my_lib is hard-coded into the my_macro_lib which is clearly undesirable.
How can I create a macro which infers the name of crate that is doing the calling?
I tried using a macro_rules! inside the procedural macro to expand $crate, but this breaks the hygiene rules.
You can obtain the name of the crate that is using your macro by reading the CARGO_PKG_NAME environment variable. Note that you have to read it via
std::env (at "runtime" of your macro) and not via env! (which would be when your proc macro crate is compiled).
#[proc_macro]
pub fn hello(input: TokenStream) -> TokenStream {
let crate_name = std::env::var("CARGO_PKG_NAME").unwrap();
let use_statement = format!("use {}::foo;", crate_name);
let output = quote! {
/// `foo` will always return `true`
/// ```
#[doc = #use_statement]
/// assert!(foo());
/// ```
pub fn foo() -> bool {
true
}
};
output.into()
}
There are a few complications here regarding interpolating things in doc comments. Interpolating like /// #an_ident does not work as doc comments are parsed in a special way. The only way we can do this is to create a string and using the #[doc = ...] syntax. It's a bit annoying because you have to create strings before the quote! invocation, but it works.
However, I don't think it is guaranteed that this works. Currently proc macros can access all of the environment (including the file system, network, ...). To my knowledge, proc macros aren't guaranteed this access and proc macros might be sandboxed in the future. So this solution is not perfect yet, but it works for now (and probably for quite some time still).
An alternative would be to just let the user pass the crate name to your macro:
hello!(my_lib);
If your macro is only invoked once per crate, this is probably the preferred solution. If your macro is invoked a lot, then repeating the crate name might be annoying.
How can I configure the "publisher" section in ccnet.config file in order to send email only to person who checked-in when the build fails?
Thanks,
John.
I don't think you can "out of the box".
You'll have to write your own publisher...and piggy back on "FailureUsers".
https://github.com/ccnet/CruiseControl.NET/blob/master/project/core/IIntegrationResult.cs
// Users who contributed modifications to a series of failing builds:
/// <summary>
/// Gets the failure users.
/// </summary>
/// <value></value>
/// <remarks></remarks>
ArrayList FailureUsers { get; } // This should really be a Set but sets are not available in .NET 1.1
Here is the tech-spec:
http://confluence.public.thoughtworks.org/display/CCNET/Custom+Builder+Plug-in
Here is an example of someone who wrote one....
http://krisselden.com/2007/01/29/adding-a-custom-cruisecontrolnet-publisher/