With some help from bjorn3 this was reasonably straightforward. I think the PRs are good templates for of someone wanted to work on a real compiler and implement further SIMD functionality. This issue lists some missing intrinsics
I needed #Rust bindings for an app to interact with #feedbackd to submit #haptic feedback. Here's the generated bindings for libfeedback in case someone else needs it too:
Breakthrough: I wrote a program that prints a line of text!
So what's the point?
Program written in #rust, cross compiled on #debian, linked with #vlink to a TOS executable {on Windows), put into a disk image on debian and executed on a real ST via a #gotek floppy emulator with #flashfloppy firmware.
Preview of what I have been working on recently. The core of this crate is a mere two traits. The crate will ship with a number of parsers and combinators, none of which rely on anything not exposed to downstream users.
I've attached a real-world situation, taken verbatim from the test suite. Parsing integers isn't as efficient as it could be yet, as it's using a naïve method.
Parsing in general compiles to be extremely efficient, and using it is ergonomic.
Once again I get foiled by switching languages. :blobcatfacepalm2:
In Javascript, you have to compare strings with ===, not ==, or else you'll run into type coercion problems, because Javascript thinks 1 == "1" is a totally fine thing to be true. (it's not)
But in Kotlin, === compares identity not equality for strings. But in the JVM, string values are aggressively cached, so === actually does what you want most of the time. Unless your strings come from weird places, like JNI code. Then you get awful non-deterministic behavior that's incredibly hard to debug, but it totally goes away when you use the correct comparison operator == for strings.
sigh I'm not really as good at this whole programming thing as I should be by now.
Request for feedback: how would you change this #Rust compiler error? Can you tell what's going on? What the problem is? Do you get a sense of how you might be able to solve it?
Time passes fast as fuck. In my mind it is 1 or 2 years old only 😅. But I started following it a little after they removed the @ symbols I guess.
Well, for me Rihanna and Miley Cyros is extremely new and recent in my head too so... 😅😞. I have no idea what kids listen to these days... But I ramble 🤣
Fresh out the oven, version 0.8.5 of the open source space game #OutFly!
✅ New flashlight
✅ Redesigned HUD, with #Fallout-4-like bars for health/power/O2, and #car-dashboard-like warning lights
✅ New, well-balanced cruising vehicle
✅ Implemented power drain
✅ Much improved texture for #Jupiter
Btw, see how the hat of the #pizza chef doesn't cast a shadow? Because it ain't real! Just an #AR illusion, which you can toggle with <TAB> :)
I’ve been using new shiny languages for a while now. #Rust, #Zig and #Swift in particular.
I love Rust’s tooling, Swift’s syntax, and Zig’s philosophy, but I feel like good old #Cpp is still the goat.
Yeah, the syntax can get out of hand really quickly.
Yeah, the STL is bloated.
Yeah, the tooling ecosystem is a mess.
But at the end of the day, with a good style guide and some discipline, it can check most of my boxes.
But learning new languages is always fun so I’m still doing it 😬
@diyelectromusic, since you're into embedded tech and microcontrollers, you may appreciate this one.
It's a Real-time Operating System kernel I wrote in C and Assembly for AVR chips. My intent was to learn about how operating systems interface with hardware.
I'd like to rewrite it with #Rust and finish the task scheduler.
So now that -Zcheck-cfg is stabilized and enabled by default, there's no way to tell the compiler about custom cfgs other than a build script?
I routinely use a custom cfg for rustdoc so that I can use nightly features when publishing (both with docs.rs and CI). #[cfg(coverage)] is also used in some places.
Apparently spurious warnings are extremely wide-spread, so I'm not clear on why this was stabilized with such a glaring hole in it.
I came across this article the other day, titled “Why Rust cannot replace C++”.
I feel that the author completely fails to understand the opposing argument. The article claims that with “new” C++ features like smart pointers, you can write safe code in C++, therefore Rust is unnecessary.
But I don’t want a language where I can write safe code, I want a language where I must write safe code.
I know that such a file has to exist because emojos.in works correctly for void.rehab but I don't know enough #Rust to figure out where they're getting the path out of the server instance.
I can't deal with languages with optional semicolons! I like languages without semicolons, but when they're optional, especially if they feel "C-like", I always end up adding semicolons to some lines even when I try to write in a semicolon-less style. I'm writing some #kotlin now and I decided to just use semicolons consistently because the alternative is seemingly to use them inconsistently.
Strangely, this isn't an issue I have in #golang. I do have it in #rust however.