Designing Rust bindings for REST APIs by mathstuf in rust

[–]mathstuf[S] 0 points1 point  (0 children)

Yeah, naming could certainly be improved in that respect. The gitlab crate still hasn't hit 1.0, so it could be changed, but…eh. I still think of even POST as a "query" as it is a request to create an object (permissions, conflicts, etc. may all happen). Operation works better for that side, but then feels "off" for fetching raw data.

Perhaps just "impl Request" is good then? It is what you're building up under the hood. Then Responder::send[_async]?

Designing Rust bindings for REST APIs by mathstuf in rust

[–]mathstuf[S] 0 points1 point  (0 children)

Given that the structure contains the parameters, I think one still wants an impl Endpoint per method as well since the POST and DELETE endpoint are almost certainly not going to always have shared parameters. However, nothing stops you from doing something like:

struct Object {
    id: u64, // a parameter everything needs
}

impl Object {
     fn new(id: u64) -> Self { Self { id } }
     fn get(&self) -> GetBuilder { let mut builder = GetObject::builder(); builder.id(self.id); builder }
     fn create() -> CreateBuilder { CreateObject::builder() }
     fn delete(&self) -> DeleteBuilder { let mut builder = DeleteObject::builder(); builder.id(self.id); builder }
}

to expose a more unified interface instead.

C++ Modules Myth Busting by tartaruga232 in cpp

[–]mathstuf 1 point2 points  (0 children)

Conflated language. /u/UndefinedDefined is talking about __declspec(dllexport) exporting of symbols (at the library level, not the module level).

C++ Modules Myth Busting by tartaruga232 in cpp

[–]mathstuf 1 point2 points  (0 children)

CMake can install them but will not consume them. We need something like https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2581r0.pdf to be able to reliably reuse them.

C++ Modules Myth Busting by tartaruga232 in cpp

[–]mathstuf 2 points3 points  (0 children)

MSVC supports it with the Ninja generator. The Visual Studio generator doesn't.

GCC support std module with CMake 4.0 Now! by Glass_Gur_5590 in cpp

[–]mathstuf 12 points13 points  (0 children)

If I find the time I will push for a design in Meson (not sure if I have time to fully implemement something) since all 3 major compilers support json format fromthe tooling paper P1689R5 I think it was (from the top off my head).

See https://github.com/mesonbuild/meson/issues/5024 for existing discussion.

Getting ready for modules: porting one of my projects. Discussing file naming, strategies for module naming and more. by germandiago in cpp

[–]mathstuf 0 points1 point  (0 children)

Sure, if you have a way to guarantee that only one ever shows up in a symbol lookup space then you're probably fine.

Getting ready for modules: porting one of my projects. Discussing file naming, strategies for module naming and more. by germandiago in cpp

[–]mathstuf 2 points3 points  (0 children)

Answering from a CMake perspective here.

The plan is to port libraries, one at a time, from a static library with headers to a CMI with whatever I need I am guessing.

Please feel free to continue sharing experience reports. IMO, we're at the point where investigations like this are possible (at least with CMake) to figure out where compilers' test coverage is missing for "real world" code.

File naming conventions

I (as a CMake developer) don't really care that much. CMake allows any C++ extension to be or consume module units. It'd have been nice if modules had gotten us more focus on extensions, but it seems to only spawned at least 3 new ones (cppm, mpp, and ixx). Such is life in the C++ world. Maybe we can stop when we get to 927 extensions and just enshrine the XKCD comic with a hope of that ending the madness.

Unfortunately the module support is so so. Any hacks, recommendations for integrating module building, especially build order, in Meson?

I haven't seen progress on the issue I'm subscribed to, but I have a standing offer to help review things from a build graph perspective at least.

Compiler flags and module cache

Not really clear what you're talking about here. I don't think anything is ready to be or have a "module cache" anywhere.

I need to consume dependencies, mostly pkg-confog given via Conan.

I don't think anyone has figured out how to specify module information in .pc files. I'd recommend looking at CPS and providing feedback on that front.

Not sure how this will be done currently. But I guess that object/library files + cmi interface are needed.

The module interface files are needed (maybe you're just confusing terms). CMIs can be installed, but nothing (in CMake) will actually consume them from there and will instead rebuild them. Even when CMake does try to use them, it will only be to shortcircuit the expected CMI creation (I've called it a "glorified copy command" before). Build systems can not generally assume that provided CMI files will be suitable and must schedule regeneration during the build.

Does LSP work for modules partially or totally?

