WTF Bites
-
@Cursorkeys said in WTF Bites:
Why not submit a PR to fix the issue rather than writing passive-agressive messages for your users?
Go on, try writing PR for GNU Make. I dare you.
Here's a representative file I've just chosen randomly from their repo:
-
@Cursorkeys said in WTF Bites:
Why not submit a PR to fix the issue rather than writing passive-agressive messages for your users?
Go on, try writing PR for GNU Make. I dare you.
Yeah, good luck with that. Assuming they'd even care to fix the problems, there's probably a gazillion backwards compatibility constraints which prevent it.
Here's a representative file I've just chosen randomly from their repo:
Anything specific about that? It looks like C code tends to look.
-
Go on, try writing PR for GNU Make. I dare you.
Well, it starts off interesting, I didn't know you could have function pointers in a union...
union { char *(*func_ptr) (char *output, char **argv, const char *fname); gmk_func_ptr alloc_func_ptr; } fptr;There is a lot of interesting code in this repo, maybe I should Google for a precis on how it all works:
inside GNU make there's essentially a functional programming language that operates on space-separated lists
Actually, it turns out it's just fine the way it is...
-
@Cursorkeys said in WTF Bites:
I didn't know you could have function pointers in a union...
It would be more surprising if you couldn't.
-
It looks like C code tends to look.
And that's exactly what makes it so bad.
-
@Cursorkeys said in WTF Bites:
That doesn't make it better, if a sub-component you're using sucks then it still means your software sucks. Why not submit a PR to fix the issue rather than writing passive-agressive messages for your users?
Meh, I've built programs with gnu make from directories with spaces in. You need to be a bit more careful with your rules, but it totally can work. As long as you avoid advanced things like the resource compiler (
) or make functions that write rules or stuff like that.
-
@dkf Am I missing something or is this a problem that could be solved with quotation marks?
-
@hungrier That's how you get the 90% solution. A few tools are internally a bunch of special snowflakes (like the aforementioned resource compiler) and screw you over if you try. Worse, you can't force in quotes to work around it either; in some places they use the name you give and in others they pass it unquoted through a word splitter (probably as an argument to a subprocess). There's literally no way to fix that without nuking the whole thing from orbit.
-
It looks like C code tends to look.
And that's exactly what makes it so bad.
Of course, but it's not unusually ugly, just as ugly as other C stuff.
-
@Cursorkeys said in WTF Bites:
Why are my build tools emitting excuses
To make you aware that it's GNU Make and not your IDE that sucks. And if something really goes wrong, to give you a heads-up on what the problem might be.
I'm 99% sure he's using MPLAB X, whose IDE does absolutely suck.
-
@Zerosquare said in WTF Bites:
@Cursorkeys said in WTF Bites:
Why are my build tools emitting excuses
To make you aware that it's GNU Make and not your IDE that sucks. And if something really goes wrong, to give you a heads-up on what the problem might be.
I'm 99% sure he's using MPLAB X, whose IDE does absolutely suck.
Yep, MPLAB X. It's a hot mess. It took one whole day to persuade it to see the hardware debugger, and there's a random chance that every time I hit enter it will enable software breakpoints (which means breakpoints don't work). That's only on one machine though, I can hit enter as many times as I like on this one and it doesn't do that.
And the new ICD 4 doesn't actually work with most of the chips Microchip make, so I'm having to use a crusty Real ICE instead. The pre-sales bumpf omits the fact that this expensive hockey-puck with fancy RGB lighting is bloody useless.
-
@Zerosquare said in WTF Bites:
@Cursorkeys said in WTF Bites:
Why are my build tools emitting excuses
To make you aware that it's GNU Make and not your IDE that sucks. And if something really goes wrong, to give you a heads-up on what the problem might be.
I'm 99% sure he's using MPLAB X, whose IDE does absolutely suck.
Which makes it even better idea to try shifting blame on someone else.
-
Wow, I didn't expect shitting on C would gather such a negative reaction.
-
I didn't know they released an ICD4. I can't say I'm really surprised it's disappointing, however.
One of the ICD3 advertised features was "faster programming". Yeah.
That must be why the MPLAB 8/ICD2 combo (in a VM, due to lack of drivers for Windows 7 and above) runs decently, while the MPLAB X/ICD3 has a latency of several seconds for doing anything involving the ICD3.
-
Wow, I didn't expect shitting on C would gather such a negative reaction.
Eh, I didn't care enough to downvote. C is fantastic when you need something simple and very powerful but don't want to write assembly.
I started off in my career writing in assembly, when we got the first C compilers it made development so much faster. But there was gnashing of teeth over the inefficiency of not hand-crafting the ASM :)I'm fond of C, but I like writing C# much more if I'm honest. When you don't need pointers and manual memory management then I don't miss them.
-
@Cursorkeys said in WTF Bites:
C is fantastic when you need something simple and very powerful but don't want to write assembly.
Yes. Average C code, on the other hand...
-
-
@TimeBandit things I can do with C# code that I can't do with C code right away:
- Tell whether something is an object or a list/array of objects.
Edit: also, C# usually doesn't contain conditional compilation right in the middle of a function.
-
C# usually doesn't contain conditional compilation right in the middle of a function.
Just because you can doesn't mean you should.
-
@PleegWat that's my point. Average C coders aren't aware they shouldn't do that.
-
Wow, I didn't expect shitting on C would gather such a negative reaction.
Not my downvote.
In fact I was just curious if there was something extra-ordinarily ugly in that you wanted to point out, even for C standards. Wouldn't be too unlikely.
-
@Gąska I worked in game dev for a while. The
I remember most clearly was in a class somewhere, that had a std::vector in it, the vector would be dynamically allocated in the constructor and deleted in the destructor, and never moved during the lifetime of the object. As in, there was no reason not to make the vector a normal member of the class. And when I pointed this out to a few colleagues, they didn't understand what the problem was.
-
@Kian I mean, that's how you Java in C++, right?
-
@Cursorkeys said in WTF Bites:
But there was gnashing of teeth over the inefficiency of not hand-crafting the ASM :)
Those people are idiots. C code is probably better than hand-crafted ASM because people don't know how to be efficient.
-
@TimeBandit things I can do with C# code that I can't do with C code right away:
- Tell whether something is an object or a list/array of objects.
Edit: also, C# usually doesn't contain conditional compilation right in the middle of a function.
Rust does that too!
-
@topspin can confirm. I've seen a Java programmer try his hand at C++ once.
-
@pie_flavor said in WTF Bites:
@TimeBandit things I can do with C# code that I can't do with C code right away:
- Tell whether something is an object or a list/array of objects.
Edit: also, C# usually doesn't contain conditional compilation right in the middle of a function.
Rust does that too!
Huh? I thought you can only do that on per-function basis.
-
Tell whether something is an object or a list/array of objects.
You can do that in PHP
-
@pie_flavor said in WTF Bites:
Those people are idiots. C code is probably better than hand-crafted ASM because people don't know how to be efficient.
It depends a lot on the target architecture, the quality of the compiler, the kind of things you're doing and the expertise of the developer.
For ordinary programs, running on a x64 processor and compiled using a compiler from 2018, it's very probable the compiler will generate better code than a human.
But if you look into specialized domains like games, audio/video processing or embedded development, there are still cases where hand-written assembly can outperform compiler output significantly in performance.
-
@loopback0 said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla yeah...gotta take it in to unbreak whatever broke with my certificates and the domain.
They'll probably just drop it from the domain and rejoin.
It was likely disconnected from the domain for too long.I've had that happen plenty of times, but I've never seen that error message. Usually it's "the trust relationship between this machine and the domain server could not be verified", or something to that effect.
-
@Zerosquare said in WTF Bites:
But if you look into specialized domains like games, audio/video processing or embedded development, there are till cases where hand-written assembly can outperform compiler output significantly in performance.
There aren't. If you said something about exotic platforms with bad tools, I would agree. But there's no situation where a human can write better x86-64 assembly than a compiler. Especially when you consider that inline asm disables many other optimizations.
-
@Tsaukpaetra said in WTF Bites:
@boomzilla said in WTF Bites:
@loopback0 said in WTF Bites:
It was likely disconnected from the domain for too long.
Yeah. Whatever that means.
Under normal operations, a computer joined into an Active Directory Domain has its own password (key). This key regularly gets updated. If the key that the computer has doesn't match that of a servicing domain controller that's authenticating it, shit breaks.
Most likely the comment from @loopback0 meant that the domain controller's keys updated but the laptop's didn't, and broke all the way down.
That's sort of correct, but the "password" isn't one that is normally used except by the system itself.
IMPLBITS
IMPLBITS provides readers with the latest technology trends, web development tips and IT news stories (focusing on cyber security breaches).
gives a few options (PowerShell) to "fix" the trust relationship without actually needing to remove it from and rejoin it to the domain.
-
@anotherusername said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
@boomzilla said in WTF Bites:
@loopback0 said in WTF Bites:
It was likely disconnected from the domain for too long.
Yeah. Whatever that means.
Under normal operations, a computer joined into an Active Directory Domain has its own password (key). This key regularly gets updated. If the key that the computer has doesn't match that of a servicing domain controller that's authenticating it, shit breaks.
Most likely the comment from @loopback0 meant that the domain controller's keys updated but the laptop's didn't, and broke all the way down.
That's sort of correct, but the "password" isn't one that is normally used except by the system itself.
IMPLBITS
IMPLBITS provides readers with the latest technology trends, web development tips and IT news stories (focusing on cyber security breaches).
gives a few options (PowerShell) to "fix" the trust relationship without actually needing to remove it from and rejoin it to the domain.
I've tried his suggestions in the past and it didn't help. Hell, sometimes rejoining doesn't fix it. And once I wasn't even unable to unjoin, that was interesting.
-
@Cursorkeys I hope I never have your problems.
-
@pie_flavor said in WTF Bites:
@TimeBandit things I can do with C# code that I can't do with C code right away:
- Tell whether something is an object or a list/array of objects.
Edit: also, C# usually doesn't contain conditional compilation right in the middle of a function.
Rust does that too!
Huh? I thought you can only do that on per-function basis.
what?
-
@anotherusername said in WTF Bites:
@Cursorkeys I hope I never have your problems.
I have a Windows XP machine still on this domain. It only speaks old SMB and you have to do terrible things to the AD config to get to to work.
If a board member says it's business critical...
-
@pie_flavor you're talking about conditional compilation, aren't you?
-
@pie_flavor you're talking about conditional compilation, aren't you?
No, the other one. Arrays.
Also, yes. You can conditionally compile in the middle of the function. Just put the #[cfg] above the line or block.
-
@pie_flavor oh. So it's not my turn to have no idea what you're talking about. It's pretty clear in Rust when something is a pointer and when it's an array.
-
@pie_flavor oh. So it's not my turn to have no idea what you're talking about. It's pretty clear in Rust when something is a pointer and when it's an array.
Exactly.
-
@pie_flavor well, pretty much every statically typed language in the world has it - that C doesn't is what makes it "special".
-
@Zerosquare said in WTF Bites:
But if you look into specialized domains like games, audio/video processing or embedded development, there are till cases where hand-written assembly can outperform compiler output significantly in performance.
There aren't. If you said something about exotic platforms with bad tools, I would agree. But there's no situation where a human can write better x86-64 assembly than a compiler. Especially when you consider that inline asm disables many other optimizations.
He did say outperform, not "better". I'm sure that by throwing away correctness, hand-crafted assembly can be much faster than the compiled asm.
-
@Zerosquare said in WTF Bites:
But if you look into specialized domains like games, audio/video processing or embedded development, there are till cases where hand-written assembly can outperform compiler output significantly in performance.
There aren't. If you said something about exotic platforms with bad tools, I would agree. But there's no situation where a human can write better x86-64 assembly than a compiler. Especially when you consider that inline asm disables many other optimizations.
He did say outperform, not "better".
I meant better as in outperform. As in take less processor cycles to produce the result of computation. Human-written asm of non-trivial complexity will never beat the compiler, especially as a part of a larger application.
I'm sure that by throwing away correctness, hand-crafted assembly can be much faster than the compiled asm.
If you throw away correctness (and by correctness, I mean correct results, because that's what correctness usually means), you might as well throw entire program in trash.
-
There aren't. If you said something about exotic platforms with bad tools, I would agree. But there's no situation where a human can write better x86-64 assembly than a compiler. Especially when you consider that inline asm disables many other optimizations.
One of my friends cofounded a company that writes middleware for video games (both PC and consoles). I'll let him know that all the time he spent hand-optimizing critical code in assembly was wasted, and that the benchmarks that shows marked improvements over what the C compilers generate are lies. He's gonna be pissed.
We'd better tell that to the people who write H265 video codecs, too.
And unlike a human, the compiler can't tell you : "you know, if you tweaked this data structure and that algorithm a bit, it'd be significantly more CPU-friendly and you'd get much better performance."
-
@Zerosquare said in WTF Bites:
There aren't. If you said something about exotic platforms with bad tools, I would agree. But there's no situation where a human can write better x86-64 assembly than a compiler. Especially when you consider that inline asm disables many other optimizations.
One of my friends cofounded a company that does middleware for video games (both PC and consoles). I'll let him know that all the time he spent hand-optimizing critical code in assembly was wasted, and that the benchmarks that shows marked improvements over what the C compilers generate are lies. He's gonna be pissed.
The most critical question is: when was that?
And unlike a human, the compiler can't tell you : "you know, if you tweaked this data structure and that algorithm a bit, it'd be significantly more CPU-friendly and you'd get much better performance."
This tweaking isn't exclusive to asm. In fact, this is how you usually optimize code in high-level languages.
-
@pie_flavor said in WTF Bites:
@Cursorkeys said in WTF Bites:
But there was gnashing of teeth over the inefficiency of not hand-crafting the ASM :)
Those people are idiots. C code is probably better than hand-crafted ASM because people don't know how to be efficient.
Did you even read the post you're replying to? @Cursorkeys wrote "I started my career ... the first C compilers". Yes, compilers are very good at generating well optimized code now. 30+ years ago, not so much.
-
Human-written asm of non-trivial complexity will never beat the compiler, especially as a part of a larger application.
Can a compiler write Rollercoaster Tycoon? Checkmate atheists.
-
@anotherusername said in WTF Bites:
@loopback0 said in WTF Bites:
@boomzilla said in WTF Bites:
@boomzilla yeah...gotta take it in to unbreak whatever broke with my certificates and the domain.
They'll probably just drop it from the domain and rejoin.
It was likely disconnected from the domain for too long.I've had that happen plenty of times, but I've never seen that error message. Usually it's "the trust relationship between this machine and the domain server could not be verified", or something to that effect.
Is that what causes that message? The client for whom I'm working has a bunch of machines in another building across town that are currently unusable because of that, but nobody has access to them.
-
The most critical question is: when was that?
Not more that a few years ago, at least. I could ask him if he still does nowadays.
This tweaking isn't exclusive to asm. In fact, this is how you usually optimize code in high-level languages.
The principle isn't exclusive to assembly, yeah. But the level of optimization you can achieve is. When you've optimized your algorithm to take full advantage of specialized instructions your CPU has, you can either:
- assuming your compiler supports the instructions in the first place, tweak the C source until the result approximates what you want (and hope that any changes in the code or the compiler version won't cause performance regressions later)
- write the damn thing yourself, using either intrinsics or straight assembly, and be done with it.
Not to mention that there are lots of other targets besides x64 when you look outside of the desktop PC/servers ecosystem. On systems running on small batteries, you're not necessarily looking for the fastest way to do things, but for the most energy-efficient way. If you think "I'll let the compiler figure it out, I don't have to bother with this low-level stuff", you're going to be disappointed by the results.
-
@pie_flavor said in WTF Bites:
C code is probably better than hand-crafted ASM
In some cases, yes. In some cases, very much no.
@Zerosquare said in WTF Bites:
if you look into specialized domains like games, audio/video processing or embedded development, there are still cases where hand-written assembly can outperform compiler output significantly in performance.
The usual issue is that the compiler decides to do lots of register shuffling and ends up spending so much time moving things around there that all the gains it might theoretically have get swallowed. That's caused by compilers thinking that register-register moves are free: they're not, though they're fairly cheap on architectures with high degrees of caching. On embedded processors, they're cripplingly slow (since those processors run much slower than desktop processors) so moving things around a lot is punishingly costly and many compilers generate terrible code as a consequence.
function.c\src - make.git - make
