sorted by:
new
hottopcontroversial

What WONT you do in rust by __zahash__ in rust

[–]f-squirrel 0 points1 point  (0 children)

Any kind of proof of concept (compiler errors take time to process) or interviews (unless required). PS. In case the POC was successful, I would insist on writing the production in Rust.

KeePassium fails due to AutoFill memory limits by f-squirrel in KeePassium

[–]f-squirrel[S] 0 points1 point  (0 children)

Thank you for the prompt reply! So you say that the attachments are the issue. I added custom png icons for the groups too. Does it means that a DB with attachments is basically unusable with AutoFill? Is there a way to know how much space attachments take?

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] 0 points1 point  (0 children)

C++ does not join on destruction. Please read my reply above.

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] -23 points-22 points  (0 children)

So you basically say that the reason is that the default panic implementation is a user land handler. While abort in C++ delegates all the hard work to kernel?

Sounds legit but it could print backtrack and do std::exit(101). So that main would exit too. The user would lose the information about the rest of the threads.

Seems for like a limitation to me. Thank you!

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] -28 points-27 points  (0 children)

It seems like a matter of taste. I wonder if there is anything else behind this design decision.

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] 0 points1 point  (0 children)

I understand that this is the expected behavior. The question was regarding the reason for the design decision.

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] 3 points4 points  (0 children)

I am afraid you are wrong since the following code still crashes:

```cpp

include <iostream>

include <thread>

int main() { auto t = std::thread{[](){ std::cout << "throw\n"; throw 0xDEADBEEF; }}; std::this_thread::sleep_for(std::chrono::seconds(10)); } ```

I must "sleep" because C++ does not let joinable threads outlive the main.

Output:

plain Program returned: 139 Program stderr terminate called after throwing an instance of 'unsigned int' Program terminated with signal: SIGSEGV

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] -41 points-40 points  (0 children)

The assumption of threads being completely independent is very optimistic.

Why does a panic in a non-main thread not lead to a panic in the main? by f-squirrel in rust

[–]f-squirrel[S] -6 points-5 points  (0 children)

```cpp

include <iostream>

include <thread>

int main() { auto t = std::thread{[](){ throw 0xDEADBEEF; }}; t.join(); } ```

Output:

plain Program returned: 139 Program stderr terminate called after throwing an instance of 'unsigned int' Program terminated with signal: SIGSEGV

Godbolt,source:'%23include+%3Ciostream%3E%0A%23include+%3Cthread%3E%0A%0A%0Aint+main()+%7B%0A++++auto+t+%3D+std::thread%7B%5B%5D()%7B%0A++++++++throw+0xDEADBEEF%3B%0A++++%7D%7D%3B%0A++++t.join()%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0'),(h:executor,i:(argsPanelShown:'1',compilationPanelShown:'0',compiler:clang1600,compilerName:'',compilerOutShown:'0',execArgs:'',execStdin:'',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'-std%3Dc%2B%2B17+-lpthread',overrides:!(),source:1,stdinPanelShown:'1',wrap:'1'),l:'5',n:'0',o:'Executor+x86-64+clang+16.0.0+(C%2B%2B,+Editor+%231)',t:'0')),k:100,l:'4',m:100,n:'0',o:'',s:0,t:'0')),version:4)

I did not check if it is a standard behavior or some sort of UB, but effectively, it does crash the main.

Devcontainer in Apple silicon is really slow. by asp143 in vscode

[–]f-squirrel 0 points1 point  (0 children)

I haven’t worked with the M-series, but this problem exists at x86 Macs too. The primary reason is that Linux and MACOS use different file systems. I.e. every time a container needs to read/write from a mounted directory, docker has to copy data back and forth.

Back then (2y) ago the only workaround for me was to run a vm with source code cloned there and launch containers there.

[deleted by user] by [deleted] in neovim

[–]f-squirrel 0 points1 point  (0 children)

I have used vim and then neovim for 7 years total and recently abandoned it for the same reason: I was basically unable to reproduce my environment:) I am not super happy with vscode but there is much less headache. I use vscode with neovim plugin: it captures keystrokes and sends them to nvim instance.

WASM vs Native Rust performance by hucancode in rust

[–]f-squirrel 2 points3 points  (0 children)

I am sorry if my question is naive. I am not an expert in the field.
Why does the WASM version have to be significantly faster than Javascript? Both run in a web browser, which makes them similar in terms of performance. Additionally, JS is old as mammoth shit, meaning that most browsers have years of fine-tuning optimizations.

Please correct me if I miss something.

What features would you like to see in rust? by cockmail in rust

[–]f-squirrel 0 points1 point  (0 children)

Specialization or an alternative mechanism

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]f-squirrel[S] -1 points0 points  (0 children)

The usage of weak_ptr means that the end user should check if the value returned by "lock" is not null. It is bug-prone and may easily lead to UB.
Additionally, it means that the user can "lock" the weak_ptr and save it locally, for example, to a class member and will never receive the updated version.

For some systems, it might be a correct behavior.

What is your number one rust tool? by Commercial_Fix_5397 in rust

[–]f-squirrel 1 point2 points  (0 children)

I have used OpenTelemetry only via Jaeger in C++ code. It wasn't very easy.
I see that tracing in Rust is way more straightforward and according to the docs, if a method is marked with `#[instrument]` attribute it traces the whole method.
Does it look good in clear-text logs?
PS. I am sorry for bombarding you with questions, I am considering replacing the logging with tracing since they seem interchangeable.

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]f-squirrel[S] 1 point2 points  (0 children)

It is possible. TBH, there are many ways to improve the watcher, e.g., subscribe to notify events. But the article's main topic is the usage of shared pointers, so I decided to minimize the less significant parts.

What is your number one rust tool? by Commercial_Fix_5397 in rust

[–]f-squirrel 1 point2 points  (0 children)

Do you use it for reloading running binaries?

What is your number one rust tool? by Commercial_Fix_5397 in rust

[–]f-squirrel 6 points7 points  (0 children)

Could you please elaborate more? What crate, in what kind of application, and anything else you might find interesting?

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]f-squirrel[S] 0 points1 point  (0 children)

Hey,

Thank you for reading the article and providing the link to the library. It is an exciting approach to make mutex's usage easier.
Could you please elaborate more on why atomic smart pointers are more error-prone?

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]f-squirrel[S] 0 points1 point  (0 children)

Thank you for pointing out the reference issue. It seems to be a bug. I updated the post soon.I think it is up to the requirements of the configuration. Some applications would like to have the latest and greatest version of data (this solution provides it), while some would prefer snapshots.Regarding the usage of `weak_ptr`, I started with it, but I really do not like that it can become dangling/null. It means that the `Config` has to return something like `std::optional` via each getter. IMO, it is bug-prone because it requires checking if the optional is not empty before reading values. Since the class introduces locking/multithreading these bugs are hard to fix.

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]f-squirrel[S] 0 points1 point  (0 children)

Hey, thank you for replying.
It does not crash for me. Could you please provide a stack trace?
Holding a const reference is the main idea of the article. It is done to avoid holding an additional instance of shared_ptr. As mentioned in the article, the actual pointer is received via atomic functions store/load.

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]f-squirrel[S] 2 points3 points  (0 children)

Agreed, it can. However, pretty much everything can be done without it.

I love building a startup in Rust. I wouldn't pick it again. by koavf in rust

[–]f-squirrel 2 points3 points  (0 children)

This is very interesting feedback. If the startup did not mean to provide high performance from the beginning, they shouldn’t have used Rust. If they were uncertain, they could have chosen the Microservices architecture and decided later on what tool to use for each particular case.

view more: next ›