In rust, tests are written in the same file as the code. But I want to have the tests in a separate file.
Conventionally, only the integration tests are written in files under tests folder. 1
I just wanted to have the unit tests in a separate file. So I created a file src/my_tests.rs and moved all the tests there.
But cargo test kept saying running 0 tests
Turns out, I’m not the only one.
No, this is not a post about how to implement doubly linked list in rust.
Or ir could be a very short post, since doubly linked list in built-in the std::collection as LinkedList
Following functions are available:
new : Creates new/empty linked list push_back : Adds an element to the list push_front : Since this is doubly linked list, element can be added at the beginning as well. Nice! pop_back and pop_front : Remove an element from the list clear : empty the entire list append : Append one list to another to make bigger list.
I initially tried to turn off the type hints via rust-analyzer extension setting, but that did not work 😞
Turns out it is very complicated (at least for me) documentation did not help 😞
Here is what worked for me. Thanks to SO 1
Open Command Palette Cmd+Shift+P Select Preferences: Open User Settings (JSON) from the drop down Add the following to existing settings Or create new one, if empty. You may need to enclose it within { } though.
Today, I accidentally found out that instead of using {:?} to debug print, if one just adds an extra # like {:#?} the variable is pretty printed.
This makes sense for struct rather than simple data types like numbers or strings.
The interesting part (for me at least) is how I “discovered” it 😄
When I was printing a struct (for debugging 🙈) VS Code (I think rust analyzer plugin) showed a popup how the struct does not implement Display 1
It is (almost) drop-in replacement for pip. We just need to invoke it as uv pip instead of pip
How to install ? pipx install uv : This makes it available everywhere. Other alternatives are curl (recommended) and brew (on macOS) It is superfast I tried installing Django
$ uv pip install Django Resolved 3 packages in 138ms Downloaded 3 packages in 2.53s Installed 3 packages in 228ms + asgiref==3.8.1 + django==5.
In rust, str is a primitive type, but many non-primitive types are also in scope by default.
e.g. We do not need to add use statement to use Vec - which is NOT a primitive type.
It comes from std::vec
So Vec::new() is really std::vec::Vec::new()
Vec::new() works because Rust inserts this at the beginning of every module:
use std::prelude::v1::*; This makes Vec (and String, Option and Result) available by default.
When I published my previous post on mastodon, Sebastian pointed out 1 that using #[cfg] is better than cfg! macro.
Documentation explains that :
cfg!, unlike #[cfg], does not remove any code and only evaluates to true or false. For example, all blocks in an if/else expression need to be valid when cfg! is used for the condition, regardless of what cfg! is evaluating.
Thanks, Sebastian!
See this thread for the original discussion.
We all know we shouldn’t use print debugging, and yet we all do 😉 1
Jokes apart, when I’m still developing the code, I use the debugger where possible. But sometimes, I want to keep certain print statements to verify runtime behaviour, especially when rolling out new feature and when there are too many variations (some of them unknown) in incoming data.
I’m aware, logging is the right way to handle this (with loglevel set to debug or something), but it seems too much when developing toy projects.
At first, I assumed since we’ve declared the capacity upfront, it would be maximum capacity of the Vec
Turns out, since Vec is expected to shrink and grow, as needed, there is no maximum capacity for Vec
It just ensures that “sufficient” memory is allocated to the Vec, such that memory reallocation is not required.
On the other hand, if you need more that what you declared with with_capacity, you will get it, but there will need to be reallocation (of memory), so it will be inefficient.
Today I learnt that certain rust code can be marked such that it is compiled only for specific platform.
This makes sense for low level libraries that provide platform-specific functionality that is not available on other platforms.
This is achieved by tagging the function with #[cfg(target_os = "xyz")]
Here xyz can be one of the following :
“windows” “macos” “ios” “linux” “android” “freebsd” “dragonfly” “openbsd” “netbsd” Similar to target_os, here are other options :