dxf

If you are asking, "Is Google helping with any C++20 support upstream?" the answer is Yes.

E.g. for standard concepts in libc++:

std::derived_from (D74292) std::convertible_to (D77961) Arithmetic concepts (D88131) std::move_constructible (D96230) std::copy_constructible (D96232) std::invocable (D96235) std::regular_invocable (D96235) etc.

Google is _big_ and C++ is used for many projects that build with disparate toolchains (even if they are all based on Clang/LLVM); each project can have different needs to adopt parts of C++20 sooner than the others, and different costs for doing so. Moving from Clang modules to C++ standard modules is an effort that, for some of our projects, lives at the nexus of "Are Standard Modules sufficiently done upstream to be able to replace our use of Clang modules?" and "What is the cost of doing that?" and "What is the benefit of making that switch?" For other projects, adopting standard modules is a more straightforward calculus.

>The two main backers (Apple and Google) seem to have backed out.

Google has not "backed out".

E.g. look at this topic's discussion thread. The current top comment is about [[clang::musttail]]; the implementor of that attribute works for Google. The current second top comment is about the Rust compilation wins from the switch to the New Pass Manager; the NPM was primarily implemented by (and turned on as the default pass manager upstream) by people who work for Google. Google is actually growing our investment in people contributing to core Clang/LLVM.

Source: I am a manager for C++ toolchains (those that target production, Chrome, ChromeOS) at Google.

No, because you have to pay taxes on income you receive from illegal activities.

https://www.irs.gov/publications/p17

Illegal activities. Income from illegal activities, such as money from dealing illegal drugs, must be included in your income on Schedule 1 (Form 1040), line 8, or on Schedule C (Form 1040) if from your self-employment activity.

The Johnson and Johnson and AstraZenica vaccines are not mRNA; they are a more traditional "standard" vaccination (adenovirus vector). Are your friends willing to get one of those?

The piece that first got me interested in classical music was Arthur Rubinstein playing Beethoven's 5th Piano Concerto (the "Emperor Concerto"). I recommend that piece, but I particularly recommend Rubinstein's performance.

But that's my point. It shouldn't be a red flag on the candidate, and shouldn't need to be explained.

>Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume.

Sorry to hijack your comment, but I would like to say:

There are many, many good reasons why someone would want to quit a job after only a short period of time at a company (harassment being an obvious one). It took me a long time to realize this fact, and stop viewing a quick departure as a potential red flag and also stop asking questions like "Why are you looking for a new role?"

Someone leaving a toxic environment really doesn't want to spend any part of the interview talking about the past; they want to show you they will be a valuable member of your team, while also learning if your company is one they want to work for. We should all consider that the next time we are reviewing resumes and interviewing candidates.

According to their website, Maui Jim frames and lenses are manufactured in either Italy or Japan.

I own both Maui Jim and Randolph Engineering sunglasses and I would not hesitate to buy either again, though they are pricy.

Google's SafeSide project published a number of practical demonstrations of leaking data through side-channels.

https://github.com/google/safeside

What is the "office class" printer you have trouble with?

I've never seen this issue with my Brother MFC-2740DW using "Image Capture" on my Mac (which I assume you are referring to as the built-in scanner app). It's worked flawlessly for me (as did my previous Brother laser printer/scanner).

I think it's great that gcc, Clang, and MSVC all push each other to improve their compile/link performance, code generation, error messaging, etc.

Yes, now that Sundar is CEO of Alphabet they pretty much have to.

https://www.marketwatch.com/story/why-google-finally-disclos...

"Revenue-recognition rules that were approved in 2014 and went into effect at the end of 2017 call on companies to report financial results to their investors in the same manner that they are reported to the main decision-maker at the company, typically the chief executive. Basically, if a CEO sees numbers for a large segment of the company, the company should be reporting that segment’s results to investors.

As the revenue-recognition rules were being put in place by companies in 2017 ahead of the deadline, the Securities and Exchange Commission entered into communication with Alphabet specifically to discern why it was not providing revenue numbers for its segments, mentioning YouTube, Google Cloud and some other businesses, such as hardware. Google responded by saying that its chief decision-maker, Alphabet CEO Larry Page, did not see results parsed to that level, though Google CEO Sundar Pichai did."

