there is, it’s called “releases” and it’s like 2 clicks to download an executable, it’s not a github issue at all, and github isn’t meant to be where you get your executables anyways
I still do sometimes. Wish they release a build so I don’t have to download all the dependencies and learn how to use a new program to build the damn thing
Probably would fall into scope of a compositer in Wayland, rather than the protocol. I suspect it originated with old CRT displays. Sometimes they can appear scan diagonally.
Even without that usecase, I think it’s great to have around in order to support novel displays and display-like devices.
The best thing you can do with that shithole of a site is ignore it as best as possible. Don’t give them any engagement. They’re no better than rage-baiters on Reddit and TikTok
I have run into this recently on several non-US, non-news sites. I have actually never run into it on US local news sites, so I don’t know what you’re on about.
Exactly. For every level of abstraction, the abstractor is the high level and the abstractee is the lower level. Those aren’t real words perhaps, but you get what I’m saying. It’s all relative along the chain of abstraction.
Is it a chain though? I think it’s more of a branching network that (almost?) always is stopped at quantum physics and it’s theories or some form philosophy.
It’s not really abstraction though. It is more like syntactic sugar. In stead of 1000111011 you say ADD, but it is still the exact same thing. There is no functional, prgrammatical benefit of one over the other. It’s just that asm is readable by humans.
At least thats as far as I understand asm. I haven’t gone beyond NandToTetris
I would argue they don’t know what that means really. Assembly is pretty much a mapping of words to machine code. It’s just a way to make machine code easier to read. It doesn’t actually change how it works.
A compiler re-arranges and modifies things so what you write isn’t the same as the final program that is created. With assembly it is. It’s not really an abstraction, but a translation. It doesn’t move you further from the machine, it only makes it so you’re speaking the same language.
Writing good comments is an art form, and beginner programmers often struggle with it. They know comments mostly from their text books, where the comments explain what is happening to someone who doesn’t yet know programming, and nobody has told them yet that that is not at all a useful commenting style outside of education. So that’s how they use them. It usually ends up making the code harder to read, not easier.
Later on, programmers will need to learn a few rules about comments, like:
Assume that whoever reads your code knows the programming language, the platform and the problem domain at least in general terms. You are not writing a teaching aid, you are writing presumably useful software.
Don’t comment the obvious. (Aside from documentation comments for function/method/class signatures)
Don’t comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments. Reserve the “what” style comments for where that just isn’t possible.
Do comment the why. Tell the reader about your intentions and about big-picture issues. If an if-statement is hard to parse, write a corresponding if clause in plain English on top of it.
In some cases, comment the “why not”, to keep maintenance programmers from falling in the same trap you already found.
Comments should be part of code review, having at least two pairs of eyes on comments is crucial. Something that’s obvious to one person maybe isn’t so obvious to another. Writing good comments is as hard or harder than writing good code, so having it checked for mistakes and quality is a must
Comments aren’t the actual documentation and aren’t a reason not to write documentation to go along with your code. Often I see larger projects where each class and function is documented in comments, but the big picture and the how and why of the overall structure is completely missing. Remember that in the real world you often have a lot of folk that need to understand how the code works, who aren’t programmers themselves. They can’t read the code or don’t have access to the code. Writing documentation is still important.
Please for the love of god when you change code, check if the comments need to be updated as well. Not just around the immediate area, but also the entire file/class and related files. I’ve worked on large codebases before with a high wtf factor and having the code do something different to or even opposite the comments is a nightmare. I’d rather have no comments than wrong comments.
This is a notoriously bad book. If you read the part about comments (which I don’t know about, and am willing to accept is good) make sure to skip everything else because Robert Martin is a fraud.
I would argue that if an if statement is hard to parse, replace the entire condition with simpler to read (but way more specific) variables that you assign values (the original condition expression) in the line above. No need for comments in that case
In this day and age of source control I don’t think this is fully necessary. If you want to know the why, you can look into the commit history and see which ticket is connected to it. There you might even see the discussions around the ticket as well. But this requires good source control discipline.
Why not put the “why” in a comment and save people the job of dredging through old commits and tickets to figure out what the code is for? I’d thank someone for saving me the hassle.
Going back to the original ticket can offer far more info than what any “why” comment can give. You can see how old it is, if there are any connected tickets, who were involved with it, step by step instructions how to reproduce the bug, etc.
In any modern IDE “dredging through old commits” means clicking a single button to see who last changed the line. From there it often makes sense to go look at the PR to see a higher level of what was changed. You cannot include all of that context in a single comment.
Don’t comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments.
Over and over and over again in my experience this just doesn’t work. Readable code does not substitute for comments about what the code should be doing.
We currently have a student for training and had her learn Rust. After two weeks or so, she told me that she had a really hard time finding anything about Rust, and it became clear that she was really confused and thought Rust was some fringe technology that no one uses.
And yeah, no, search engines just got obliterated by LLM spam since the last time she had to learn a new technology. Seriously, I remember getting better results about Rust back in 2018, when it was really still relatively fringe…
But then you need to know enough about the topic already to know what is stable and what changes with newer versions.
Like, the “web dev boot camp” course I got from UDemy a few years ago as a guide for building a web dev high school course: I recently went back to to look something up, and the whole thing has been completely redone start to finish. Makes sense, considering that it’s updated to the newest versions of Bootstrap and other libraries (and who knows what else).
I know nothing about Rust, but I would assume there are at least some libraries that have major new versions in the last couple of years which might change best practices somehow? idk. But the harder part is not knowing what you don’t know.
One search that was memorable to me was looking for dimensional information on a T-slot. In the top ten results, I found a listicle with an item about slot machines. LLM spam and Google’s relentless bullshit have poisoned the internet.
I’ve been into computers for over 20 years and I couldn’t tell you what uses rust. I am aware of it, but I am completely unaware of how narrow or broadly it is used. I keep forgetting people aren’t talking about the game.
I mean, to name a few projects off the top of my head:
Firefox
Android is migrating some of their internals.
The Linux kernel, Google Chrome, Thunderbird are preparing to use Rust.
Many Python programs now have Rust in there, because of the PyCrypto library.
Fish shell is in the middle of a RiiR.
I don’t feel like there’s a ton of big, mature projects yet, because of how relatively young Rust still is, but performance-critical or embedded software will be strongly considering Rust in the future.
And like C, Rust can be used to create libraries which can be called from practically any other programming language. I expect that to give it significant growth in the future.
Frankly, I do most of my searching these days directly on std.rs and docs.rs . But yeah, those are usually better as a reference than for learning.
You can look through lib.rs and awesome-rust.com , if you’re searching for a specific library.
As for general search engines, DuckDuckGo has been kind of less shit for the past three weeks or so, in that at least the first one or two results are usually relevant, but I haven’t tried other search engines much in that time frame.
Another tip is to make use Clippy. Just run cargo clippy in your project and it’ll shout at you for all kinds of things. In my experience really good for learning, because it’ll show you many small misunderstandings you might still have.
There are two common types of laser printers. Those that have special paper that react to heat, such as receipt printers, would fit the description.
The other laser printers… Hm, I don’t think your description is accurate either. It’s more that the laser electrically charges ink particles so that they jump on to a separate roller that gets rolled on to the paper.
I am not aware of any receipt printers using lasers - thermal printers have an array of resistors that get hot when necessary. I know how a laser printer works and it is hard to explain in 12 or so words. Inkjets are way easier, you can just say “squirt squirt oops”. Anyway…
A photosensitive drum gets a negative electrostatic charge.
A laser shining through a rotating prism scans lines across the drum’s surface. This removes charge from parts of the drum that should not be covered in toner.
A high-voltage corona wire inside the toner reservoir charges an amount of toner positively.
The charged drum rotates past the corona wire, getting covered in toner where its negative charge remains.
Paper is pushed against the drum and the powdery toner is transferred to it.
The paper continues into a fuser, a little oven where a heating element briefly makes the toner so hot that it melts, its powder particles making a permanent bond among themselves and with the paper. (The heater is usually stationary and heats the paper from below. The fuser drum that pushes paper against the heater can get sticky and pick up some of the toner, making images repeat down the page. This is the most common failure mode that cannot be resolved through regular maintenance such as replacing the toner cartridge and printing cleaning pages. However, almost all laser printers have a cheap fuser module or its drum available so it is usually worth replacing.)
It’s an accurate description of laser printers. The “powder” in the description are small plastic flakes (toner), and the paper is baked so that powder melts into it.
Receipt printers have no additional consumables beyond the paper. The heat itself is all the paper needs.
the search in amazon is so bad that you sometimes need high to low: some searches get you so much cheap unrelated trash, you have to sort high to low, and page down so you find the actual cheapest match quicker.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.