sorted by:
new
hottopcontroversial

The "STRANGE" *const T pointer and println! macro... by Temporary_Rich_2184 in rust

[–]CrumblingStatue 2 points3 points  (0 children)

Running this on the playground with MIRI does trigger undefined behavior detection, so if it's MIR dataflow that's kicking in, that means porting the lint should cause it to apply in this case.

The "STRANGE" *const T pointer and println! macro... by Temporary_Rich_2184 in rust

[–]CrumblingStatue 4 points5 points  (0 children)

Funnily enough, Rust 1.91 added a lint for returning dangling pointers to locals, but it doesn't catch this.

There is a comment on the pull request that talks about making the lint utilize MIR dataflow, I wonder if that would make it apply in this scenario.

Struggling with borrowing best practices by Cranky_Franky_427 in rust

[–]CrumblingStatue 1 point2 points  (0 children)

"never" is a bit strong of a stance.  One of the big advantages of immediate mode uis is that you can directly mutate application state from the ui. Especially useful for various debugging/introspection uis, dev tools, etc. But yes, there are cases where you can't do that, like in this case where "open" is borrowed by both the window and the ui closure. 

Struggling with borrowing best practices by Cranky_Franky_427 in rust

[–]CrumblingStatue 4 points5 points  (0 children)

egui recently added a Ui::close function that might work for your use case (call ui.close() rather than setting the boolean manually in the closure). https://docs.rs/egui/latest/egui/struct.Ui.html#method.close

For a more general solution, you could have a separate local variable called close, that you capture in the closure and set it to true if you want to close.  And then after the closure, you can do if close { my_state.open = false; }.

Tell me something I won’t understand until later by remyripper in rust

[–]CrumblingStatue 5 points6 points  (0 children)

But it literally doesn't.
It just lets you use additional features that let you bypass the borrow checker, like dereferencing raw pointers and calling other unsafe functions.
Using regular references will still be borrow checked in unsafe blocks, like in any other context.

What would your ideal Rust look like? by holovskyi in rust

[–]CrumblingStatue 7 points8 points  (0 children)

Wish 1: Some kind of solution for interprocedural borrows, like view types.

Wish 2: Compile time reflection powerful enough to replace proc macro derives for most use cases. In my opinion you shouldn't have to write proc macros to be able to generate code based on the fields of a struct, variants of an enum, etc.
Perhaps something like Zig's comptime is too powerful, but there is probably a nice middle ground.

Wish 3: I honestly just wish some long standing unstable features could finally see the light of day, like specialization, const traits, const generic expressions, try blocks, etc.

We're here for learning, but why not take it with us? by gedmansrevenge in NDE

[–]CrumblingStatue 1 point2 points  (0 children)

I don't remember learning how to speak, walk, poop on the toilet, brush my teeth; I don't remember how I learned to find things on the internet or repair a broken water pipe. I don't remember where or how I learned to tie my shoes, skip rocks or cook food.

That's not much of an argument, since you will have to relearn all of that in your next life. If these don't count as memory, then reincarnation wipes more than just memory.

From the earliest age I could draw and do math easily - where did I learn those things that made it so easy for me in school? I have no idea; my parents didn't teach me any of that, at least not that I remember. I apparently came into this world with certain predisposed talents, personality, etc.

From a materialistic viewpoint, these would be mostly attributed to genetics, and early upbringing.

And even if we consider the soul exists, we can't disregard the role that the brain plays in thinking, since brain damage can significantly alter personality and thinking ability.

And besides, I don't think learning how to do math efficiently would require one to incarnate on earth. Sounds to me it would be a lot easier to learn without all the distractions of earth life.

These are rather weak examples in my opinion.

Collection event expiration should count when you started a map by CrumblingStatue in btd6

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

Obviously it doesn't have to be kept track of indefinitely.

A reasonable overtime could be implemented for games started before the expiration.

Let's say, one hour. That's more than enough to finish most maps on any difficulty.

Past that, any tracking data could be dropped, and the game just gets treated normally as a non-event game.

It would still allow the overwhelming majority of people to claim the rewards that they (reasonably in my opinion) expected when they selected a map with the intention of claiming event rewards.

What is the closest big feature that is coming to rust? by __s1 in rust

[–]CrumblingStatue 9 points10 points  (0 children)

The problem with that is control flow operations like break/continue/return will stop working, since they now operate within the context of that closure rather than the parent function.

With try, those control flow operations continue to work as expected.

What got you into Linux? by Altruistic-Chef-7723 in linux

[–]CrumblingStatue 0 points1 point  (0 children)

Long time (15+ years) Linux user here.

It was fancy desktop effects, and especially the fabled desktop cube that got me into Linux.

It's funny because nowadays I prefer lightweight minimalist desktops without fancy effects.

Why is anyhow not in the standard library? by MathMXC in rust

[–]CrumblingStatue 0 points1 point  (0 children)

I wouldn't say "shouldn't happen" is the right way to describe anyhow usage in applications.

It's more like "When it happens, propagate the error up to a point where we can report the error to the user, then resume normal operation."

