Why you’ve wrote “dont sign in…” for GitLab? GitLab is safe

You can clone the original, add fnmatch-regex2 as a remote, fetch it, and do a diff between them to see what changed if you want.

If you go with this route, do not open the code with rust-analyzer active because it might run build scripts and proc macros automatically.

On the other hand, bevy is such a neat general manager and framework. You can run crossplatform parallel async within it, stall things with timers, set custom loop rates. I'm experimenting with using it as non-game frontend, and so far it seems much more suited for fast development than those reactive frameworks imitating js frameworks if something more complicated than simple ui is needed. The gaming community cares for each othes, so sweet. The only downside is 30mb wasm file for prototype level of complexity app, but I haven't even started optimizing yet, and it will not grow much probably once it becomes super sophisticated.

For a graphics-intensive application, this (or something custom with egui).

Bevy also doesn't need to redraw every N milliseconds or anything. You can create a custom game loop and redraw only when needed, whether that's 60fps or only on window event.

There's also no reason a Bevy app couldn't be embedded within a larger application. You can create the Bevy app when needed, render to a render target rather than the window surface, then manually draw that where you need to in your egui app. This also means you can stop the app, or at least the game loop, when it's not needed anymore.

Use Bevy with egui, just disable needless features. You'll get performance hit until there is an actual complete game inside.

I haven't tried using a GUI library for this. But it is possible (and relatively easy) to build for Android using rust.

I found this tool called "x build" that works basically out of the box. It was a bit tricky to set up the release build, but got it working too.

I made a small App using winit+wgpu and it seems to work. Win it also has touchscreen-specific events.

Iced does use winit+wgpu, so if they are listening to the touchscreen events, it should work for Android. Haven't tested it though.

Damn, I was hoping it would be an announcement about making it mobile ready, but this will do too. Being able to easily write mobile apps in Rust is the dream...

Depends on whether those changes break the formatting.

If they add flatpak support it would be so good.

I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing.

Maybe. My point is that unless you want to, for example, have a reference that you switch between which object it references, I think you would be fine with using the ref-counted reference. With eventual optimization done via compiler when it's sure the code won't be trying to access the object after it got deleted. But even if I'm wrong, there could be another way to get a pure reference

This proposal as I understand it is an attempt at making reference-counting more ergonomic.

Yes, and IMO by using Handle for that it breaks a pattern. Rust keeps * and & for speaking about values and memory management (I want data vs I want reference). Using a trait for ref-counted referencing adds another layer. So suddenly we have *, & and ::Handle(). You see what I'm getting at?

I don't know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing.

References are just pointers, they don't have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic.

What's the use-case for &Arc? Modifying an Arc object in outer scope?

To me, this handle trait sounds a lot like "reference-counted reference". When there already exists a pure "reference" in the language

How do I now actually get a &Arc? Without implicitly cloning?

& is such a fundamental part of the syntax, I really don't think it's meaning should be muddled.

I mean, keep the ref-counting. Just from the syntax perspective. Aligning with the example in the post: & before Arc would increment reference count, before a Mutex would reference the same object as it does now

The semantics of something like Handle does add a lot of clarity for me. I had just written an app using tokio and arc and the clones always felt off.

Without ref counting it is hard to know when to free or safely change a value with multiple consumers

Why not just expand meaning of &?

let l_before = &v1;

If a project is functional and mostly complete, is it an issue?

How can a language formatter be considered complete is the language it is targeting keeps getting updates?

I considered that (talking about clang-format here, not rustfmt), but there are cases where some files are formatted while others are not, such that, you can't go around formatting the whole project to your liking and then expect it to return to the same, once you go back to the project's configuration, for committing.

Here, the difference between clang-format and rustfmt comes up, because unlike clang-format, which has the required configurations, rustfmt does not have the configuration I require. The little part that is there, has not been fully implemented and a lot of the configuration hasn't even been defined.
Meaning that even if I were to put the time into contributing to rustfmt, I will soon reach a point where I will have to be setting up groundwork. That's where I will fail, because I am too new to Rust to be able to define formatting for undecided conditions, many of which I don't even know about yet.

Ahh, I see. Well okay, you don't have to like it. But that is not the problem of the default configuration, but the problem of those who accept it as the formatting in the project. You don't like what the KDE code formatting project does, and that's the issue. Working in teams it will obviously happen at some point that you don't like what the team accepted as formatting. This is not a specific issue with KDE or rustfmt.

BTW, wouldn't it work to have your personal rustfmt configuration that you like and work with and when you are done and want to git push, it would automatically reformat with rustfmt using the teams formatting? I personally don't work in teams, so no idea if this is a viable option to do if you really dislike what they use.

I mean the clang-format in KDE code.
I work with it, I don't like it, but I like KDE, so I put up with the formatting that I don't like.

Is this a typo? What do you mean by KDE formatting?

Neither do I, but I don't like the KDE formatting either, so it doesn't really matter as much.

If a project is functional and mostly complete, is it an issue?

I get the sentiment, but if you have 200+ open PRs by dozens of authors, the community obviously doesn't agree that is compete.

They do. Linus just doesn't like the default settings.