ReleaseCandidat

10 ms·

61.
by ReleaseCandidat 2y ago
We are not arguing whether not declaring phony targets is worse than using comments in `package.json`? But anyway, comments in a Makefile or `package.json` are not documentation anyway, that's what the `README` or `INSTALL` (or whateve
62.
by ReleaseCandidat 2y ago
> it works and, what's important, it works for him. Until it doesn't. And then you really have to learn about PHONY targets, why and when there must be a tab and not spaces - good luck with an editor that doesn't treat Mak
63.
by ReleaseCandidat 2y ago
> If the correctness matters so much that you're going to be messed up by a file named `all` or `build`... That's not the problém. _We_ know what "dev is already up to dáte" means, but chances are people who don'
64.
by ReleaseCandidat 2y ago
But I want please, ag and friends! The "problem" with this kind of package is that everybody wants something else. And the chances that they get a part of the default MacOS or Windows install (or even part of the XCode command lin
65.
by ReleaseCandidat 2y ago
Why use Make if they already use Gulp? Why not put that in `package.json`'s `script` stanza? And never ever use Make as a script runner without declaring the targets `.PHONY`, there will be a day when somebody has a directory (or file)
66.
by ReleaseCandidat 2y ago
> But it's more about being able to enter a project and have a consistent experience in "getting started". I'd say putting the Makefile content in `package.json` would be more consistent, especially as they are alread
67.
by ReleaseCandidat 2y ago
> "Buy our KVM Solution, we have KVM experts" Of course, but that is less of unique selling point. > But they evaluated that Bhyve was better then KVM despite that. If you are selling Bhyve you better say that whether it&#x2
68.
by ReleaseCandidat 2y ago
But that doesn't make sense if you have specialists for $A that also like to work with $A. Why should I as a customer trust Illumos/Bhye developers that are using Linux/KVM instead of "real" Linux/KVM develope
69.
by ReleaseCandidat 2y ago
Instead of stating more or less irrelevant reasons, I'd prefer to read something like "I am (have been?) one of the core maintainers and know Illumos and Bhyve, so even if there would be 'objectively' better choices, our
70.
by ReleaseCandidat 2y ago
That's just a local problém, there's no such shortage in Europe. Guess I'd just need a really cheap shipping option to the US to make some profits ;)
71.
by ReleaseCandidat 2y ago
Yes, that's true. Except it isn't (well, doesn't have to be) an extra step in the tokenizer. Most of the time you do not want to run the whole string or part of it through the kompatibility normalization but just some code po
72.
by ReleaseCandidat 2y ago
It's not about categories they don't help with such problems, but comparison using compatible normalisation (either NFKC or NFKD). Using that, e.g. 1 compares equal to I and i (the roman number literals) the 1 in a circle and all
73.
by ReleaseCandidat 2y ago
That's why you don't want to use regexes to parse something, but an actual tokenizer which uses Unicode _k_ompatibility normalisation (NFKC or NFKD) for comparisons. Although I'm not sure if that works with the Dollar emoji (
74.
by ReleaseCandidat 2y ago
Actually what you are using is an equivalence relation and you are generating the equivalence classes of your set, "your" associativity is transitivity. Whenever you are comparing something it's almost always better to think
75.
by ReleaseCandidat 2y ago
> Most of what's added to the language are things that people have been complaining about the lack of for _decades_. And are useless now, because everybody who had that problem either already solved it (the solution could have been
76.
by ReleaseCandidat 2y ago
I'm not sure if regex engine (or treesitter) + LSP really is faster than just using the LSP, as most of them check the source on typing anyways, so the overhead is sending the tags for the syntax highlighting. And there is no need to s
77.
by ReleaseCandidat 2y ago
> Syntax-coloring and [...] come to mind Semantic highlighting is part of LSP and supported by all "bigger" LSPs.
78.
by ReleaseCandidat 2y ago
> The reason why you use LSP is because it is a common protocol. Exactly. And if "everybody" (except MS) in the committee agrees on the implementation of LSP, they can define a new common protocol too. The old LSP clients and s
79.
by ReleaseCandidat 2y ago
> What do you mean? Why not? You need support for each language in the debugger, as symbols do not contain semantics. As users we for example know that `foo::bar` and `foo::baz` are methods of the same class `foo`, the debugger doesn&#x2
80.
by ReleaseCandidat 2y ago
I did formulate that badly. I did not want to say that Jetbrains and MS do not use LSPs too, but that the most important IDEs do _not_ use an LSP - Java, Kotlin, Python, C#, Rust - or add significant improvement to them - like the debugger
81.
by ReleaseCandidat 2y ago
Autocomplete.
82.
by ReleaseCandidat 2y ago
`ec` is an error code. What happens is a conversion to bool, see `operátor bool()` https://en.cppreference.com/w/cpp/utility/to_chars_result And no, don't ask mé why somebody might think that a bool is a
83.
by ReleaseCandidat 2y ago
Yes, the "skill" of the commitee to discuss some feature for a really looooooong time and then come up with a solution which is going to be (half) fixed in the next standard always astonishes mé :). I guess with C++38 we'll g
84.
by ReleaseCandidat 2y ago
No, that's why `maybe_unused` has been needed.
85.
by ReleaseCandidat 2y ago
No. Actually "interactive" frontends in batch compilation mode generally have better error messages in this mode too. Yes, it may make the batch compilation (the frontend part) sligthly slower, but won't turn Go into Rust (or
86.
by ReleaseCandidat 2y ago
Rust-analýzer is an example of what not to do, which is reimplementing a compiler frontend. Ideálly it should be the samé as the "real" compiler is using. Of course this has it's own problems, which the Haskell LSP this post
87.
by ReleaseCandidat 2y ago
Treesitter is the wrong solution anyway. The biggest advantage of LSP is that the parser, type checker,... used by the LSP is (well, can and should be) the same as the one used in the compiler (or at least another _complete_ implementation
88.
by ReleaseCandidat 2y ago
But then there is no reason to use LSP, they could (and should) come up with their own protocol.
89.
by ReleaseCandidat 2y ago
> doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this? Jetbrains' main feature are their own engines. And MS still has Visua
90.
by ReleaseCandidat 2y ago
I guess that the GP didn't talk about the language itself, but the users. For me it looks like Scala and Clojure had lost many of its users because of Kotlin and newer Java versions. Generally I see a decline in the usage of functional

More ›