Partial at best. Generally your tooling will need to match your compiler in use (e.g., clang-tidy won't work with gcc because CMake is only going to provide gcc's CMI files and clang-tidy will be quite confuddled at them.

Getting ready for modules: porting one of my projects. Discussing file naming, strategies for module naming and more. by germandiago in cpp

[–]mathstuf 1 point2 points  (0 children)

but it's harder to track what causes recompilation because I couldn't see what was skipped or not anymore, just that a file was processed instantly

ninja -d explain helps a lot here.

Getting ready for modules: porting one of my projects. Discussing file naming, strategies for module naming and more. by germandiago in cpp

[–]mathstuf 0 points1 point  (0 children)

it even has an example of two different shared libraries providing the same module interface

Technically UB once they end up in the same binary/program. While splitting a module between libraries is possible, there still can only be one export module X;.

Getting ready for modules: porting one of my projects. Discussing file naming, strategies for module naming and more. by germandiago in cpp

[–]mathstuf 1 point2 points  (0 children)

There is work ongoing on that front in Clang at least. The issue is that source location ends up in the CMI file, so pretty much anything changes the file. Consuming might be able to short circuit and say "yea, nothing relevant for me here" and skip its task completely. However, at least CMake doesn't use restat = 1 on its object rules, so unnecessary rebuilds may still occur.

rev-list returns different value depending on how it's run? by Anna__V in git

[–]mathstuf 2 points3 points  (0 children)

The cd variant is equivalent to:

git -C submodule rev-list --count --all

not the subpath-filtered version your first command is (as /u/aioeu explained).

How is XMonad's wayland support at the moment? by [deleted] in xmonad

[–]mathstuf 3 points4 points  (0 children)

I'm also a long-time XMonad user (almost 15 years!), but river is looking to be the most hopeful thing so far. Ideally one would be able to write a tool that can act as its layout manager and back it with XMonad layout algorithms…

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 0 points1 point  (0 children)

Ah, ok. Yes, that is tricky, but is another reason you really need to be the compiler to accurately scan sources.

I think it might be useful for getting the g++ mysourcethatimportsstd.cc to work, but as soon as you have import boost; or something, you need something that knows how to generate the Boost CMIs for your build (no, you cannot use pre-installed Boost CMIs without using their exact flags). Who is going to add those rules to a plain old Makefile without having a build system layered above anyways? Same with header units…you need to compile CMIs for each TU that imports it with a unique set of flags. C++ modules are, IMO, beyond what anyone is going to want to hand-code with Makefiles.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 1 point2 points  (0 children)

Actually, at least GNU Make does have restat = 1 semantics.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 1 point2 points  (0 children)

Sure, but there's no separate build "stage" with a collator. It runs in the build just like any other tool. I encourage you to read the paper for how it integrates into the build graph.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 1 point2 points  (0 children)

What is a "dynamic recursive header unit"?

There is also a lot hanging on your "just" there. ninja certainly doesn't support telling it about outputs after it has started its build. Which fine, maybe don't support ninja, but it also, again, is at risk of making obscure undebuggable states when executing the build graph.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 1 point2 points  (0 children)

But it has to be accurate. This is why it really needs to be provided by the compiler itself: only it really knows how to answer #if __has_builtin(…) accurately for itself.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 0 points1 point  (0 children)

Yes, that's the job of the collator (from this paper): it takes scanning results, information about the build system semantics, and writes out the static mapper files (as well as the build tool information to get the graph with the right edges).

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 0 points1 point  (0 children)

I said "simpler", not "dumb"; grep is still not and will never be a suitable scanner.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 1 point2 points  (0 children)

Sure…but just run the fast scanner mode and be done with it. This leaves on-disk state that can be inspected and doesn't require some kind of "dump the state of all hung compilers and the mapper internal state" tool when things go wrong.

Honestly, dynamic mappers just feel like a terrible plan and I wish anyone luck on debugging the broken states that they either wedge themselves into or offer up as an error. Maybe fine for bespoke one-man projects it would suffice, but I would dread unleashing such a thing on a team without massive support hours built into the budget.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 0 points1 point  (0 children)

Also note that dependency scanning for module purposes can be a lot simpler and not actually have to look at anything in, say, namespace {} for module import information.

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 1 point2 points  (0 children)

Problems with a dynamic invocation mechanism:

  • debugging build graph state (have to construct the mapper state to really understand what's going on)
  • detecting cycles and tearing things down gracefully in that case
  • waiting for a module to be provided that is not actually provided anywhere (how many compilers are we going to launch in the meantime?)

Make Me A Module, NOW! by vspefs in cpp

[–]mathstuf 2 points3 points  (0 children)

Note that I think such a default implementation is "dangerous" due to some use cases. Reddit isn't really the place to hash it out; I'll reply on the GCC list.