1
submitted 3 months ago* (last edited 3 months ago) by [email protected] to c/[email protected]

I hardcoded size and position values in Sway to hide it outside the screen.

Here they are for 1366x768:

for_window [app_id="dev.zed.Zed"] floating enable, \
                                    resize set width 1387 px, \
                                    resize set height 830 px, \
                                    move position -15 -75


bindsym $mod+2 workspace number 2, \
    for_window [app_id="dev.zed.Zed"] floating enable, \
                                        resize set width 1387 px, \
                                        resize set height 810 px, \
                                        move position -8 -60

This won't work unless I keep Zed in workspace 2 though.

If I don't re-run the command when switching workspaces Zed changes position and breaks my hack. There should be a better solution to the workspace problem.

Edit: I know I input different values in both cases, but it doesn't work otherwise.

10
submitted 5 months ago* (last edited 5 months ago) by [email protected] to c/[email protected]

I shaved off 10 MiB from my binary in 2 hours!

I made a program using Macroquad, then I built it in release mode, the binary was 63 MiB in size.

So I used cargo vendor to have a better look at Macroquad and one of its dependencies, glam.

I then started to delete code, like, lots and lots of code(about 30_000 lines of code); none of it affected my main project, some of it became 'dead_code' just by removing the pub keyword.

The result is that my project was unaffected and the binary went down to 52 MiB.

Is there a way to automate removal of unneeded elements from dependencies? This is potentially huge.

EDIT: I FIGURED IT OUT!!!

My mistake was measuring the size of "target/release", I discovered that that folder contains many "unnecessary" files, like "deps", which greatly bloat the folder'r size, the actual size of my binary is 864K.

I am so relieved.

7
submitted 7 months ago* (last edited 7 months ago) by [email protected] to c/[email protected]

How safe it is to upgrade to Pop!_OS 24.04 by manually editing /etc/apt/sources.list (or whatever it was).

I tried doing it and running sudo apt update, and nothing suspicious seemed to appear. I used the Ubuntu 24.04 repos.

It is worth nothing that I have ran sudo apt remove with the --allow-remove-essential flag; I did it long ago to remove some "bloat".

I want to upgrade; 22.04 is so old Debian stable is more up-to-date. There are also bugs with Sway and Mangohud that I am interested in getting rid of.

I am uninterested in the Rust desktop.

17
submitted 8 months ago* (last edited 8 months ago) by [email protected] to c/[email protected]

It might be lack of sleep, but I can't figure this out.

I have a Label, and I want its text to be red when it represents an error, and I want it be green when it represent "good to go".

I found search result for C and maybe a solution for Python, but nothing for Rust.

I tried manually setting the css-classes property and running queue_draw(); it didn't work.

I can have a gtk::Box or a Frame that I place where the Label should go, then declare two Labels, and use set_child() to switch between them, but that seems like an ugly solution.

Do you have a solution?

SOLVED:

I have to add a "." before declaring a CSS "thing" for it to be considered a class.

Ex:

.overlay {
        background: rgba(60, 60, 60, 1);
        font-size: 25px;
}

instead of:

overlay {
        background: rgba(60, 60, 60, 1);
        font-size: 25px;)
}

Just use label.add_css_class(), label.remove_css_class() or label.set_css_classes() and make sure to properly load your CSS style sheets,

Source: the comment of [email protected]

13
submitted 9 months ago by [email protected] to c/[email protected]

