What does this comment mean? Function parameters used or not are part of the function signature, so obviously would participate in any form of argument dependent lookup.
There's "not fast but usable enough" of course, but I would never ship std::regex code on any user facing software. Forget realtime, std::regex fails to be interactive in examples where other libraries resolve quickly.
IDK, JSON? HTML and XML are markup languages also. There are obvious issues with markdown that were fixed/resolved in various markdown variants, and missing features as well that I don't think anyone could argue helped adoption. Case in point, the most commonly used markdown flavor is GFM because we all adopted GitHub and that was what they support.
I'd argue that it won the adoption it did in spite of parsing ambiguities and the lack of a spec. Not because of it. There are plenty of examples of well specified things that have gained mass adoption, so I think you are confusing cause and correlation here.
Honestly, the best resources I know are the ISA/architecture manuals directly from each vendor (Intel, AMD, Arm) for the various CPUs and/or GPUs of interest. Prior to that, my experience largely comes from doing (working with lower level code, benchmarks, looking at assembly, profiling hardware counters, etc.).
Thanks I missed that line regarding the O states. Still, a word about write reordering on ARM would probably be useful (unless I missed that also).
I understand that synchronization in code vs hardware is different, but the blog explicitly moves out of hardware-land into source code land with references to Java volatile and such.
Hmm, I think the discussion is missing a few things needed for a complete picture of the situation.
First, ARM and x86 coherency models differ, so a big disclaimer is needed regarding the protocol. Most ARM processors use the MOESI protocol instead of the MESI protocol.
Second, synchronization isn't just because of register volatility and such. Synchronization is needed in general because without the appropriate lock/barrier instructions, compilers make assumptions about how loads and stores may be reordered with respect to one another.
If foo is a function in this example, then yes I agree for most PLs. If foo is a class, namespace, or some other declaration context however, its contents are definitely relevant when editing a different context due to possible usage of scope operators.
How do you propose code completions are done without it? To even produce a set of suggestions, you need to understand the parse context, the set of available symbols with appropriate types and scope resolution. AST parsers already have recovery mechanisms, and I am assuming those are all working as intended.
And that assumption is relevant in the context of OPs concern but not yours. You created a different hypothetical and orthogonal situation where the assumption need not apply, and to be honest, I lost the plot a bit. It's possible for there to be a branching set of concerns, each of which having their own set of perfectly valid but otherwise disjoint assumptions.
I guess I meant complexity in the sense of symbol resolution in this context. So things like scoped type aliases, expressions evaluated as template or trait arguments, that sort of thing.
Either way, all those files need to be marked dirty and reindexed, so I suppose I'm just not sure how the topic at hand is relevant. Is the proposal that we attempt to treat each dirtied file as though incremental edits were imminent? Because this is precisely the wrong assumption you're raising. Ultimately, if you need to reopen a file in order to see changes on disk reflected, that's a bug with your lsp server, nothing more.
I only know a little bit about zig, but I would have assumed that the latter mechanism you are describing isn't really possible. Most languages with "advanced" features and type systems really need a full semantic tree to do anything meaningful due to the complexities of compile time code and type instantiation.
Even if we are using this latter model, the user is only editing one file at a time. What if the completion source is in a different file altogether? Generally, you're going to be indexing the entire codebase anyways, so we're splitting hairs over a potential optimization in just one facet of the indexer.
As someone actually working on some symbol indexing stuff at the moment, I can mention that this model is ignoring some pretty important details, and I think there's some classic overengineering happening here (easy trap to fall into when you're still in the design space).
Generally, when you need a code completion action, it's expected that you have an AST (post semantic analysis). This AST is still very useful even after a user continues to edit the code! Outside of where the cursor is, most of the symbols, definitions, and declarations are relevant, and source locations can be easily translated from a previous version of the document, provided that deltas are tracked. Cancelling an existing translation unit parse on edit is wasteful, because the majority of the time, that parse will produce meaningful results. The better approach (IMO) is to let the parse finish, but immediately enqueue a subsequent parse (with some debouncing timer to avoid overly consuming user resources). If you wanted to level this up further, you could perform incremental parsing/analysis, provided your language supports it. In the presence of a preprocessor, this can be very difficult, but it's the next "upgrade" from the previous approach mentioned in my opinion.
And an easy way to lose everything because you sent tokens to the wrong address, forgot your passphrase, lost your hardware ledger, fell prey to some scam or another, house burned down, etc.
This is a typical sort of projection I see from crypto-owners. They can't seem to contemplate the fact that there are people that think crypto is a bad idea _regardless_ of how much profit they might or might not have made by buying or selling at various points in history.
I really don't think protecting IP produced at company expense is "evil." That's their prerogative, and people knowingly violating agreements/ToS are playing with fire.
Having every transaction recorded in a public append only but otherwise immutable ledger does not afford the privacy choice you have with fiat.
People using fiat are not losing their life savings when they forget their bank passwords, nor are they sending money to the wrong address and losing money irrecoverably.
What difference you mean, aside from the lack of a regulatory framework, pseudonymity (and paradoxically, lack of privacy), lack of recourse in the face of user error, and custodial issues? The "not your keys not your coins" take is hilariously dumb in light of how much "value" has evaporated in personal custodial failure. The currency and its supporting infrastructure has everything to do with it, and crypto fails basic litmus tests to even attempt to go mainstream.
In what way is its documentation not useful? I did a project based on TreeSitter a year ago and the docs were perfectly clear and adequate, and I was up and running within half an hour or so
Correlation != causation. It's clear that his success is in spite of himself, not because of it. I don't know anyone in my professional circle that would work under him, what with having a reputation for impulse firing people that disagree with you and other clear signs of egomania.