Interesting, saw reCAPTCHA infinite loop for the first time in a long time just yesterday, on Firefox, and it was when I tried to access an article on PMC. Disabling uBlock and Enhanced Tracking Protection did not help. It looked like several automatic reloads, then one real reCAPTCHA showed, and infinite reload loop after I solved it.
Does not reproduce today though, and I never had issues with PMC/NIH before that.
I got an impression from the text that pilots were not sure the fuel levelling line does not have a leak itself. Maybe they were afraid the line can leak fuel into fuselage somehow?
I think the way I've talked about incremental linking may have given a somewhat misleading impression. I'm not against incremental linking, and I'm not denying its possible usefulness. But especially when I was developing lld, I felt that we should focus first on speeding up full links.
Before I created lld, linking was much slower than it is today, and people somehow seemed to accept that as a given. People would often argue that since linking was slow, we needed to reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic. Why don't we just make the usual full link much faster, ideally almost as fast as a cp command, so that we don't need incremental linking nearly as much?
In other words, I wanted to solve the slow link problem head-on rather than work around linker slowness. And now we can link multi-gigabyte binaries in a second or two, which makes incremental linking much less urgent than it was ten years ago. That's pretty much what I wanted to achieve.
Am I satisfied with the speed? No. Could incremental linking speed it up even more? Maybe. Would it still be useful? Sure. It may well be worth doing. But people don't need it nearly as badly as they did ten years ago. I wanted to solve the larger problem first.
This may just be too much. I settled up on 0.2mg dosage - you can find 0.1mg tablets, easy to try different dosages with them. Also seems to work better if you take it 2-3 hours before sleep.
Not only is CMake single threaded but the generation step time scales almost quadratically* with the number of targets in some cases. Probably not what happens here but this is what forced us to move from CMake — generation times were surpassing 5 minutes, and this is not counting configuring step.
* Because in CMake there are several target properties that may be affected by the "parent" (another target which added this target as dependency), meaning that these properties need to be re-evaluated in the context of each root target dependent on this one. If I remember correctly, exact mechanism is that some properties can have generator expressions, and these expressions can reference "parent" target. Now we imagine an app which has some std lib with 1k targets, and 100 top-level executables dependent on this std lib - suddenly we have 100k target evaluations in generation step.
I'm not trying to overlook cmake's issues... However my first thought on reading about your problem is "you shouldn't do that anyway - write simple code that someone else can understand". A little complexity is sometimes needed, but if your generations times are more than 30 seconds you probably should step back and do something different anyway.
Important detail here is that the problem disappers if you use PRIVATE dependencies — but you can't do that with a heavily templated C++ codebase. Templates (and complexity they bring) are there for good reasons (primarily performance at all costs) so we did not manage to find a path forward with CMake.
Just learned about Kenji by finding his "The Best Chili Ever" recipe [0] through Reddit and immediately his another recipe appears on HN. Baader-Meinhof strikes again.
That's interesting. I assumed that the OP's attempts to fix the prompt looked like jailbreaking attempts and got the account auto-flagged into hair-trigger 'classifier jail'. Of course, a bad actor would swap accounts, so maybe Anthropic flags both the account and the prompt (coming from any account).
reply