00:08 <hkaiser> aacirino: sure

00:09 <hkaiser> what I meant is that you may have an older version of HPX built somewhere on your system and this is being picked up by the new build

00:22 <aacirino> hkaiser: I only have the build dir and the installed files in /usr/local/hpx

00:22 <aacirino> No other versions

00:22 <hkaiser> yah, remove the installed files before building HPX

00:23 <aacirino> I did remove the installed files, rebuilt it and am now waiting for the tests

00:24 <hkaiser> ok

01:18 <aacirino> Finally the tests run as intended. I don't understand what could have changed from my last attempt after cleaning everything to this outcome now. Maybe what I needed was a little incentive from you. I appreciate very much your help and time. Tomorrow I will resume my app build and report any issues I may have.

13:24 <zao> There is some ambiguity of which files will be preferred when using full includes like <hpx/foo/bar/baz.hpp> if you have headers in both a system location or one included via include path and also locally in your build tree. It depends greatly on the order and amount of spurious -I include directives on the compiler command line, and often appears due to some third party dependency being installed in such a location.

13:25 <zao> Say that f.ex. tcmalloc is installed in /usr/local; then the logic that detects and uses that might add -I/usr/local/include on the build command line, also pulling in unrelated headers into the search path.

13:25 <zao> A similar problem exists to some degree for library search paths and libraries.

13:26 <zao> This is incidentally why it's a great idea for control to install software into specific prefixes so that when you depend on it, only the relevant files will be pulled in and you have full control over what variants are used or even omitted if you want to make a build without some auto-detected library.

13:52 <K-ballo> it's best to not install anything at all to /usr/local

16:20 <gonidelis[m]> K-ballo: what could be a case where we would want `intrusive_ptr`s?

16:21 <K-ballo> gonidelis[m]: any of the ones in HPX? for example

16:21 <K-ballo> integrating external ref-counted pointers as well, things like COM

18:37 <gonidelis[m]> K-ballo: thanks! i just came across this header dependency graph of yours. this is amazing!

18:38 <gonidelis[m]> how could we use it? is there any way to simplify it? how do you produce it?

18:38 <gonidelis[m]> seems like new users could benefit from that

18:48 <K-ballo> the giant cloud one? I don't remember

18:48 <K-ballo> I had some scripts

18:51 <hkaiser> gonidelis[m]: use the cpp-dependencies tool

18:51 <hkaiser> https://github.com/tomtom-international/cpp-dependencies

18:51 <hkaiser> we use it to check for cyclic dependencies in one of the CIs

19:01 <K-ballo> i would run a serial -fsyntax-only build with whatever the flag is that dumps #includes (-M?)

19:01 <K-ballo> and then I had some python scripts that processed the output

20:03 <gonidelis[m]> if it's just for checking the cycling deps then the visualization is redundant, no?

20:11 <K-ballo> if you mean the giant cloud one, it was to show how (poorly) layered the framework was

20:15 <hkaiser> today the modules are free of cyclic dependencies

20:18 <K-ballo> that's great already, but far from robust layering

20:18 <K-ballo> although it's probably an important base for it

20:20 <gonidelis[m]> what does robust layering mean?

20:21 <K-ballo> ideally design-wise you'd see a high-level layer talking to a medium-level layer talking to a low-level layer and so on

20:22 <K-ballo> concrete "pockets" of abstraction that other abstractions build on top of

20:22 <K-ballo> instead of the promiscuous all-to-all the giant cloud depicts

20:23 <K-ballo> modules could be those layers, but the ones we have aren't

20:28 <hkaiser> yeah, the modules we have are too fine grain for that

20:44 <gonidelis[m]> oh

20:44 <gonidelis[m]> i would never think that "a clean picture" is also a "better software design"

20:44 <gonidelis[m]> sounds about right

20:48 <gonidelis[m]> what's `clear_container` for ? hkaiser

21:44 <aacirino> Resuming the talk about my issue with building HPX, I am finally able to run all the tests in both release and debug mode. But my app still has problems. A lot of template instantiations aren't being compiled, for instance

21:44 <aacirino> error: undefined symbol: build/linux/x86_64/release/libcryptobot.a(server.cpp.o): std::__1::vector<hpx::id_type, std::__1::allocator<hpx::id_type> >::~vector()

21:44 <aacirino> clang

21:45 <hkaiser> gonidelis[m]: it calls .clear() on it's argument if supported