I'm not sure what you mean by "run"? I use Firefox as my browser on my iPhone.

The LLVM issue was addressed in LLVM in https://reviews.llvm.org/D64757 and https://reviews.llvm.org/D64759.

Those haven't been released in Android yet, but they should be in the next quarterly release of Android. My understanding from chatting with the Android team is that though this is a weakened mitigation, it is not an exploit.

At Google, we strive to ship a new Clang/LLVM toolchain to our C++ developers every week.

Two of our toolchain engineers gave a talk on this at CppCon. Check it out if you're interested: https://www.youtube.com/watch?v=zh91if43QLM

You're right that many microbenchmarks can be noisy (and the environment you run them on can introduce more noise).

But if you're attending cppcon, two engineers in Google's production toolchain organization are giving a talk on "Releasing C++ Toolchains Weekly in a 'Live at Head' World" where they'll discuss (among other things) how we use various microbenchmarks to catch performance regressions.

https://sched.co/Sft4

You have to be careful though. The compiler can do a very good job of lifting statements (and many other optimizations), so it is generally a better use of developer time to try and write code that is clear than to write code that is believed (without evidence) to be more performant.

I didn't see it in the article, but I wonder how much debt that was forgiven was actual credit extended for purchases (which is money that Chase has "lost" as they won't recover it) and how much debt was interest+fees on the credit they extended.

I'd worry about those problems (e.g. "revert wars") if and when you ever see them happen. They will be easy enough to spot.

MSFT is already contributing to Chrome, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=893460

From my position sitting at the crossroads of Clang/LLVM and Chrome (the team I work on developed clang-cl), all the interactions I've seen with MSFT are positive.

The article says the MSFT will be a significant contributor to Chromium. If anything, this means that Google will have _less_ control, as a second major internet player will be involved.

These chips are not really for Hell, as Hell is much hotter than 500°C, see Healey, T (1979). A Refutation of the Proof That Heaven is Hotter Than Hell. The Journal of Irreproducible Results, 25(4), 17-18

I enjoyed reading "Fumbling the Future: How Xerox Invented, then Ignored, the First Personal Computer"[0]. At the end of the first half of the book, you wonder how anything can stop Xerox. In the second half, you learn how Xerox can stop Xerox.

[0] https://www.goodreads.com/book/show/638812.Fumbling_the_Futu...

Gene Siskel gave it thumbs up, so you're not that much of an odd ball.

Clang 7 documentation has a section on MSVC compatibility, https://clang.llvm.org/docs/MSVCCompatibility.html

From that document:

Asynchronous Exceptions (SEH): Partial. Structured exceptions (__try / __except / __finally) mostly work on x86 and x64. LLVM does not model asynchronous exceptions, so it is currently impossible to catch an asynchronous exception generated in the same frame as the catching __try.

I've got a rather old iMac. Even though it has screws on the back, you replace the drive (which I just did) by going through the front -- step one, attach suction cups and remove the screen. (Shout-out to iFixit for their informative guides.)

You've confirmed this truly not user-servicable?

(edited typo)

This is very exciting. The blog post mentions cross-compilation, and being able to use lld should also result in faster link times and the ability to enable Clang features like CFI.

Congratulations on this milestone!

Yes, I should have been a bit more clear. You can link with lld (we have bots running that do this; we're even setting up a bot that enables ThinLTO). But lld support for emitting PDB files isn't quite there yet.

I'm not sure what is meant here.

"opting in" to VS 2017 is recommended when building Chrome for 64-bit Windows to get improved incremental linking support. (We still link Chrome on Windows with link.exe even when compiling with Clang.)

Yes, this is something that is being worked on.

Not having to worry about language feature support across different compilers is a big win. See https://bugs.chromium.org/p/libyuv/issues/detail?id=685 for one specific example of why using Clang can have benefits over MSVC (TL;DR: 64-bit MSVC doesn't support inline assembly). Clang was already being used to compile this little part of Chrome on Win64.

Switching to Clang also allows the use of Clang-based sanitizers and fuzzing, which improves the security of Chrome.