reproc/Lobby

Daan De Meyer

@DaanDeMeyer

You might be able to send all the fields separately between contexts and reconstruct the reproc_type struct manually in the new context and call reproc's function for stopping a process.

The transferring code would be platform specific since the reproc_type struct contains different information depending on the platform but the rest of the code would still be cross platform.

This does assume stuff like handles and open file descriptors are shared between contexts

Daan De Meyer

@DaanDeMeyer

and that you can send a handle pointer as a number between contexts

Boris Staletic

@bstaletic

I'm going to go offtopic again. Considering there was no talk here since the end of january, I'm guessing that's not so much of a problem.

I was playing with Intel's PrallelSTL and in about 5 minutes got to the point where std::sort of 65k elements works as fast as std::partial_sort of 10 (out of 65k total) elements.

Daan De Meyer

@DaanDeMeyer

I'm assuming that's impressive?

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--;

Where communities thrive

People

Repo info

Activity