I was using Iced as a dependency, but wanted to tweak its source code for some reason, so I jumped into the folder where cargo downloads dependencies, and went into iced_wgpu 13.5 (I think that's the version).

I could make a change, then run

cargo clean -p iced_wgpu && cargo check

in my other project for instant feedback, yet it took rust_analyzer at least 5 whole minutes to stop hallucinating.

Can I disable some functionality of rust_analyzer? I only use it for jump-to-definition, linting and syntax highlighting; I don't even use autocomplete.

Setup:

  • Desktop that thermally throttles only when both the IGPU and the CPU are under full load, and is cool otherwise.

  • CPU: Intel I5-7500

  • RAM: 8 GiB DDR-4

  • Editor: NVIM v0.11.0-dev | Build type: RelWithDebInfo | LuaJIT 2.1.0-beta3 (I had the same issue with other versions as well).

TLDR

What can I disable in rust_analyzer to boost performance while maintaining jump-to-definition, linting and syntax-highlighting, or what can I do to boost rust_analyzer for big projects in general?

8
submitted 10 months ago by [email protected] to c/[email protected]

Another crazy idea I share with this website.

I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.

I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe?", but the truth is: unsafe is not ergonomic, and so is Refcell<T> so after thinking for a bit, I came up with this pattern:

let mut enemies = if cfg!(debug_assertions) {
    // We use `expect()` in debug mode as a layer of safety in order
    // to detect any possibility of undefined bahavior.
    enemies.expect("*message*");
    } else {
    // SAFETY: The `if` statement (if self.body.overlaps...) must
    // run only once, and it is the only thing that can make
    // `self.enemies == None`.
    unsafe { enemies.unwrap_unchecked() }
};

You can also use the same pattern to create a RefCell<T> clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.

This has several benefits:

1 - No performance drawbacks, the compiler optimizes away the if statement if opt-level is 1 or more. (source: Compiler Explorer)

2 - It's as safe as expect() for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior If it doesn't crash.

You can also wrap it in a "safe" API for convenience:

// The 'U' stands for 'unsafe'.
pub trait UnwrapUExt {
    type Target;

    fn unwrap_u(self) -> Self::Target;
}

impl<T> UnwrapUExt for Option<T> {
    type Target = T;

    fn unwrap_u(self) -> Self::Target {
        if cfg!(debug_assertions) {
            self.unwrap()
        } else {
            unsafe { self.unwrap_unchecked() }
        }
    }
}

I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context() to acquire a static mut variable.

Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?

Conclusion: we shouldn't fear unsafe even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.

1
OpenGL 1.5 support? (infosec.pub)
submitted 11 months ago* (last edited 11 months ago) by [email protected] to c/[email protected]

I know the title looks insane, but hear me out.

I wanted to make a game, specifically an isometric 2.5D RPG game, nothing that fancy.

So I decided to write it in Rust because I... like Enums, or something, and I had already finished the concurrency chapter, so I should be able to hang on.

Bevy seemed like the most complete engine out there, if overkill for my use case, but it's presumably so modular I could de-bloat it adequately, But...

Someone I know has a laptop; it is old.

It is not super old, a Toshiba Portege R700 with a locked BIOS which took me 3 days to trick its Windows 10 boot loader into booting Debian, and accidentally, yet irresponsibly, broke Windows and installed Grub.

There is no reason the thing shouldn't be able to run my hypothetical game. I've personally seen it LANning Sven Co-Op (Half-Life Co-Op) not long ago; the beast could maintain 60FPS for a solid few minutes, before overheating and dropping to 5, but it should hold on better now that I installed GNU/Linux.

So I, just to make sure, ran the command that exposes the OpenGL version used by Mesa, and... Open GL (ES?) 1.5? I surely, need a plan.

I noticed this issue with many indies. Many would-run-on-a-2005-thinkpad games sacrifice this untapped market for features they never use, or worse, go against the artistic vision.

So, since Bevy is modular, can I, a humble would-be-intern, write a rendering backend for the 2003 specification, but not before learning what a rendering backend is?

Or can I, a seasoned searcher, find a premade solution solution for Bevy or any other Rust engine, made to use the 2003 spec, or even the 1992 1.0 spec?

Or would it be worthwhile, to construct an engine of mine?

Edit: Or can I, a man of determination, write an FFI for an existing C solution?

22
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]

I have written a calculator in Rust and libcosmic, the design is copied from gnome-calculator; I discovered 2 things:

  1. I don't like working on UIs.
  2. I have no idea how to transform

cosmic::widget::button::Builder

to

cosmic::widget::Button;

this code would be so much cleaner if I could return a button::standard() from a function.

The source code.

[-] [email protected] 14 points 1 year ago* (last edited 1 year ago)

My emotions just stopped, so I can now think straight.

There are really only 2 changes that - in my eyes - should be made:

  • 8 space-long, hard tabs.
  • 80 character limit instead of 100.

I don't think a tool like rustfmt can affect most of the original guidelines, and it's generally compatible with the OG style by default.

Edit: I - surprisingly - never actually used rustfmt, so I will go now and test before I say something stupid.

Edit II: I just found this on their repo:

Rustfmt is designed to be very configurable.

Edit III: I tested rustfmt with:

hard_tabs = true

max_width = 80

It's great!

38
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

I am in love with this awsome document; I love its guidelines, and coding conventions.

However, when Rust was introduced into the kernel, they butchered these beautiful guidelines, I know it's hard to look at such heretic actions, but you have to see this:

