51–60 of 63 posts
Earlier quoted context omitted.
there's only a barely working, undocumented backend for LLVM on the z80. You could probably do this with mrustc.
The Game Boy doesn't use a Z80 though. It's based on a SM83 core, an obscure Sharp design.
Earlier quoted context omitted.
I enforce formatters wherever possible after working on codebases with 20+ years of people imposing their own unique opinion on where spaces and braces should go. Worse, arguing about what the spacing should be, and making noisy diffs because people change previous peoples styling. The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact b…
There is no reason why each of us can't have the formatted according to one's taste (=what works best), instead of this "communism". It's just a matter of IDE support that is lacking. The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.
Earlier quoted context omitted.
There is no reason why each of us can't have the formatted according to one's taste (=what works best), instead of this "communism". It's just a matter of IDE support that is lacking. The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.
This is bad idea, so you want your code to not looks like what's in the repo?
Earlier quoted context omitted.
I wouldn't know, I hardly ever see such posts about other languages. Weird, isn't it, that only rust gets that treatment?
As of writing this the font page has the following: * Slacktyping: I'm typing when you're typing (2018) * The world's worst Linux kernel module * Show HN: Go playground powered by WASM that runs in the browser * Elk: A low footprint JavaScript engine for embedded systems
We can reasonably assume the Go one is written in Go, but the point here is the playground, not the fact that somebody did something in Go.
The slacktyping and kernel module don't mention language at all, they're about some typing... thing and an example of how not to write a kernel module.
The javascript one obviously implements javascript, but there's no mention what language it is implemented in.
Do you see the difference here? These are all about interesting _projects_, not about some implementation detail, being that it is written in language XXX.
A rust port for the gameboy, that would have been impressive...
There's some ongoing work on a LLVM whole-program backend for the MOS 6502, which can already compile some Rust code (discussed https://news.ycombinator.com/item?id=28581812 ). If that's successful (it does require lots of new optimization passes to match the effectiveness of hand-written code), it would be quite easy to have a backend for the Z80 as well.
Earlier quoted context omitted.
There is no reason why each of us can't have the formatted according to one's taste (=what works best), instead of this "communism". It's just a matter of IDE support that is lacking. The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.
This is bad idea, so you want your code to not looks like what's in the repo?
Earlier quoted context omitted.
Yep, and everyone still uses all the stoftware written in C/++, and the stuff written in ruby/(and soon go/rust/...) doesn't even run anymore.
Getting old, forgotten C/C++ code running can be a job. It's really a matter of how well written the make files were and if one still has the original tool chain sitting around. C/++ code written for a paid, closed-source compiler can require a lot of changes to get running under something like GCC. Not sure how Ruby's backwards compatibility is, since I don't use it, but I have to imagine it's like most other script…
I'm saying that, every time, there is a "${old-existing-thing} in ${current-language-of-the-day}", people upvote it, start it on github, and continue using the old one, written in c/c++.
A few months will go buy, and people will continue using mgba/visualboy/vbam or whatever was popular before.
I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).
I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).
For those looking to see an example of the match expressions: https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff... This process of matching on opcode and doing a marginally different version of the same basic few operations on one of a set of registers is something that is _much_ easier to do when you're able to see all the opcodes and activities in a densely packed set of lines like this. (The start of th…
Declarative macros might be useful here, at least to cut down on the mindless repetition somewhat. These are fairly hygienic (a technical term meaning that if variable names in the macro are the same as variable names in the code using the macro, this doesn't make them the same variable) and so pretty safe to use but limited.
Procedural macros can do almost anything, they're Rust code that runs inside the compiler when your program is compiled, so e.g. they can have arbitrarily complicated behaviour including completely breaking compilation. You could definitely fix this with proc macros, but, that's not necessarily a good idea.