This question already has an answer here:
Why is a trait not implemented for a type that clearly has it implemented?
(1 answer)
Closed 4 years ago.
I am trying to generate a keypair using secp256k1 library.
In the official documentation I found this code:
use rand::OsRng;
use secp256k1::{Secp256k1, Message};
let secp = Secp256k1::new();
let mut rng = OsRng::new().expect("OsRng");
let (secret_key, public_key) = secp.generate_keypair(&mut rng);
And I put this in my Cargo.toml:
[dependencies]
rand = "0.6.1"
[dependencies.secp256k1]
features = ["rand"]
version = "0.12.0"
However, I get this compile error:
| secp.generate_keypair(&mut rng);
| ^^^^^^^^^^^^^^^^ the trait `secp256k1::rand::Rng` is not implemented for
`std::result::Result<rand::rngs::OsRng, rand::Error>`
I am very new to Rust and I am trying to understand it but I find it extremely difficult. Please explain what is my mistake. Thanks!
This appears to be a crate version mismatch. The latest version of the rand crate is 0.6.1, but secp256k1 0.12.0 depends on a much older version - 0.4.3.
A quick fix is to use an older version of rand:
[dependencies]
rand = "0.4.3"
And consider asking the authors of secp256k1 to update their dependencies.
The way that I found this was to search in the Cargo.lock file, which contains all of the actual versions of dependencies used by your application.
Related
My code (reduced to just a few lines for this demo) looks like this:
AgentAssignment = List[int]
def assignment2str(assignment: AgentAssignment):
pass
The produced html documentation has List[int] as the type hint. This seems to be a resolved issue (#6518), but I am still running into it in 2022 with Sphinx version 5.1.1 (and Python 3.8.2). What am I missing?
I am not sure if there is Sphinx support for this yet, but you need to use explicit PEP 613 TypeAlias introduced in Python 3.10. Because otherwise the type resolver cannot differentiate between a normal variable assignment and a type alias. This is a generic Python solution for the type alias problem beyond the scope of Sphinx.
AgentAssignment: TypeAlias = List[int]
Ps. I am having the same issue with Sphinx
So, one needs to add at the beginning of the file (yes, before all other imports):
from __future__ import annotations
Then in conf.py:
autodoc_type_aliases = {'AgentAssignment': 'AgentAssignment'}
Not that this identity-transformation dictionary makes any sense to me, but it did the trick...
I also had this issue and was very confused why the accepted answer here stackoverflow.com/a/73273330/1822018, which mentions adding your type aliases to the autodoc_type_aliases dictionary as explained in the documentation here https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_type_aliases was not working for me. I solved my problem and I am posting it here for the benefit of others.
In my case, I also had installed the Python package sphinx-autodocs-typehints which extends/hijacks/overrides certain Sphinx functionality, in particular it appears to supplant the functionality of the autodoc_type_aliases dictionary in the given PR. To anyone trying to debug this issue I would suggest removing 'sphinx_autodoc_typehints' from the extensions list in your Sphinx conf.py file.
I'm using an extern crate in my Substrate 1.0 runtime module (based on node-template) which gives a compile error of
duplicate lang item in crate 'std' (which 'myexternalcrate' depends on): 'panic_impl'.
= note: first defined in crate `sr_io` (which `node_template_runtime` depends on).
If I understand the message correctly then I think this might be a common problem if developers want to include external crates that rely on std features which already implemented in sr-io, but I'm not sure if that is correct.
I have seen this issue here, which appears to have been fixed in sr-io but that does not appear to be the cause here.
Is their another approach to resolve this?
EDIT: Adding in changes to Cargo.toml
We are attempting to pull in crate called nacl
[dependencies]
nacl = {version = "0.3.0", default-features = false}
Added in lib.rs
extern crate nacl;
in the runtime module
use nacl::public_box::*;
The crate you are trying to use (rust-nacl) does not support no_std, and thus cannot be used within the Substrate runtime environment.
The options are:
Find another crate which does support no_std and has similar functionality: https://crates.io/keywords/no_std
Update/Write a crate to support no_std (which may not be that bad depending on the crate).
To clarify Shawn Tabrizi's answer above...
To use another crate that supports no_std:
imported_crate = { git = "...", default-features = false, branch = "..." }
OR to write a crate to support no_std :
#![cfg_attr(not(feature = "std"), no_std)]
more about no_std: https://substrate.stackexchange.com/questions/1307/how-to-resolve-duplicate-lang-item-error
I would like to define a function which should allow me to return an iterator over a range of struct instances.
I've tried the same functionality for standard types such as usize (see simplified code sample) and this works (although it is a little awkward). I can't use a standard type in the scenario that I have in mind, so that's not helpful to a solution, but it's helped me understand there is some kind of problem here.
#[derive(Debug)]
struct MyThing();
fn main() {
let good = 0usize..=10usize;
// ALSO WORKS for thing in *good.start()..=*good.end() {
for thing in 0usize..=10usize {
dbg!(thing);
}
dbg!(good);
let bad = MyThing()..=MyThing();
for thing in *bad.start()..=*bad.end() {
dbg!(thing);
}
dbg!(bad);
}
$ cargo --version
cargo 1.35.0 (6f3e9c367 2019-04-04)
$ cargo build
Compiling huh v0.1.0 (huh)
error[E0277]: the trait bound `MyThing: std::iter::Step` is not satisfied
--> src/main.rs:13:18
|
13 | for thing in *bad.start()..=*bad.end() {
| ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::iter::Step` is not implemented for `MyThing`
|
= note: required because of the requirements on the impl of `std::iter::Iterator` for `std::ops::RangeInclusive<MyThing>`
I don't expect the stable compiler to tell me that I have a missing unstable trait. I might have some other kind of issue here, which I don't understand, but the stable compiler is telling me that my problem is that I haven't implemented an unstable trait. I definitely can't fix my code like that (without switching to unstable).
I guess what I'm trying to understand is whether or not it's possible to define a range based on a user defined type which can then be iterated over.
Can anyone explain what is going on and suggest ways I can address my problem?
= note: required because of the requirements on the impl of `std::iter::Iterator` for `std::ops::RangeInclusive<MyThing>`
The Step trait is not yet stabilised. However, as this error note suggests, it is still used internally; the Iterator implementation of Range* types relies on the Step being implemented.
The result of this is that you cannot (yet) implement Iterator for ranges over custom types, until Step (or some replacement API) is stabilised.
Note that "unstable" in Rust does not mean it is buggy or could break in any way. It just means that there is still a possibility that the API could change in the future and break backwards-compatibility. The Rust compiler can make use of such APIs for syntax desugaring, because it can just change the desugaring later in the same release as the API changing.
To address the problem, I would suggest iterating over something else, that can be trivially converted into your type. Your code is perhaps a little too simplified to offer something realistic for your actual use case, but something along these lines:
impl From<usize> for Thing {
fn from(index: usize) -> Thing {
Thing()
}
}
for i in 0..=10 {
let thing = Thing::from(i);
dbg!(thing);
}
This should not result in any performance overhead.
It's not possible for you to implement that trait on a stable compiler (as of 1.36.0) at the moment.
This "pattern" isn't uncommon in the Rust world, e.g. see the Pattern trait, which is used in str::find method, so you can use either Strings, chars or a closure to search for something.
Unstable means in this context that the actual signature of the trait may change and therefore it is not stabilized. If you use the unstable (aka nightly) compiler you opt-in that your code may break because the signature of a trait, function changes.
The documentation says that it should be supported.
It seems that its not implemented in the gen.go file:
case types.Uint8: // types.Byte
return "uint8_t"
// TODO(crawshaw): case types.Uint, types.Uint16, types.Uint32, types.Uint64:
I read that i need to patch go mobile to support
But after changing the file to support Uint64, (go/src/golang.org/x/mobile/bind/gen.go)
And re init go mobile: gomobile init
The same error still appears, am i missing something obvious here?
I think the issue here is that Java does not have unsigned. Therefore interfaces to Java cannot have uint64 (and uint32 IIRC) file types as either global variables, function return values or function parameters.
You can use uint64 within Go mobile.
Two solutions based on the above:
Limit the exposure of illegal types to Java to a minimum
Convert uint64 to int64 in Go and convert from long to BigInteger in Java.
I solved this by patching Go mobile, inspired by this very StackOverflow post! I use "patch" very loosely, I don't encourage anyone to use this code as it is very purpose-specific.
I simply short-circuited the default case to return uint64 - you can see exactly what I did here: https://github.com/Sidetalker/mobile/commit/01eb11be69a781e71c7f00df6fc17b35f828f7a2
I needed to make a handful of other find/replace changes you can see on that branch to get it building properly, and I also had to fix what I'm pretty sure is a Go mobile bug with the byte type. All of this can be see on the branch.
Also, critically, I had to fully go get this project - making my changes and running gomobile init was not sufficient.
Don't use this code. Do mark this answered.
I would like to understand how jdk1.8 code is, as compared to code of jdk1.6
Can anyone provide an example, or a link??
Thanks
I want to see a comparison between code written in java6 and cod written in java8,
to understand the features of java8 and how it simplifies the code
I just need an example of a program written in java6 , against a program written in java8
The below link will help you understand how Java8 feature 'Lambda Expression' simplifies the code.
Java8 Lambda Expression - The What and Why
There are many features available in Java 8 and code enhancement that was not available in java 6.
A useful compiler feature that is added in Java 7 is the 'diamond operator'. E.g, instead of typing
ArrayList<Integer> arrInt = new ArrayList<Integer>();
You could just type
ArrayList<Integer> arrInt = new ArrayList<>();
In Java 8 many features are available. For further details you may visit mentioned links
https://www.javacodegeeks.com/2014/03/8-new-features-for-java-8.html
http://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html