21:53 <hkaiser> aacirino: not compiled or not linked?

22:01 <aacirino> Not linked, but template instantiation must be compiled to be available to the linker

22:01 <hkaiser> I'd expect so, yes

22:02 <hkaiser> what's missing is the destructor, that means that the type didn't get instatiated, but I'm ot sure, why - did you #include <vector> while compiling the TU?

22:02 <aacirino> I am about to start a clean install of my whole OS. I am about to move from Ubuntu to Fedora. If I am unable to solve this link issue in a couple of hours I will move to Fedora.

22:04 <K-ballo> there are no forward declarations of std::vector, nor any explicit template instantiations of vector<id_type> that I can see within hpx

22:04 <aacirino> This is the case of a build that was working until something was changed in my environment. I managed to use C++20 modules in my build, even HPX is a C++20 module for me. I am just importing the whole std and hpx as modules and it builds very well

22:08 <aacirino> K-ballo: there are cases where the application creates instances, like in the async_io_action.cpp example: std::vector<hpx::id_type> localities = hpx::find_remote_localities();

22:09 <K-ballo> in pre-modules world that TU would have its ~vector instantiation, as will all others

22:09 <hkaiser> aacirino: this sounds like an issue with c++20 modules - I have no extensive experience with using modules

22:09 <K-ballo> in modules world that's no longer the case

22:10 <K-ballo> me neither, who's responsible for instantiating in that case? can't be std, shouldn't be hpx, only the app "knows" both

22:14 <aacirino_> It is frustrating since my app was building and running just fine until some library or other update broke my enve

22:23 <aacirino1> I had a connection issue when answering and maybe I lost some of the messages. My frustration comes from the fact that my app was building and running as expected until something was updated in my development environment.

22:23 <hkaiser> sure, but how can we tell what happened?

22:26 <aacirino1> I can't, unfortunately. I can't say which update broke my environment. C++20 modules is working just fine for me. I have some libraries that I forked and build myself, like {fmt}, that I was able to put in a C++20 module following clang's module map guidelines.

22:27 <aacirino1> I just hoped that someone had this kind of issue and would give me some advice, since you guys have been working with HPX for a long time.

22:27 <hkaiser> aacirino1: would you be willing to share your HPX module files?

22:27 <aacirino1> Sure

22:27 <K-ballo> oh, this is clang's modules not 20's modules

22:28 <hkaiser> I can try whether something like your code fails for me as well

22:28 <aacirino1> C++20 modules with a module.modulemap file

22:28 <aacirino1> import hpx; works just fine

22:32 <aacirino1> https://www.sharenote.org/hpx-module-map-file

22:32 <hkaiser> ok, makes sense

22:32 <aacirino1> Put this module.modulemap file in the include dir and clang will compile it as a C++20 module

22:34 <aacirino1> I had to tweak some HPX headers to work with C++20 modules, like using import std; in three HPX headers I think

22:39 <aacirino1> Like this is what I added to the beginning of libs/core/plugin/include/hpx/plugin/detail/dll_dlopen.hpp

22:39 <aacirino1> https://www.sharenote.org/dll-dlopenhpp

22:40 <aacirino1> I define CPP20_MODULES in my build script and the headers will import std

22:40 <hkaiser> why was that necessary?

22:41 <aacirino1> It wouldn't compile since clang wouldn't find some classes from the standard library, like std::map I think

22:42 <aacirino1> I had to add the CPP20_MODULES test to libs/core/topology/include/hpx/topology/topology.hpp, libs/core/runtime_configuration/include/hpx/runtime_configuration/runtime_configuration.hpp and libs/core/plugin/include/hpx/plugin/detail/dll_dlopen.hpp

22:47 <hkaiser> thanks

22:48 <aacirino1> This is a very small example of a little program I created when learning HPX that uses C++20 modules

22:48 <aacirino1> https://www.sharenote.org/cpp20-module-example

23:04 <gonidelis[m]> `9. Verify that the Jenkins setups for the release branch on Rostam and Piz Daint are running and do not display any errors` ms hkaiser any idea where could i check that? do i just check the latest successful pr or sth?

23:06 <hkaiser> gonidelis[m]: you need to ask Alireza to give you access to https://rostam.cct.lsu.edu/jenkins/

23:06 <hkaiser> on Piz Daint only Mikael has access

23:09 <gonidelis[m]> αλριγητ

23:09 <gonidelis[m]> alright **