The default settings of rustfmt are used. This means the idiomatic Rust style is followed. For instance, 4 spaces are used for indentation rather than tabs.

How can this even relate to the ideology of the first document? I am deeply saddened by these new rules.

I know this is "The Rust experiment", but this must be fixed before it's too late! This has to reach someone.

A counter-argument might be:

The code should be formatted using rustfmt. In this way, a person contributing from time to time to the kernel does not need to learn and remember one more style guide. More importantly, reviewers and maintainers do not need to spend time pointing out style issues anymore, and thus less patch roundtrips may be needed to land a change.

And to that I say that rustfmt is configurable per project, and if it isn't, then it has to be. Doesn't something like .editorconfig exist?

Edit: I think I read enough comments to come up with a conclusion.

At first, forcing another language's code style upon another sounds backwards, but both styles are actually more similar than I originally though, the kernel's C style is just rustfmt’s default with:

  • 80 character line.
  • 8-space hard tabs.
  • Indentation limited to 3.
  • Short local-variable names.
  • Having function length scale negatively with complexity.

The part about switch statements doesn't apply as Rust replaced them with match.*

The part about function brackets on new lines doesn't apply because Rust does have nested functions.

The bad part about bracket-less if statements doesn't apply as Rust doesn't support such anti-features.

The part about editor cruft is probably solved in this day & age.

The rest are either forced by the borrow checker, made obsolete by the great type system, or are just C exclusive issues that are unique to C.

I left out some parts of the standard that I do not understand.

This all turned up to be an indentation and line-size argument. Embarrassing!

*: I experimented with not-indenting the arms of the root match expression, it's surprisingly very good for simple match expressions, and feels very much like a switch, though I am not confident in recommending to people. Example:

match x {
5 => foo(),
3 => bar(),
1 => match baz(x) {
	Ok(_) => foo2(),
	Err(e) => match maybe(e) {
		Ok(_) => bar2(),
		_ => panic!(),
		}
	}
_ => panic!(),
}

[-] [email protected] 10 points 1 year ago

w-what... 2 days was a looong time of not watching news, apparently.

What happened?

[-] [email protected] 13 points 1 year ago* (last edited 1 year ago)

Didn't eat it, have to wait for sunset.

Probably tastes the same as other cheap options, they rarely differ in taste.

Edit: I am really bad at tasting things, but I don't think it tasted different from what I expected.

390
submitted 1 year ago by [email protected] to c/[email protected]
[-] [email protected] 16 points 1 year ago* (last edited 1 year ago)

These posts get tens of likes but no comments, because nobody knows what to say anymore. The situation is clear, the motives have been revealed and the details are trivial, and pointless.

Should we stop talking, the situation will only decline, but should we speak the declination will happen slower.

Edit: I wrote a comment that looks pretty cool & I am somewhat proud of it, actually

[-] [email protected] 12 points 1 year ago

English people on their way to ruin the meaning of every word.

[-] [email protected] 14 points 1 year ago

The KDE Plasma 6 open-source desktop environment

Makes me wonder, are there closed-source desktop environments for Linux?

[-] [email protected] 13 points 1 year ago* (last edited 1 year ago)

Stop revealing our plans! Our police force can hardly arrest protestors fast enough!

-Most Governments

[-] [email protected] 13 points 1 year ago* (last edited 1 year ago)

(I ~~didn't read~~ skimped through the article)

Just make games with older graphics; it's cheaper, reduces visual bloat, and encourages player imagination to fill in the gaps, and investing xxx million dollars in a video game is dumb.

[-] [email protected] 10 points 1 year ago

I don't think there's a way to remove it, even though there are 3 different ways of accessing that menu.

[-] [email protected] 39 points 1 year ago

Being an adult has nothing to do with age, I saw 30 year-old children and 13 year-old men.

8
submitted 2 years ago by [email protected] to c/[email protected]

I have a huge library of game EXEs on my computer, but they run at a 4:3 aspect ratio as they're old, Proton/Proton-GE/WINE-GE keep the aspect ratio and place black bars left and right, which is desireble, unlike wine who stocks them to the left side of the screen.

[-] [email protected] 15 points 2 years ago

I didn't mean we should stop improving, what I meant is we should focus more on the efficiency and less on the raw power.

11
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]

I might clean under a non-functioning button after this.

I used an old charging cable with a broken micro USB port.

view more: next ›

Doods

0 post score
0 comment score
joined 2 years ago