RunAwayFrog 6 months ago • 100%
Regarding Cargo.lock
, the recommendation always was to include it in version control for application/binary crates, but not library ones. But tendencies changed over time to include it even for libraries. If a rust-toolchain
file is tracked by version control, and is pinned to a specific stable release, then Cargo.lock
should definitely be tracked too [1][2].
It's strictly more information tracked, so there is no logical reason not to include it. There was this concern about people not being aware of --locked
not being the default behaviour of cargo install
, giving a false sense of security/reliability/reproducibility. But "false sense" is never a good technical argument in my book.
Anyway, your crate is an application/binary one. And if you were to not change the "*"
dependency version requirement, then it is almost guaranteed that building your crate will break in the future without tracking Cargo.lock
;)
RunAwayFrog 6 months ago • 100%
- Don't use
"*"
dep version requirements. - Add
Cargo.lock
to version control. - Why read to string if you're going to base64-encode and use
Vec<u8>
later anyway?
RunAwayFrog 10 months ago • 100%
Here is an originally random list (using cargo tree --prefix=depth
) with some very loose logical grouping. Wide-scoped and well-known crates removed (some remaining are probably still known by most).
mime data-encoding percent-encoding textwrap unescape unicode-width scraper
arrayvec bimap bstr enum-iterator os_str_bytes pretty_assertions paste
clap_complete console indicatif shlex
lz4_flex mpeg2ts roxmltree speedy
aes base64 hex cbc sha1 sha2 rsa
reverse_geocoder trust-dns-resolver
signal-hook signal-hook-tokio
blocking
fs2
semver
snmalloc-rs
RunAwayFrog 10 months ago • 100%
My quick notes which are tailored to beginners:
Use Option::ok_or_else()
and Result::map_err()
instead of let .. else
.
let .. else
didn't always exist. And you might find that some old timers are slightly triggered by it.- Functional style is generally preferred, as long as it doesn't effectively become a code obfuscater, like over-using
Option
s as iterators (yesOption
s are iterators). - Familiarize yourself with the
?
operator and theTry
trait
Type inference and generic params
let headers: HashMap = header_pairs
.iter()
.map(|line| line.split_once(":").unwrap())
.map(|(k, v)| (k.trim().to_string(), v.trim().to_string()))
.collect();
(Borken sanitization will probably butcher this code, good thing the problem will be gone in Lemmy 0.19)
Three tips here:
- You don't need to annotate the type here because it can be inferred since
headers
will be returned as a struct field, the type of which is already known. - In this pattern, you should know that you can provide the collected type as a generic param to
collect()
itself. That may prove useful in other scenarios. - You should know that you can collect to a
Result
/Option
if the iterator items areResult
s/Option
s. So that.unwrap()
is not an ergonomic necessity 😉
Minor point
- Use
.into()
or.to_owned()
for&str => String
conversions.- Again, some pre-specialization old timers may get slightly triggered by it.
make good use of the crate echo system
- It's important to make good use of the crate echo system, and talking to people is important in doing that correctly and efficiently.
- This post is a good start.
- More specifically, the
http
crate is the compatibility layer used HTTP rust implementations. Check it out and maybe incorporate it into your experimental/educational code.
Alright, I will stop myself here.
RunAwayFrog 10 months ago • 100%
RunAwayFrog 11 months ago • 100%
RunAwayFrog 11 months ago • 100%
Broken input sanitization probably.
Issue will thankfully no longer exist in the next lemmy release.
RunAwayFrog 1 year ago • 100%
lemmy deleted everything between the “less than” character and “>”.
Lemmy also escaped the ampersands in their comment's link 😉
Isn't broken sanitization great!
RunAwayFrog 1 year ago • 83%
Next Day Edit: Sorry. Forgot to use my Canadian Aboriginal syllabics again. Because apparently it's too hard to admit HTML-sanitizing source markdown was wrong!
One thing that irks me in these articles is gauging the opinion of the "Rust community" through Reddit/HN/Lemmy😉/blogs... etc. I don't think I'd be way off the mark when I say that these platforms mostly collectively reflect the thoughts of junior Rustaceans, or non-Rustaceans experimenting with Rust, with the latter being the loudest, especially if they are struggling with it!
And I disagree with the argument that poor standard library support is the major issue, although I myself had that thought before. It's definitely current lack of language features that do introduce some annoyances. I do agree however that implicit coloring is not the answer (or an answer I want to ever see).
Take this simple code I was writing today. Ideally, I would have liked to write it in functional style:
async fn some_fn(&self) -> OptionᐸMyResᐸVecᐸu8ᐳᐳᐳ {
(bool_cond).then(|| async {
// ...
// res_op1().await?;
// res_op2().await?;
// ...
Ok(bytes)
})
}
But this of course doesn't work because of the opaque type of the async block. Is that a serious hurdle? Obviously, it's not:
async fn some_fn(&self) -> OptionᐸMyResᐸVecᐸu8ᐳᐳᐳ {
if !bool_cond {
return None;
}
let res = || async {
// ...
// res_op1()?;
// res_op2()?;
// ...
Ok(bytes)
};
Some(res().await)
}
And done. A productive Rustacean is hardly wasting time on this.
Okay, bool::then()
is not the best example. I'm just show-casing that it's current language limitations, not stdlib ones, that are behind the odd async annoyance encountered. And the solution, I would argue, does not have to come in the form of implicit coloring.
RunAwayFrog 1 year ago • 80%
Practically speaking, you don't have to.
Your executor of choice should be doing tokio
compat for you, one way or another, so you don't have to worry about it (e.g. async-global-executor with the tokio
feature).
async-std
is dead.
RunAwayFrog 1 year ago • 100%
I do, however, hold to the fact that any sudo implementation will be more complicated than doas. Sudo, as a project, has more options and usecases than doas so it also has more posibilities for bugs or misconfiguration for the user.
Fair.
I’m unable to tell what codebase your are refering to with you’re grep arguments, sorry.
sudo-rs
RunAwayFrog 1 year ago • 83%
Opendoas has a significantly smaller codebase. It only has 4397 lines of code compared to Sudo-rs’s staggering 35990 lines.
Hmm.
% tokei src | rg ' (Language|Total)'
Language Files Lines Code Comments Blanks
Total 76 16243 13468 682 2093
% tokei src test-framework | rg ' (Language|Total)'
Language Files Lines Code Comments Blanks
Total 196 34274 27742 1072 5460
% git grep '#\[cfg(test)\]' src |wc
40 44 1387
I too love making unaware "Tests Considered Harmful" arguments based on some blind analysis.
Funnily enough, one could easily do some actually potentially useful shallow analysis, instead of a completely blind one, simply by noticing the libc
crate dependency, then running:
git grep -Enp -e libc:: --and --not -e '(libc::(c_|LOG)|\b(type|use)\b)'
Ignoring the usage in test modules, use of raw libc
appears to be more than you would think from the title. One can also argue that some of that usage would be better served by using rustix
instead of raw libc
.
Of course authors can counter with arguments why using rustix
* is not feasible or would complicate things, and would argue that the use of unsafe+libc is required for this kind of project, and it's still reasonably limited and contained.
And a little bit more informed back-and-forth discussion can go from there.
* Searching for rustix in the sudo-rs repo returned this. So this predictably has been brought up before.
RunAwayFrog 1 year ago • 100%
exa
(which OP's readme says eza
is built on) supports creation times. Actual creation time (the "Birth" line in stat
output), not ctime
.
RunAwayFrog 1 year ago • 100%
I would bad mouth Axum and Actix just because of the overhype. But then, the latter is powering this very platform, and the former is used in the federation crate examples 😉
So let me just say that I tried poem
and it got the job done for me. Rusty API. Decent documentation. And everything is in one crate. No books, extension crates, and tower
s of abstractions needed.
I try to avoid tokio
stuff in general for the same reason, although a compatible executor is unfortunately often required.
RunAwayFrog 1 year ago • 100%
Look into Arc
, RwLock
, and Mutex
too.
Later, check out parking_lot
and co. and maybe async stuff too.
RunAwayFrog 1 year ago • 100%
From your list, I use bat
, exa
and rg
.
delta (sometimes packaged as git-delta
) deserves a mention. I use it with this git configuration:
[core]
# --inspect-raw-lines=false fixes issue where some added lines appear in bold blue without green background
# default minus-style is 'normal auto'
pager = "delta --inspect-raw-lines=false --minus-style='syntax #400000' --plus-style='syntax #004000' --minus-emph-style='normal #a00000' --plus-emph-style='normal #00a000' --line-buffer-size=48 --max-line-distance=0.8"
[interactive]
diffFilter = "delta --inspect-raw-lines=false --color-only --minus-style='syntax #400000' --plus-style='syntax #004000' --minus-emph-style='normal #a00000' --plus-emph-style='normal #00a000' --line-buffer-size=48 --max-line-distance=0.8"
[delta]
navigate = true # use n and N to move between diff sections
light = false # set to true if you're in a terminal w/ a light background color (e.g. the default macOS terminal)
[merge]
conflictstyle = diff3
RunAwayFrog 1 year ago • 100%
Still on 0.17.4 btw.
RunAwayFrog 1 year ago • 100%
--all-features
doesn't work with that particular crate because two of the features conflict with each other. The features list in my command is the one used for docs.rs from the crate's Cargo.toml
.
RunAwayFrog 1 year ago • 100%
are there any hurdles or other good reasons to not just adding this to every create?
I'm no expert. But my guess would be that many crate authors may simply not be aware of this feature. It wasn't always there, and it's still unstable. You would have to reach the "Unstable features" page of the rustdoc book to know about it.
Or maybe some know about it, but don't want to use an unstable feature, or are just waiting for it to possibly automatically work without any modifications.
Of course, I would assume none of this applies to the embassy
devs. That Cargo.toml
file has a flavors
field, which is something I've never seen before 😉 So, I'm assuming they are way more knowledgable (and up-to-date) about the Rust ecosystem than me.
RunAwayFrog 1 year ago • 100%
So, this is being worked on. But for now, that crate needs this line in lib.rs
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
And this line in Cargo.toml
's [package.metadata.docs.rs]
section:
rustdoc-args = ["--cfg", "docsrs"]
With these changes, feature gating will be displayed in the docs.
To replicate this locally:
RUSTDOCFLAGS='--cfg docsrs' cargo doc --features=nightly,defmt,pender-callback,arch-cortex-m,executor-thread,executor-interrupt
RunAwayFrog 1 year ago • 100%
I constantly seem to include something from the docs, only to be told by the compiler that it does not exist, and then I have to open the source for the create to figure out if it’s hidden behind a feature flag.
As others mentioned, the situation is not perfect. And you may need to check Cargo.toml
. Maybe even the source.
But as for the quoted part above, the docs should definitely indicate if a part of the API is behind a feature. Let's take rustix
as an example.
Here is the module list:
Here is the view from inside a module:
Here is the view from a function page:
This is also true for platform support. Take this extension trait from std
:
Now, it's true that one could be navigating to method docs in the middle of a long doc page, where those indicators at the top may be missed. But that's a UI issue. And it could be argued that repeating those indicators over and over would introduce too much clutter.
RunAwayFrog 1 year ago • 100%
Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.
Well, getters are not an official concept in Rust. You can do whatever works best in your case.
Just worth pointing out that a method with a return value of OptionᐸVecᐸStringᐳᐳ
wouldn't be really a getter, as you must be constructing values, or moving ownership, or cloning. None of these actions conceptually belong to a getter.
Also, you should be clear on the what the Option
abstraction means. Does it mean the vector is empty? Does it mean the vector does not exist or some sort of null (FFI ore serialization contexts)? And make sure the code does what you expect it to do.
RunAwayFrog 1 year ago • 100%
Note: the ᐸᐳ
characters used below are Canadian Aboriginal syllabics because Lemmy devs haven't fixed broken input sanitization yet.
A vec and a string are basically the same thing (a series of bytes)
Everything is a series of bytes! I thought you were going to mention that both are fat pointers. But that "series of bytes" description is quite weird.
This makes handling it much easier because you can still iterate over it
This is not a valid consideration/objection, as Option
s are iterable and you can flatten them:
fn main() {
let v = vec![1,2,3];
for n in Some(&v).into_iter().flatten() {
eprintln!("{n}");
}
for n in None::ᐸ&Vecᐸi32ᐳᐳ.into_iter().flatten() {
eprintln!("{n}");
}
}
This might involve the compiler making an allocation of an empty array but most of them (gcc, ghc) will now what you are doing and optimize the null check on the empty array to a bool check
This paragraph appears to be out of place in the context of a Rust discussion.
RunAwayFrog 1 year ago • 100%
It might actually be a bug that the thread didn’t end up here as comments
If that's the case, that's a good bug in my book.
RunAwayFrog 1 year ago • 100%
I will use the Rust Book first.
Good choice. Follow it with this Little Book of Rust Macros. And don't verge into the unsafe
stuff early, and don't verge into it later unless it's really necessary.
RunAwayFrog 1 year ago • 100%
if you’ve been following us for a while you know we’re passionate about #Rust! 🦀
who's "us"?
following where?
is there a reason to particularly care about ᐸwhoever you areᐳ
's passion for Rust?
^ only meant half-seriously to point to the silliness of microblogging to a discussion community.
Note: the
ᐸᐳ
characters are Canadian Aboriginal syllabics because Lemmy devs haven't fixed broken input sanitization yet.
RunAwayFrog 1 year ago • 100%
RunAwayFrog 1 year ago • 100%
Because the audiophile is broke, and will have to listen to some music on a lowly device, but the craving for some placebo is still there.
EDIT: btw, the bitrate is missing a k
in your command 😉
RunAwayFrog 1 year ago • 100%
Not audiophilic enough.
ffmpeg -i in.flac -ar 48000 \
-af aresample=resampler=soxr:precision=28:cheby=1:dither_method=shibata \
-c:a libopus -b:a 224k out.opus
RunAwayFrog 1 year ago • 66%
There is no need to talk about an imaginary version of IPFS. GNUnet already exists. You can add that to the list of actually superior technologies that long predates IPFS.
As I mentioned, IPFS is nothing but very basic tech that got overhyped to junior/uninformed developers, and crypto scam victims.
RunAwayFrog 1 year ago • 100%
If you were on GNU/Linux, my answer to your questions would have had nothing to do with Rust. It would have involved tools like readelf
and ldd
, maybe strace
.
So, maybe check out what equivalent tools exist on Windows, and try using them.
RunAwayFrog 1 year ago • 100%
I only participated in two surveys, the first, then the second or third (don't remember).
I am here. So, while I'm not sure, I think I'm still interested 😑
Maybe gauging level of interest based on the number of survey participants is not a sound strategy 🤔
I think there used to be a question about how long you've known/used Rust. And you would find that new or relatively new users were always overrepresented. Although, maybe that over-representation was read wrongly at times.
If I had to speculate something based on this decline, I would guess that most people who were to give Rust a try at some point, have actually done so already. So the influx of people new to the language, where for them the novelty (and the excitement/resentment that comes with it) hasn't worn off already, has slowed down.
I'd say that's understandable, and is to be expected after many years of hyped existence.
RunAwayFrog 1 year ago • 80%
Besides being overhyped basic tech where way more useful and practical solutions existed for decades (Freenet existed since year 2000 btw, and Tahoe-LAFS since 2007), there is nothing private about IPFS. This is a dangerous message to purport.
IPFS is as practically useful as NFTs. No wonder the two crowds connected well!
iroh is an attempt to create a useful and practical IPFS. But none of the bigger practical features is implemented yet. And the design itself doesn't appear to be finalized. I'm willing to give iroh
a chance, although the close proximity to the IPFS crowd doesn't fill one with confidence.
RunAwayFrog 1 year ago • 100%
- I would drop the derive shorthands, and drop the
Cypher
prefix from the derive macros. They are already namespaced under the crate. - Regarding the
ty::new()
impls, I'm not a hardline devotee of the builder pattern, but when there are multiple private fields of the same type, I would absolutely prefer it, to remove the possibility of field-value confusion at construction.
I didn't dig deeper because I noticed you posted this to Reddit first 😉
RunAwayFrog 1 year ago • 100%
Defederation questions/requests should be made in private, at least initially. That is to avoid turning an instance, which may temporarily not be actively administered/moderated, into a hotbed of illegal posting.
As it stands, any concern troll can turn a random small instance, which may not have an admin around for two days or three, into a hotbed of illegal or potentially-illegal activity, simply by bringing attention to it with a public defederation request.
Even with the presumption of genuine concern, the effect and end result will be the same.
RunAwayFrog 1 year ago • 21%
Not a good move. That instance had almost no content before the defederation trolls gave it publicity. You just made the age old mistake of feeding the trolls. And they will come back for more, and more, and more...
RunAwayFrog 1 year ago • 17%
Great original retort there. Not part of "the lot" I had in mind in my previous comment at all.
RunAwayFrog 1 year ago • 26%
if 9 people are fine sitting at a table with a Nazi, you have 10 nazis
Good thing there is no table involved.
both sides
Actually, if you read carefully, you will find that my arguments are against both sides, where the sides are the Stasi and McCarthyists.
That is if my argument was ideological. But it wasn't. It was a technical and practical answer where I consider(ed) whatever ideologies supposedly involved irrelevant.
Monitoring instances and gouging their supposed collective thought, and making decisions based on that in an attempt to appease the masses, will make the job of general purpose instance admins unattainable.
It would be a very effective way for the likes of Reddit to fuck with the Fediverse, actually.
Weekly instance defederation talk loaded with emotional/psychological manipulation, moral grandstanding, and why not, some bullying.
"table with a Nazi" analogies. Linking the Paradox of tolerance wikipedia page for the 345636556th time. The lot.
This may work with instances that like their Stasi or McCarthyist wanna be agents (a.k.a. users) keeping their eyes out for baddies.
For general purpose instances, this will be a great way to make them quit. A desirable outcome for some. I'm not one of them. So, I, and hopefully others, am willing to take the hit and speak out, and state things that some admins may want to state, but don't feel comfortable doing so publicly.
RunAwayFrog 1 year ago • 37%
A general purpose instance with no claimed "safe space" offering should only be burdened with instance-level defederation talk when another instance is behaving badly at a technical level, or when its admins are actively involved in, or not actively trying to prevent, spam, brigading, repeat copyright infringement, and stuff like that.
Bad thoughts expressed in text form by individual users shouldn't be ground for such talk, and to create a foray over such an inactive instance is quite self-indulging.
If anything, maybe a couple of previous defederation decisions were taken in haste, and should be reconsidered!
If you're looking for a "safe" instance, there are a couple that should suit you. One of them was already recommended to you.
RunAwayFrog 1 year ago • 91%
Funny you should mention that. I think iced
as of four days ago can do this!
If I'm reading the release notes and Cargo.toml
right, cargo add iced --no-default-features
and you should be good to go, as tiny-skia
will be used as a rendering backend instead of wgpu
.
In [a comment](https://sh.itjust.works/comment/1227148) I wrote, I was surprised to see something I didn't write showing up, in the form of a third dot. So, where did the third dot come from? Well, markdown-it has an extension where [*"typographic replacements"*](https://github.com/markdown-it/markdown-it/blob/master/lib/rules_core/replacements.js) are done. You can see them all in action [here](https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%23%23%20Typographic%20replacements%5Cn%5CnEnable%20typographer%20option%20to%20see%20result.%5Cn%5Cn%28c%29%20%28C%29%20%28r%29%20%28R%29%20%28tm%29%20%28TM%29%20%28p%29%20%28P%29%20%2B-%5Cn%5Cntest..%20test...%20test.....%20test%3F.....%20test!....%5Cn%5Cn!!!!!!%20%3F%3F%3F%3F%20%2C%2C%20%20--%20---%5Cn%5Cn%5C%22Smartypants%2C%20double%20quotes%5C%22%20and%20%27single%20quotes%27%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D) (tick **typographer** on and off). So, wherever two or more dots are written, even if around quotes, three dots will be rendered (`'..'` => '..') While it may seem nice, this is more trouble than good IMHO. Not to mention the fact that people using other apps, utilizing other markdown implementations, will not see what others see (which is why some of you probably had no idea what the hell I was talking about at the start of this post). It is my opinion that use of non-standard markdown extensions should be kept to a minimum, or preferably not used at all. And since a new UI is going to be written (which may open the possibility to use a high-quality markdown Rust crate), this should be a deliberate implementation choice going forward.
``` {"msg":"Error in store"} ``` Or the longer version: ``` < HTTP/2 500 < server: nginx < date: Sat, 15 Jul 2023 06:45:55 GMT < content-type: application/json < content-encoding: gzip < access-control-expose-headers: content-encoding, vary, content-type, date, content-length < vary: accept-encoding, Origin, Access-Control-Request-Method, Access-Control-Request-Headers < * Connection #0 to host sh.itjust.works left intact {"msg":"Error in store"} ```
Using this with Stylus: ``` css li .comment-node { padding: 0.5ex; border: 0.1ex solid #80808060 !important; border-radius: 1ex; } li li .comment-node { border-left: none !important; border-top: none !important; border-radius: 1ex 1ex 1ex 0 !important; } ``` Or for a more lightweight change: ``` css .comment-node { border-bottom: 0.1ex solid #80808060 !important; ``` It's the lack of **clearly visible** separation between comments that just doesn't look right to me.