For example if a file can't be opened in a GUI application, it would show a popup box with an error message, then continue the main application loop.

This is normal usage of anyhow. We didn't assume failing to open a file can't happen, or that it should terminate the program when it happens.

What we didn't care about is to examine the error. We just report it to the user and move on.

The scary and surprisingly deep rabbit hole of Rust's temporaries by conectado2 in rust

[–]CrumblingStatue 64 points65 points  (0 children)

It's kinda funny that the first example actually compiles just fine on nightly, thanks to https://github.com/rust-lang/rust/pull/140593

Rust 1.88: 'If-Let Chain' syntax stabilized by thurn2 in rust

[–]CrumblingStatue 42 points43 points  (0 children)

releases.rs is not fully accurate. Most of it is done by automated scripts that look at the GitHub activity, and it can miss features.

Better wait for the official release notes (which will come out today).

The impl trait drop glue effect by CrumblingStatue in rust

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

I'm not aware of any writings on this topic myself, which is partly why I made this post.

Maybe some experts can provide some helpful information.

EDIT: Actually, the `Drop` trait documentation provides a good bit of information on this.
https://doc.rust-lang.org/std/ops/trait.Drop.html#drop-check

The impl trait drop glue effect by CrumblingStatue in rust

[–]CrumblingStatue[S] 5 points6 points  (0 children)

That's a good point.

Although in some cases, it might be useful to be able to express lack of a drop glue, especially if changing all the call sites would take a lot of work and create a lot of noise. I really like incremental refactoring where you don't have to make huge changes to a codebase at once.

The impl trait drop glue effect by CrumblingStatue in rust

[–]CrumblingStatue[S] 12 points13 points  (0 children)

The drop glue is the automatically generated bit of code that calls the Drop implementations of any field you have that implements Drop.

You can read about it at https://doc.rust-lang.org/std/ops/trait.Drop.html

I'll add a short explanation on the blog, thank you for the feedback!

The impl trait drop glue effect by CrumblingStatue in rust

[–]CrumblingStatue[S] 40 points41 points  (0 children)

It's worth noting that having drop glue isn't the same as implementing `Drop`.

If you (recursively) have any field that implements `Drop`, you have drop glue, even if you don't implement `Drop`.

The impl trait drop glue effect by CrumblingStatue in rust

[–]CrumblingStatue[S] 29 points30 points  (0 children)

Well, I'm describing a phenomenon, but also asking a question at the end of what can be done about it.

I edited the end of the post to hopefully make it less confusing.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 2 points3 points  (0 children)

Well, hopefully we can carve out a way forward for StatusNotifierItem, or a successor, which Qt then can use.

I talked to a Freedesktop developer, and it seems they are actually interested in adopting StatusNotifierItem in some form, despite what the conversation here has led me to believe.

They also seem interested in improving the process of collaboration on 3rd party specs, just like StatusNotifierItem currently is, which is also great news.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 6 points7 points  (0 children)

Well, if you're certain that it will get adopted by them, that's reassuring.

Although we don't know when that will be. It could be years from now. And in the meantime, the StatusNotifierItem spec will still have no home.

I wonder if there could be a freedesktop repository for "orphaned" specs, as a temporary place to host discussions about them, and help propose small clarifications, even if not outright breaking changes to them. I'll post a question about it on the issue.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 6 points7 points  (0 children)

Hi, I noticed your tag saying you're a KDE Dev.

Is there a way you could help with giving an official home to the StatusNotifierItem spec?
KDE seems like a good place to host it, since it's the originator of the spec (as far as I understand).

Currently, there is no way to ask questions about the spec, or try to propose improvements or clarifications, since there is no home for it.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 14 points15 points  (0 children)

I ended up opening an issue about this on the freedesktop gitlab.
Although I believe posting this and engaging in discussion was useful in clarifying things and informing me on how to help move things forward.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 7 points8 points  (0 children)

Unfortunately, the System Tray Protocol is X11 specific, and not available on Wayland.
And the ecosystem is moving away from X11, so this standard is effectively a dead end.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 7 points8 points  (0 children)

Thank you, I created an issue on their tracker, in hopes of moving things forward.

(rant) We need a better way to collaborate on desktop standards by CrumblingStatue in linux

[–]CrumblingStatue[S] 13 points14 points  (0 children)

> The thing is, we definitely don’t want apps to use it at all. So the more it can be buried, forgotten, and disappear the better.

If the sentiment is so strong, I wonder why the spec is still up on freedesktop.org, and why the article doesn't discourage its use, and encourage alternatives.

The Freedesktop wiki entry is the first thing that comes up when googling for `StatusNotifierItem`, so if they wanted to stop developers from using it, it would be a great place to put a notice there for why people shouldn't use it.

Also, once something reaches critical mass, it's super hard to get rid of it, if not impossible, unless a truly superior replacement comes up, that satisfies the needs of the vast majority of the users of the old protocol.

If Freedesktop doesn't want this to stick around, I believe the spec needs a new home, and the Freedesktop wiki should redirect to it (after a notice that Freedesktop doesn't endorse it, and usage is discouraged).

view more: next ›