-
-
Notifications
You must be signed in to change notification settings - Fork 94
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
No std upstream working #90
Conversation
Hey @yukibtc. Just a polite ping, looking for feedback :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank for working on this!
I marked some changes to do for now.
When it will be ready, can you squash commits and add CI for no_std
?
Cargo.toml
Outdated
@@ -10,8 +10,9 @@ members = [ | |||
"crates/nostr-sdk", | |||
"crates/nostr-sdk-net", | |||
"crates/nostr-sdk-sqlite", | |||
"crates/ensure_no_std", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This crate is just for testing no_std
, right?
If yes, can you move that to examples?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely, yes, this is just a simple test crate for no_std
, will move it 👍
crates/nostr/src/prelude.rs
Outdated
pub use bech32::*; | ||
pub use bech32; | ||
#[cfg(feature = "nip06")] | ||
pub use bip39::*; | ||
#[cfg(feature = "nip06")] | ||
pub use bitcoin::*; | ||
pub use bitcoin_hashes::*; | ||
pub use secp256k1::*; | ||
pub use serde_json::*; | ||
pub use bip39; | ||
pub use secp256k1; | ||
pub use url::*; | ||
|
||
// Internal modules | ||
pub use crate::event::builder::*; | ||
pub use crate::event::id::*; | ||
pub use crate::event::kind::*; | ||
pub use crate::event::tag::*; | ||
pub use crate::event::unsigned::*; | ||
pub use crate::event::*; | ||
pub use crate::key::*; | ||
pub use crate::message::*; | ||
pub use crate::types::*; | ||
pub use crate::{Result, SECP256K1}; | ||
pub use crate::event; | ||
pub use crate::event::builder; | ||
pub use crate::event::id; | ||
pub use crate::event::kind; | ||
pub use crate::event::tag; | ||
pub use crate::event::unsigned; | ||
pub use crate::key; | ||
pub use crate::message; | ||
pub use crate::types; | ||
pub use crate::Result; | ||
|
||
#[cfg(feature = "std")] | ||
pub use crate::SECP256K1; | ||
|
||
// NIPs | ||
#[cfg(feature = "nip04")] | ||
pub use crate::nips::nip04::*; | ||
pub use crate::nips::nip04; | ||
#[cfg(feature = "nip05")] | ||
pub use crate::nips::nip05::*; | ||
pub use crate::nips::nip05; | ||
#[cfg(feature = "nip06")] | ||
pub use crate::nips::nip06::*; | ||
pub use crate::nips::nip06; | ||
#[cfg(feature = "nip11")] | ||
pub use crate::nips::nip11::*; | ||
pub use crate::nips::nip13::*; | ||
pub use crate::nips::nip11; | ||
pub use crate::nips::nip13; | ||
#[cfg(feature = "nip19")] | ||
pub use crate::nips::nip19::*; | ||
pub use crate::nips::nip26::*; | ||
pub use crate::nips::nip19; | ||
pub use crate::nips::nip26; | ||
#[cfg(feature = "nip46")] | ||
pub use crate::nips::nip46::*; | ||
pub use crate::nips::nip65::*; | ||
pub use crate::nips::nip46; | ||
pub use crate::nips::nip65; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is possible to leave the ::*
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am honestly not sure, because it gives me a warning:
--> nostr/crates/nostr/src/prelude.rs:14:9
|
14 | pub use bitcoin_hashes::*;
| ^^^^^^^^^^^^^^^^^ the name `error` in the type namespace is first re-exported here
15 | pub use secp256k1::*;
16 | pub use serde_json::*;
| ------------- but the name `error` in the type namespace is also re-exported here
|
= note: `#[warn(ambiguous_glob_reexports)]` on by default
I think it is most likely because an Error
named enum is declared in each module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, add #![allow(ambiguous_glob_reexports)]
in the prelude module.
crates/nostr/src/nips/nip19.rs
Outdated
use alloc::{ | ||
string::{self, String, ToString}, | ||
vec, | ||
vec::Vec, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for nitpicking... can you rewrite this as:
use alloc::string::{self, String, ToString};
use alloc::vec::{self, Vec};
Also in other parts of code
crates/nostr/src/event/builder.rs
Outdated
#[error(transparent)] | ||
Json(#[from] serde_json::Error), | ||
#[error("Serde json Error: {0}")] | ||
Json(serde_json::Error), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not very expert about no_std
, thiserror not support the #[from]
in no_std
env?
If not support it, I think we can remove the thiserror
deps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the problem is the following:
thiserror
crate assumes that the enum/struct implements the std::error::Error
trait, which is not available in no_std
. However the thiserror-core
crate switched to the core::error::Error
trait, which is available on nightly
.
If you are not going to use the thiserror
heavily, then I would say removing it would be a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove thiserror
dep.
Maybe is better to do that in another PR.
If you don't have enough time, I can do it in the next days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would appreciate it if you did that in another PR, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merged #102
crates/nostr/Cargo.toml
Outdated
rand_core = { version = "0.6", features = [ | ||
"alloc", | ||
"getrandom", | ||
], optional = true, default-features = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is possible to keep only the rand
dep?
Thanks for the review, will address this soon! |
2dc247e
to
ee3c989
Compare
This reverts commit 77ef1c8.
ee3c989
to
b389fdb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the changes :)
Since two deps (bech32
and url_no_std
) aren't released to crates.io
yet, I prefer to wait to merge this to the master
branch.
The code looks good to me, but I want to make some cleanups.
So, instead of approve and merge this PR, is okay for you if I move the code/commits to a new branch (no_std
branch) in this repo and close this PR, so I can do the cleanup and merge by myself when the previous mentioned crates are published?
And, do you plan to open a PR to the url
repo to add no_std
support? (I saw that the url_no_std
crate is your url
fork)
Can you leave me your nostr pubkey? So when I'll release the new version with |
Understandable, hopefully they get merged soon. The rust_url crate has an open PR, I just used forked that PR to have a stable reference :).
Absolutely, I wanted to do it myself, but can not find the time, much thanks for it in advance! |
Thanks, much appreciated here is my nostr public key: |
Add
no_std
support with feature flagalloc
.Description
This PR adds
no_std
support to thenostr
crate.Notes to the reviewers
I will open it as a draft PR and I ask you @yukibtc to have a look at it for a first round of feedback :).
The CI will need some changes as well, but I wanted to open the PR first, hope you don't mind.
Changelog notice
Checklists
All Submissions:
make precommit
before committing