Instead of getting mad, just maintain the patch locally. You have fixed the bug for you, after all, so why get angry. The only thing that does suck is if you later find out your patch has been merged, but without attribution, in which case a passive aggressive mail to their list might be in order. Happens rarely, though.
And there are more than enough counter examples to your story, e.g. my latest fix to icinga (a nagios fork) had a turnaround time of roughly half an hour (Though github will only show it happened on the same day...)
Is it? I switched from FreeBSD to NetBSD in late 2013, there have been some 27k commits on trunk alone since (~1500 in 2017 so far). Also some 30k mails on the mailing lists. Not to say the project couldn't use some funding, but it sure does not seem 'nearly dead'.
You've got it backwards. Yes, I do know x86 and the pertinent C implementations rather well. But no, since C abstracts those concepts away, there is a) no need to and b) it actually makes things less portable if you have implicit assumptions about what the machine has and does WHEN C ALLOWS YOU TO NOT CARE ABOUT IT.
So please tell me, given the code int a, *b = malloc(sizeof *b);
What exactly is the advantage of thinking about `a` and `b` as "on the stack" and `*b` "on the heap"? I truly don't get it. What is the problem with thinking about `a` and `b` as having automatic storage duration+block scope, and `*b` having allocated storage duration? It's THOSE TERMS that have well-defined semantics that EVERY C implementation (including those that put things "on the stack"/"on the heap") *has* to comply with. (That is apart from the fact that something you think is "on the stack" might well be NOT on the stack because it's "in a register", or got opimized out entirely, rendering your stack/heap categorization as a heuristic at best).
Learn some C. Make your programs more portable. You'll end up a better C programmer.
It was actually a rhetorical question. Standard C does neither specify nor require a stack or a heap, and memory allocation isn't specified in terms of those. I'm only pointing it out because of the GP implying that knowing about "the stack" implies competence at C, which is far from true.
Or to put it differently: $ grep -iEc 'stack|heap' c11std.txt 0 $
Yes, Captn Capslock, I finally do. I wasn't sure I got it after the first dozen people pointing out that US measures BAC in percent as opposed to per mille, but your angry - albeit late - rant convinced me that I must be finally getting it. Thank you so much! I hope you didn't wet yourself over it because it sure sounds like you did.
No, it's just that you were the only one not realizing that both mistakes were intentional. Protip: It's obvious when you realize that no one in their right mind would accidentally type 'have' when meaning to type 'of'.
Emails ending in 'thank you' and friends get more responses because they likely contain some explicit prompt for a reaction/action, otherwise i wouldn't be expressing my gratitude in the first place, duh. Fucking news at 11.
Thanks, but the one thing your comment does not do is answer my question:-).
It is [consumed].
So then why do we see *anything* at the detector screen when measuring at the slits? How do you measure a single photon passing by without consuming it?
Slashdot Mirror
Instead of getting mad, just maintain the patch locally. You have fixed the bug for you, after all, so why get angry. The only thing that does suck is if you later find out your patch has been merged, but without attribution, in which case a passive aggressive mail to their list might be in order. Happens rarely, though.
And there are more than enough counter examples to your story, e.g. my latest fix to icinga (a nagios fork) had a turnaround time of roughly half an hour (Though github will only show it happened on the same day...)
and yields somehow valid code.
Comments. You have infinite tries to get it right.
Calloc! The drop in replacement for malloc that makes your code safer while also making it look like no fucks were given!
What a pile of shit.
Leave C to the adults, mkay?
Just make it a habit to store the bottle upside down.
Failing that, use centrifugal force -- just make sure the bottle is closed properly, then grab at the bottom and violently swing around.
It's completely stupid because ketchup slides down alright in upside down glass bottles. just give it a day or two
If only there was a way to design a connector that would not short yet retain a circular axis.
NetBSD is nearly a dead platform.
Is it? I switched from FreeBSD to NetBSD in late 2013, there have been some 27k commits on trunk alone since (~1500 in 2017 so far). Also some 30k mails on the mailing lists. Not to say the project couldn't use some funding, but it sure does not seem 'nearly dead'.
when i used it
When did you use it?
Yeah and with systemd it's finally starting to feel like 2000s windows.
The fuck is this funny?
Have fun raising a railroad bridge
You've got it backwards. Yes, I do know x86 and the pertinent C implementations rather well. But no, since C abstracts those concepts away, there is a) no need to and b) it actually makes things less portable if you have implicit assumptions about what the machine has and does WHEN C ALLOWS YOU TO NOT CARE ABOUT IT.
So please tell me, given the code
int a, *b = malloc(sizeof *b);
What exactly is the advantage of thinking about `a` and `b` as "on the stack" and `*b` "on the heap"? I truly don't get it.
What is the problem with thinking about `a` and `b` as having automatic storage duration+block scope, and `*b` having allocated storage duration? It's THOSE TERMS that have well-defined semantics that EVERY C implementation (including those that put things "on the stack"/"on the heap") *has* to comply with. (That is apart from the fact that something you think is "on the stack" might well be NOT on the stack because it's "in a register", or got opimized out entirely, rendering your stack/heap categorization as a heuristic at best).
Learn some C. Make your programs more portable. You'll end up a better C programmer.
It was actually a rhetorical question. Standard C does neither specify nor require a stack or a heap, and memory allocation isn't specified in terms of those.
I'm only pointing it out because of the GP implying that knowing about "the stack" implies competence at C, which is far from true.
Or to put it differently:
$ grep -iEc 'stack|heap' c11std.txt
0
$
So what is "the stack"? A core concept of C? Something the standard mentions in passing?
Yes, Captn Capslock, I finally do. I wasn't sure I got it after the first dozen people pointing out that US measures BAC in percent as opposed to per mille, but your angry - albeit late - rant convinced me that I must be finally getting it. Thank you so much! I hope you didn't wet yourself over it because it sure sounds like you did.
First you call it a lie, then you realize what happened. Is your point that even 0.02 % BAC is "very drunk"?
It happened so fast we almost missed it.
No, it's just that you were the only one not realizing that both mistakes were intentional. Protip: It's obvious when you realize that no one in their right mind would accidentally type 'have' when meaning to type 'of'.
I guess that's what happens when a raw number is used like this. Fair enough, I wasn't aware of it being measured in percent over there.
Yup, the cause was a drunk driver not how fast the car accelerated.
With a blood alcohol level of .21 you're not "drunk".
Could of done the same thing in any car.
Could of said "have" instead have "of" to appear semi-literate.
Seriously 0.2 is nothing and if that's thrice the limit, then the limit is ridiculously low.
Love from Germany, where the limit is 0.5.
whoosh.
If word gets out that paying doesn't help, then people will stop paying.
These are trustworthy criminals that have a reputation to lose.
because wtf is an "executable", fuck off with your computer shit.
Emails ending in 'thank you' and friends get more responses because they likely contain some explicit prompt for a reaction/action, otherwise i wouldn't be expressing my gratitude in the first place, duh.
Fucking news at 11.
e.g. putting a conducting loop around the slit that will experience a voltage pulse as the electron passes THROUGH it
Thanks.
Thanks, but the one thing your comment does not do is answer my question :-).
It is [consumed].
So then why do we see *anything* at the detector screen when measuring at the slits? How do you measure a single photon passing by without consuming it?