21–30 of 158 posts
The specific proposal (linked to from the article) is https://lkml.org/lkml/2019/7/30/1399
Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?
The specific proposal (linked to from the article) is https://lkml.org/lkml/2019/7/30/1399
Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?
This may be someone’s first submission and they may consequently not be aware of style guides, tools which can help lint, etc?
Earlier quoted context omitted.
Would it be useful to native programs?
Valve's post suggests that they believe this to be the case, although they didn't explain the specific details. > We think that if this feature (or an equivalent) was adopted upstream, we would achieve efficiency gains by adopting it in native massively-threaded applications such as Steam and the Source 2 engine.
Earlier quoted context omitted.
Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?
On the contrary, I think the feedback provided was excellent and far better than just saying “Doesn’t conform to our style guidelines, please try again”. Bravo Peter. This may be someone’s first submission and they may consequently not be aware of style guides, tools which can help lint, etc?
Earlier quoted context omitted.
The thing to remember is that version numbers aren’t decimals. They’re two or three integers separated by periods. 11 is higher than 2.
Harumph. Then it should be padded with zeros. So, 4.002 and 4.011 /grumpy edit: nope, it's fine as is. my experience in frame numbers, dates, and so forth do not scale to releases
Am I interpreting the graph on their page all wrong? It looks like the older version of Proton provides better performance? Unless they're graphing function call return time? The graph and the text around it doesn't do a good job of explaining that.
4.11 is newer than 4.2
Thanks for pointing out the obvious for those of us who missed it!
The specific proposal (linked to from the article) is https://lkml.org/lkml/2019/7/30/1399
Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?
The scale goes from 0 to 80. It's not horribly misleading, but just saying
I believe that’s because it’s frames per second, not an abstract percentile.
Isn’t a mutex timing out an indication that:
a) a lock wasn’t needed in the first place or
b) the program is incorrect?
It feels more like they just want the api to match win32 better but most of the multithreaded programming I’ve done lately has just used go’s channels so I totally could be missing something.