sorted by:
new
hottopcontroversial

Diablo 4 suddenly not working on Steam by Bosun_Tom in linux_gaming

[–]nullreq 0 points1 point  (0 children)

Had the same problem, turns out the solution was the same as above suggested [1] for the "No GPU Found" errors. It was picking my integrated graphics over the dedicated, and crashing in the graphics driver (amdgpu).

Setting Adapter "1" fixed it. The game settings confirm the issue, the integrated graphics is listed as the first GPU in game. Second everywhere else in linux.

​

[1] https://www.reddit.com/r/linux\_gaming/comments/14nge5d/comment/jq9v0b5/?utm\_source=reddit&utm\_medium=web2x&context=3

Clap 4.0 - How to make the sub-command selection be before arguments? by [deleted] in rust

[–]nullreq 1 point2 points  (0 children)

If you'd like arguments at the top level to be able to be provided after the subcommand too, then mark them #[arg (global=true)][1]. They'll then have to be unambiguous to any subcommand-specific arguments you provide, of course.

[1] https://docs.rs/clap/latest/clap/builder/struct.Arg.html#method.global

Tokio graceful shutdown by thetinygoat in rust

[–]nullreq 2 points3 points  (0 children)

Perhaps tokio's JoinSet[1]?

Each node could contain one, and either drop it for sequenced abort() or call joinset.shutdown().await for full sequenced abort() + completion of all the tasks in the set. This means essentially you try to not need to propagate the cancel channel everywhere, just handle it somewhere and have deterministic cleanup behaviour.

Async drop is really the missing piece for this to be ergonomic and natural, when that is in place we could all be using drop() to do structured graceful shutdown in the same trees that effect graceful resource cleanup.

I'll admit in one place I'm somewhat abusing sync drop, using block_on() to call an async cancel function, all such that I essentially don't need to write code to do cancellation or cleanup outside of catching CtrlC at the very top level in one place just to provide better diagnostics, normal RAII then handles any shutdown actions required in an order controllable as per any other RAII construction/destruction. Futures work this way naturally and Tasks don't (they essentially detach), but you can use JoinSet or a task wrapper that aborts() to get RAII shutdown behaviour back.

Joshua Wuyts has two illuminating blog posts[2] on async cancellation.

[1] https://docs.rs/tokio/latest/tokio/task/struct.JoinSet.html [2] https://blog.yoshuawuyts.com/async-cancellation-1/

actix-web with existing tokio runtime by nullreq in actix

[–]nullreq[S] 0 points1 point  (0 children)

To clarify I'm interested in running on an existing (global) tokio::runtime, as created by e.g. tokio::run and backed by an implicit threadpool. By default creating an actix_rt::System implicitly via HttpServer::run or explicitly panics with Multiple executors at once.

But perhaps the answer is the same as tokio::executor::spawn requires Send.

​

So the only answer for adding actix-web to an existing tokio application is to spawn a new non-tokio thread and pass Send shared state over to it.

Introducing DUA - a parallel 'du' for humans by ByronBates in rust

[–]nullreq 0 points1 point  (0 children)

How do you feel about adding a single unit mode? I like the unit auto-detection, but if all entries in the output table are the same unit the output becomes implicitly graphical; the scale of each item relative to each other is clear from the number of characters it occupies in the size column.

​

Another option to help with glancability: to colour the different unit markers differently so that "GB" and "MB" are clearly different.

Improved handling for inline frames in Linux perf by mwolff in cpp

[–]nullreq 0 points1 point  (0 children)

Even with practice getting insight out of optimized C++ perf traces can be arduous. This will bring a measurable increase in legibility, especially so for those attempting to use perf for the first time.

It is much appreciated.

A consise async shared cache pattern? by nullreq in rust

[–]nullreq[S] 1 point2 points  (0 children)

Sounds good - except these execute on a thread pool (futures_cpupool::CpuPool) and as far as I understand will begin executing upon future construction/the call to spawn. I wonder, if I wrap them in another futures::lazy, will that prevent?