reproc/Lobby

Boris Staletic

@bstaletic

The complete std::sort has, considering O(nLogn), has ~5 times more work, but it gets completed in about the same wall time. I do think it's impressive.

Daan De Meyer

@DaanDeMeyer

@bstaletic Thanks for the mention in the Belfast trip report post.

Boris Staletic

@bstaletic

Don't mention it. My first thought was "What trip report? I wasn't in Belfast!"

Daan De Meyer

@DaanDeMeyer

I randomly checked the Traffic report on Github and noticed people were visiting reproc from the belfast trip report post. Never expected that to be the origin of visits

Boris Staletic

@bstaletic

Hahhaah

Daan De Meyer

@DaanDeMeyer

I had one referal from the US army bugzilla once

no idea what was going on there

Boris Staletic

@bstaletic

I rewrote that comment a bunch of times, trying to find the right balance between unimportant historical details and details that actually matter.

Daan De Meyer

@DaanDeMeyer

I was a bit dissapointed by ned14's reply to your comment that the API was easy to get right after all the effort I put in keeping reproc's API as simple as possible

Boris Staletic

@bstaletic

I believe what he wanted to say is that it's a much bigger problem being able to change the definition of the abstract machine to make it recognize that the world isn't just the single process that is currently being executed.

Daan De Meyer

@DaanDeMeyer

I agree that's likely a much harder problem to solve. I'm not entirely sure it's worth it to standardize a process library for C++ though. I wouldn't be able to live without subprocess in Python but I feel there's more important stuff to focus on for C++.

Boris Staletic

@bstaletic

I'd much rather see std::process than std::audio, std::video or, god forbid, std::web_view.

Daan De Meyer

@DaanDeMeyer

Naturally, those are much better served by libraries (although a standardized way of distributing libraries might help)

distributing might not be the right word

Boris Staletic

@bstaletic

Something like cargo/crates.io?

Daan De Meyer

@DaanDeMeyer

More like something that allows interop between all the build systems

Boris Staletic

@bstaletic

May I just say... pkgconfig?

Daan De Meyer

@DaanDeMeyer

It's the closest we have at the moment

Although CMake config files are a contender as well with meson adding support for them

Boris Staletic

@bstaletic

C++ committee did form a tooling study group.

Daan De Meyer

@DaanDeMeyer

But if something was ever standardized it would very likely be something declarative instead of CMake config files which are imperative

Boris Staletic

@bstaletic

I dislike declarative configuration with passion.

At some point the cumulative needs of the users will make you wish you had a turing complete language instead of ad-hoc solutions in the "it's good enough" declarative language.

Daan De Meyer

@DaanDeMeyer

Same, although the scons build system at my job hasn't made me fond of a full programming language for build systems either

Boris Staletic

@bstaletic

I haven't used scons, so I'll have to take your word for it.

However, I'm guessing you remember how much I talked about YCM's .ycm_extra_conf.py.

Daan De Meyer

@DaanDeMeyer

I do remember you mentioning it but not the specifics

It's a python script for configuring YCM right?

Boris Staletic

@bstaletic

Yes. YCM passed a filename to it and a function inside the file returns { 'flags': [ flags ] } (with a few other optional properties).

When compile_commands.json is too limiting, YCM users can solve that by implementing thte logic in the extra conf.

Daan De Meyer

@DaanDeMeyer

Making scons generate a compilation database was quite the adventure, I still don't have it quite where I want it. All headers are copied to a rootfs in the build directory by the build so each time I hit go to definition I end up in the build directory. I'm working on making that symlinks which clangd should be able to handle

It's a shame cquery winded down but clangd has been getting more amazing with every release

Boris Staletic

@bstaletic

Things I miss in clangd:

clangd/clangd#45 - not for myself, but it would allow ycmd to drop the old libclang based completer
clangd/clangd#36

Daan De Meyer

@DaanDeMeyer

The first one seems hard to implement. clangd would need some way to correlate the separate files with the actual file that's compiled

Boris Staletic

@bstaletic

Libclang API supports that.

Support for that in our libclang completer was quite an intrusive change.

And we didn't have to worry about the index.

Daan De Meyer

@DaanDeMeyer

I can imagine it was, props for adding support for something like that

If only a bit more thought was put into the compile_commands.json format when it was invented

It could have been more flexible to support these use cases

Boris Staletic

@bstaletic

It's basically the only way to get support for unity builds. I.e.

// A.cpp
int x;
// B.cpp
x++;
// only_compile_this.cpp
#include <A.cpp>
#include <B.cpp>
x--;

Now you open B.cpp and get errors, because x was never declared.

Daan De Meyer

@DaanDeMeyer

A comment in the CMake release thread mentioned unity builds breaking compile_commands.json

Boris Staletic

@bstaletic

With clangd/clangd#45 you can say "when I open B.cpp, parse it as if TU main file was only_compile_this.cpp".

Daan De Meyer

@DaanDeMeyer

That actually seems feasible to add to compile_commands.json without thinking it through in detail

Boris Staletic

@bstaletic

It should be. Add an optional field called override_filename.

Daan De Meyer

@DaanDeMeyer

Yup, and it's optional so most tools should keep working

Boris Staletic

@bstaletic

That would leave only some obscure uses for the YCM's extra confs. Like executing make flags $FILEPATH to get the flags.

Yes, I've seen that done.

Where communities thrive

People

Repo info

Activity