61–70 of 74 posts
Is there one similar to this but that doesn't require your code to compile under Clang? I have plenty of projects at home that don't instantly work under Clang. So far, I've never seen any C++ language server that doesn't rely on Clang unfortunately.
https://reviews.llvm.org/diffusion/L/browse/clang-tools-extr...
Earlier quoted context omitted.
I saw that on Twitter but I couldn't figure out what his actual complaint was. I think I'd probably disagree but I'm still interested in knowing.
That doing all of this stuff via rpcs vs function calls is crazy I believe.
He has a point but there's nothing to stop you bringing some of this in-process or caching aggressively.
Author here! Wasn't quite ready to post to HN yet since cquery is still in development, and I plan to eventually publish on the vscode marketplace so using cquery should be as simple as using the existing C/C++ extension. Let me know if you have any questions.
Hi! I see you're using compile_commands.json. How are you handling header files? I've found that header files present problems for compile_commands since a number of tools using compiler_commands (like bear) only look at the compiler commands for .c files, and don't notice that the header files should be added as well. I know that some tools, like YCM, attempt to intelligently map a header file to it's associated .cp…
When a cc file is indexed cquery will index the associated header files. There is some logic to deduplicate multiple header file parsing so it only happens once, but that is fundamentally how it works. cquery then knows which header files are associated to which cc files.
> I know that some tools, like YCM, attempt to intelligently map a header file to it's associated .cpp/.cc/.c file to guess what the compiler commands are, but this doesn't always work.
cquery does this as well, because you can, for example, create a new file that is not in compile_commands.json. cquery has sophisticated logic here, as it will also try to infer if the file is test or platform specific (use general postfix matching) as those often have a very different set of arguments.
> What is the state of generating compiler_commands.json for Chromium? I remember running into this issue a few years back.
Chrome compiles using ninja, which natively supports compile_commands.json, so generating the file works well and is easy to do. I have not run into any issue here.
Earlier quoted context omitted.
I saw that on Twitter but I couldn't figure out what his actual complaint was. I think I'd probably disagree but I'm still interested in knowing.
That doing all of this stuff via rpcs vs function calls is crazy I believe.
For huge projects you want the build/index performance from a fast build server rather than a laptop, buildi environment inside a docker container, IDE in windows and build in linux, free choice of IDE rather than tighlty tied plugins.
Though i fully agree that json might not be the best packaging.
Earlier quoted context omitted.
Some advice if you do decide to learn C++: there has been a steady stream of improvements in standard C++ the past 8 years (C++11-17), and some (Bjarne Stroustroup, Herb Sutter, others) promote it as a better starting point for beginners under the name 'Modern C++'. From: https://msdn.microsoft.com/en-us/library/hh279654.aspx "[...] Over the years, features have been added to the language, together with highly-tested…
C++ as a language has certainly modernized, but its tools are still stuck in the 90's. Contrary to the increasingly bizarre rationalizations offered up by its proponents, CMake and friends are not acceptable package managers or build tools, at least to those of us who have used newer languages. I don't need a build tool assumes all projects are unique snowflakes in need of their own hand-crafted build system; I just…
PS: I don't think you will find a single "fan" of cmake who would say it's the best thing since sliced bread. Most people know it sucks, but grudgingly admit that its better to have one bad standard than a dozen competing solutions.
Is this like https://github.com/Andersbakken/rtags but for vscode? Any key differences?
I tried using rtags before developing cquery, but found it did not perform well enough for Chrome when doing a huge number of semantic operations (I was hacking in support for code lens). I spent some time trying to figure out if it code be fixed but I believe it would have been too large of an architectural change. - cquery interacts with an editor via the language server protocol, letting it work with any editor wi…
Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.
Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).
Earlier quoted context omitted.
Although C++ has lots of warts, I still really like the language mainly thanks to the tooling around it. It has had very good IDEs for years and when I see some of the advancements in debuggers and profilers for more modern languages I feel that they are still quite behind. Note that this server is based on libclang. This is good because having a good language support means that you have to practically write a compil…
It existed, but sadly both were too early for the market. The first one was from Lucid, after pivoting away from Lisp Machines. https://www.dreamsongs.com/Cadillac.html Here is a demo on YouTube. https://youtu.be/pQQTScuApWk IBM also tried to create a Smalltalk style repository in Visual Age for C++ v4.0, which has quite resource hungry for mid-90's PCs. So we had to wait until the idea of compiler as library to catc…
The Lucid CL IDE wasn't THAT advanced. Fairly standard CL stuff.
Example: SUN sold Lucid CL as Sun Common Lisp and the IDE was called Symbolic Programming Environment:
http://3e8.org/pub/scheme/doc/lisp-pointers/v2i2/p5-endelman...
That's nice, but not too advanced and with a basic look&feel.
Lucid as a company failed, because the C++/Energize product failed in the market and it consumed all the money they had earned from milking their Lisp business, which itself was in a shrinking market.
Earlier quoted context omitted.
C++ as a language has certainly modernized, but its tools are still stuck in the 90's. Contrary to the increasingly bizarre rationalizations offered up by its proponents, CMake and friends are not acceptable package managers or build tools, at least to those of us who have used newer languages. I don't need a build tool assumes all projects are unique snowflakes in need of their own hand-crafted build system; I just…
The funny thing about cmake is though that simple things are indeed simple, you can describe an executable made of several compile units in a single line of cmake script. The problem is that it doesn't enforce any standardization beyond that of how to structure complex projects, especially if external dependencies are involved. PS: I don't think you will find a single "fan" of cmake who would say it's the best thing…
This happens in all the time. At one point here on HN I lamented that C++ didn't have a build system like Rust's Cargo, and lots of C++ folks came out of the woodwork to argue that Cargo is a shitty tool because it can't support certain byzantine projects. Similar arguments were made in a thread about a new C++ package manager that attempts to modernize C++ package management. Almost all of the pro-CMake arguments focus on how capable it is to handle bizarre projects, without realizing that most such projects are bizarre only because they each had to implement their own build system instead of using one that encouraged them toward some standard structure. I can't recall anyone making an argument that resembled "it's better to have one bad standard than a dozen competing standards", even in response to something like "CMake is the best of all C++ tools, but still a far cry from other languages' tooling." Some people would allude to C++ projects being uniquely difficult to build, and so it would be impossible to emulate another language's tools; however, this too seemed to be confusing "C++ projects lack a standard structure" with "C++ projects can't have a standard structure". I could go on and on.
Earlier quoted context omitted.
I tried using rtags before developing cquery, but found it did not perform well enough for Chrome when doing a huge number of semantic operations (I was hacking in support for code lens). I spent some time trying to figure out if it code be fixed but I believe it would have been too large of an architectural change. - cquery interacts with an editor via the language server protocol, letting it work with any editor wi…
I've been happy user of ycmd+rtags tandem for a couple of years. A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too). This allows me to do develop on my weak 4-core laptop and offload indexing to fast 32-core workstation. Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (Recursiv…
I have a similar use case in mind, so I'm planning on trying to get this working by writing a simple script that proxies language server messages over SSH/TCP. Ideally it should work with any language server.
> Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.
Yea, it is amazing how big of a difference the architecture around indexing makes - any sort of global lock/shared state really hurts performance. I spent a significant amount of time finding the right architecture to make each index job as independent as possible. Most of the design decisions in cquery are oriented towards either latency or throughput at the cost of things like memory and total system load (I've since reduced memory usage, but at one point cquery used 30gb after indexing Chrome - now it is around 5gb).
> Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).
I'd like to see cquery support in vim as well using a vim LSP implementation :). But yes, I agree with you - cquery makes me want to continue using C++ over Rust simply because the tooling works a lot better.
Earlier quoted context omitted.
I've been happy user of ycmd+rtags tandem for a couple of years. A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too). This allows me to do develop on my weak 4-core laptop and offload indexing to fast 32-core workstation. Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (Recursiv…
> A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too). I have a similar use case in mind, so I'm planning on trying to get this working by writing a simple script that proxies language server messages over SSH/TCP. Ideally it should work with any language server. > Regarding indexing time, all of these tools seem to parse source code using either li…
I think I know at least 2 efforts to do this by now. One at Facebook with Nuclide, and I believe VS Live Share does something similar.
I think it's an idea whose time has come, so I think it's pretty cool that so many people are doing it.