@CoreFusionX I think as long as you don't compose multiple euler angle rotations you shouldn't have a problem with gimbal lock. I.e. you can always decompose any rotation into a sane set of euler angles in a given coordinate system

But you're right, just use quaternions :P They're faster anyways because of less trigonometric operations

@retoor No, I'm just procrastinating and reading dR all the time :P

@retoor I've tried claude a little online and it's output seems a lot better than chatgpt. You can ask it stuff about LLVM passes and it can tell you the exact source file where something is implemented, pretty cool stuff!

@AlgoRythm You really underestimate how autistic and knowledgable the Rust user base is. I have no idea where the idea come from that all Rust users are dumb script kiddies because it's actually quite the opposite, there are so many incredibly smart people (and it makes sense, because just like OCaml or Haskell, Rust is complex enough that anybody doing anything serious *has* to know what their doing :P Script kiddies can't)

The real issue with adding Rust is just the fact that you're doing new development, and especially if you replace something, you'll inevitably add bugs that need to be ironed out over time

Linux isn't being rewritten in Rust btw. It's for new subsystems or subsystems which badly need fixing anyways. And for anything security related I see it as a win

@Lensflare Oh come on, Eclipse is fineee

Still use it from time to time for Minecraft modding!

There's a reason chatgpt plus is $20 and pro is $250

Those data centers ain't cheap! All that free AI usage was subsidized by investors burning billions of dollars for customer acquisition

Now they want to actually make some of that money back :P

@D-4got10-01 I don't agree with canonical's choice either. But if you read some of the comment sections on different news sites, hoo boy, are there some mentally retarded rust haters lol

@Liebranca If the question is "is accessing an allocation on the stack or heap faster?" the answer is "they're both just memory, so it doesn't matter (ignoring that the stack region might already be in your caches)"

If the question is "is *allocating* faster on stack or heap?" then stack is magnitudes faster

:P

@whimsical How am I wrong? o.O

The hate against uutils is retarded

But ubuntu replacing battle tested gnu utils with alpha uutils is also really retarded

@whimsical Oh, stack allocation by far

@Liebranca Damn, pretty cool!

Also first time seeing someone still using perl :P

@Liebranca How are you dealing with the complexities of x86 though!??

I mean you also have to follow some ABI when doing function calls, and you also have to deal with x86 memory operands which can be as complex as `[rbx + rax * 4 + 0x1337]` (and should be as complex for performance!), you have to implement register allocation, etc.

I'm actually curious

@Liebranca I agree with you that I don't have to follow any specific specification (which to be fair i'm not because of complexity :P)

But do note that I'm writing a real compiler with an x86_64 machine code backend. I legitimately have to put things into physical registers or on the stack for this to work, and I'd like to not make something *completely* shitty so I'd also like to support some pretty important optimizations like folding ptr calculations into x86 memory operands

I've written a stack machine based compiler before and that was fine-ish (still pretty complex :P) but for x86 that just won't cut it

@AlgoRythm Can zig do dynamic allocations in comptime?

Understandable. Prostate massages are allegedly pretty pleasurable

Yeah C++ is crazy powerful -- and arcane :P

@Liebranca Well, I have to follow *some* ABI

And that ABI, whatever it is, needs to account for passing values via registers and via memory, and via memory if we don't have enough registers left, and via registers if it's a small enough struct so we don't nuke performance

And it has to deal with returning stuff in both registers and memory

Ya see the issue? :P

@Liebranca For example I've given up on actually implementing full SYSV abi, because it allows passing multiple values packed in a single physical register. Now all downstream logic has to be able to cope with that: A physical register can now actually be multiple subregisters and reg alloc has to respect that, the illusion that each SSA reg can be stored in a pyhsical register is broken (I already disallow aggregates in ssa regs, also for complexity reasons)...

It's a really deep rabbit hole

@Liebranca I mostly struggle with the enormous complexity of all the little moving parts which have to integrate

For example ABI: Just the amd64 sysv rules are complex enough on their own: Structs get recursively split up into 8 byte chunks then assigned registers or stack space accordingly depending on a bunch of subrules. But ultimately let's say a struct is passed on the stack, my backend should be able to produce e.g. `add [rbp+16], 8` -- directly interacting with the param passed on the stack instead of load/add/store

Obviously that's not impossible to implement, and I think my current plan should work out. But you do get what I mean? That "value" has to snake through 2 ssa (+1 non ssa) IRs, through instruction selection, through register allocation and then I still have to be able to make that connection

I'm making progress, but designing something this large and interconnected is definitely a challenge

@Liebranca Ehhhhh not so sure about that :P

Why do you always complain

No

@BordedDev I mean it parses json via the type system from a generic parameter, does it not? Either way this is cursed lol

@AlgoRythm Obligatory Rust plug :P

#[derive(Deserialize)]

struct Foo {

#[serde(rename = "qux")]

pub is_qux: bool,

#[serde(default)]

pub list: Vec<Bar>,

}

let x = serde_json::from_str::<Foo>("...");

One of the most beautiful things i've ever used. It's so flexible and compatible with pluggable formats

json parsing via const generics.... yeaaaaa....

@antigermanist I didn't mean to make fun of you. Actually just curious

I wonder why you always say IA instead of AI. Is it that way around in french or something? Kinda like how NATO is OTAN in french

Understandable to be honest

@Wisecrack But if its incremented on a timer, how do you make sure who ever is writing is finished by the time another thread can read it?