13:00 <zao> Finally, Git tooling that can help with the heft of the HPX repository - https://vfsforgit.org/ :P

13:15 <hkaiser> zao: assuming our repo is considered 'massive'

13:15 <hkaiser> they talk about 12+ hours needed for cloning ...

13:23 <zao> MS monorepo they cite is "300G".

13:23 <zao> HPX isn't that bad, but still downloads a ton of dead weight on a non-shallow clone.

13:25 <zao> Seems a bit behind on Git versions and a bit unpolished at the moment, but interesting nevertheless.

13:25 <zao> I just found out that my favourite Git GUI is becoming a paid product, time to find a new one. :(

13:27 <K-ballo> which git gui is that?

13:28 <zao> "Fork"

13:28 <zao> "Free, $49.99 soon", three concurrent machines

13:28 <zao> (Windows and mac clients)

15:23 <Yorlik> Is there any other purpose behind client components besides type safety? I have to consider using these or just construct an interface around an id_type (or a typed id_type wrapper struct) which I expose to Lua manually with free functions. Not sure yet what would be more work.

15:27 <hkaiser> just type safety and convenience

15:28 <Yorlik> Thanks. So I'll just have to see what's more practical and creates less allocations/deallocations.

15:29 <Yorlik> Exposing to Lu still requires me to list every single method/function anyways.

15:29 <Yorlik> Lua

15:29 <hkaiser> Yorlik: clients are essentially fancy future<id_type>'s

15:31 <Yorlik> I still have to think how to expose futures and id_types to Lua. I will need them, but I want to hide them away as much as possible from scripters. But I won't be able to hide away the asynchronous environment from scripters entirely and it would probably be very inefficient to do so.

15:32 <Yorlik> Got some tricky design thinking to do.

15:32 <hkaiser> Yorlik: one of our collaborators here at CCT has created LUA bindings for HPX before

15:33 <hkaiser> https://github.com/STEllAR-GROUP/hpx_script

15:33 <hkaiser> those bindings had futures as well, iirc

15:33 <Yorlik> I think I will just expose futures entirely transparently and have a way to store them until the next frame, when the objects get updated again.

15:34 <Yorlik> So scripters will have to understand the semantics of checking futures. But I will not expose wait or get, to not block a running update task.

15:35 <Yorlik> Just a check and when it passes get the value.

15:36 <Yorlik> Or something like try_func_sync() which works for local requests and fails for remotes.

20:28 <Yorlik> Is there a way to register actions from templates or would I have to write all specializations manually?

21:11 <Yorlik> hkaiser: YT?

21:12 <hkaiser> here

21:12 <Yorlik> Is there a way to register actions from templates or would I have to write all specializations manually?

21:12 <hkaiser> template actions or actions on template component types

21:13 <Yorlik> I need to send any type of message with attached data across the network and am looking for the best way to do it.

21:13 <Yorlik> Its about usertype messages.

21:13 <hkaiser> so a template action

21:13 <Yorlik> Very dynamic data - can even be defined outside C++ on the Lua Side.

21:13 <hkaiser> see the template_function_accumulator example (https://github.com/STEllAR-GROUP/hpx/blob/master/examples/accumulators/server/template_function_accumulator.hpp)

21:14 <Yorlik> Imagine a user defines a message with a callback which takes arbitrary arguments

21:15 <Yorlik> I see - line 84 FF in the example. Thats one step at least.

21:16 <Yorlik> The Lua problem is special I need to think about that separately.

21:16 <Yorlik> Thanks for the link!

21:40 <Yorlik> hkaiser: Would serialization for a vector of std::variant work?

21:41 <hkaiser> hmmm

21:41 <hkaiser> sec

21:42 <hkaiser> Yorlik: by default we can only serialize boost::variant in HPX, iirc

21:43 <hkaiser> for std::variant you need to add a serialization function, see for instance here: https://github.com/STEllAR-GROUP/phylanx/blob/master/phylanx/util/serialization/variant.hpp

21:43 <Yorlik> OK. So - since I have to bridge between the madness of Lua and the strictness of C++ - going with boost::variant would hopefully allow me to do this halfway elegantly .. (Better than falling back to vectors of byte or sth ...)

21:43 <hkaiser> it should work if you replaced hpx::util::variant with std::variant

21:43 <Yorlik> OK - I'll do experiments.

21:43 <hkaiser> using std::variant will work as well

21:44 <hkaiser> I meant replace phylanx::util::varaint with std::variant in that code I linked

21:45 <hkaiser> in c++17 phylanx::util::variant == std::variant anyways

21:45 <Yorlik> We use C++17

21:45 <hkaiser> yah sure, I just wanted to say that we introduced our own variant to support things before c++17

21:45 <hkaiser> it's 100% conforming

21:47 <Yorlik> OK. I'll probably use Vectors or arrays of variant to send message arguments

21:47 <Yorlik> Maybe tuples - I'll have to see what works best

21:47 <hkaiser> right