00:25 <Yorlik> hkaiser: I updated the links, but some macros are undocumented.

00:26 <Yorlik> I'll make an issue for them.

01:25 <hkaiser> parsa: yt?

01:28 <hkaiser> parsa: I'm done with the paper, nice work!

10:19 <jbjnr> hpx doesn't compile with apex turned on. hpx/runtime.hpp not found, what the correct way to set the include dirs with the new module setup?

12:49 <jbjnr> which module do I need to depend on to get hpx/traits/xxx.hpp

12:50 <jbjnr> I've had to add hpx_topology hpx_hardware hpx_timing hpx_allocator_support hpx_concurrency to apex so far, but I still have errors

12:50 <jbjnr> getting a bit tedious doing it one by one and looking for the right includes

13:00 <simbergm> jbjnr: add all of them for now

13:01 <simbergm> hpx/traits/xxx.hpp will generally be moving to modules that are related to those traits, i.e. there won't be one module with all traits

13:04 <simbergm> otherwise find is your friend

13:04 <simbergm> is this for apex?

13:04 <jbjnr> I've added all these hpx_algorithms hpx_assertion hpx_collectives hpx_config hpx_errors hpx_hashing hpx_logging hpx_preprocessor hpx_statistics hpx_timing

13:04 <jbjnr> hpx_allocator_support hpx_concurrency hpx_datastructures hpx_hardware hpx_iterator_support hpx_parallel_executors hpx_segmented_algorithms hpx_thread_support hpx_util

13:04 <jbjnr> hpx_cache hpx_concepts hpx_format hpx_type_support

13:04 <jbjnr>

13:04 <jbjnr> but it still does not pick up hpx/runtime.hpp

13:04 <jbjnr> this is a joke

13:04 <jbjnr> but not a funny one

13:05 <simbergm> of course not, because runtime.hpp isn't in a module

13:05 <simbergm> what are you trying to do?

13:05 <jbjnr> ok. I'll juat add the path by hand then

13:07 <simbergm> what are you trying to do?

13:08 <jbjnr> scroll up half a page, just trying to get apex to build with the new hpx structure

13:10 <rori> do you hpx_config also linked as a dependency to apex ?

13:12 <jbjnr> I've added al the modules and added the source root as an include dir

13:12 <jbjnr> it's building now. I've edited a bunch of apex files to get rid of deprecated headers. I'll do an aper PR once I'm happy with it

13:13 <jbjnr> ^apex

13:14 <rori> I already opened one 2 hours ago, but hasn't been merged yet

13:14 <jbjnr> who is rori?

13:14 <rori> But I hadn't the hpx/runtime.hpp pb which is weird

13:14 <rori> Auriane

13:14 <rori> sorry ^^

13:22 <simbergm> jbjnr: have you updated apex?

13:23 <simbergm> I can build with apex develop and hpx master right now

13:25 <jbjnr> well, I thought I was on develop, but in fact I'm on master. No wonder things are broken

13:36 <simbergm> jbjnr: working?

13:37 <jbjnr> link errors, but not module related

13:55 <rori> which ones ?

14:03 <hkaiser> simbergm: yt?

14:03 <simbergm> hkaiser: here

14:03 <hkaiser> hey

14:03 <K-ballo> hkaiser: here now too

14:03 <simbergm> what's up?

14:03 <hkaiser> may I suggest to add all boost headers we replace to the inspect #include check to avoid that those creep back in?

14:04 <simbergm> you may absolutely ;)

14:04 <simbergm> that's a good idea, thanks

14:06 <hkaiser> simbergm: well, you removed the filesystem stuff ;-)

14:06 <hkaiser> I'll handle the program options headers

14:06 <hkaiser> K-ballo: I had a question about util::function, but I forgot what it was :/

14:08 <simbergm> hkaiser: right, sorry for the cheeky answer... I'll take care of it as well

14:09 <simbergm> hkaiser: by the way, thanks for starting the program options pr! it's really appreciated

14:09 <simbergm> didn't expect to get you on board that easily

14:17 <hkaiser> heh

14:17 <hkaiser> thanks for your work

14:46 <jbjnr> rori: the link errors were cuda related. fixed them now

14:47 <rori> great!

14:50 <heller> So, where should the serialization module live? It would be awesome if it could have as little dependencies as possible in the end

14:59 <hkaiser> heller: what do you mean by 'where'?

15:17 <heller> hkaiser: in other words: how much dependencies should it have

15:18 <heller> hkaiser: where in the hierarchy that is

15:18 <hkaiser> none except for config and similar

15:18 <heller> Yeah

15:18 <heller> Going to be a tough one...

15:18 <hkaiser> I'm not sure how we should handle serialization of concrete types, like std::vector or util::any

15:19 <hkaiser> should this be in the serialization module or some other module collecting all kind of specific serialization helpers

15:19 <heller> I think it makes sense to handle std types

15:19 <heller> For other data structures, I have no idea

15:20 <heller> Both makes sense

15:21 <heller> The latter makes everything depend on serialization, which kind of defeats the purpose again

15:21 <heller> In some sense, at least

15:22 <hkaiser> is that a bad thing?

15:23 <hkaiser> gtg anywyas

15:24 <heller> Probably not a bad thing, indeed

15:26 <simbergm> heller: don't think it matters too much if they're separate or not; I slightly prefer separate

15:26 <simbergm> the dependency is there anyway, and we should prefer non-intrusive serialization over intrusive whenever possible

15:27 <simbergm> the hard part is the circular dependency on naming, id type and some other networking utilities

15:37 <heller> simbergm: yes, the id_type dependency is indeed the hardest part

15:37 <heller> Requires some hard thinking

15:37 <heller> And needs to be tested carefully

15:38 <heller> Especially at large scales with lots of credit splitting going on

16:44 <simbergm> USTOBRE: btw, how did it go last friday with parse? did you get somewhere with all the tooling?

16:45 <simbergm> everybody btw, USTOBRE is our gsod writer, please be nice to her!

16:46 <simbergm> *parsa

18:36 <nikunj> hkaiser: yt?

19:14 <Yorlik> Is add_hpx_library() documented anywhere?

19:21 <hkaiser> Yorlik: here

19:22 <Yorlik> Just looking at the HPX Cmake functions and missing docs

19:22 <Yorlik> There is just a really basiy hello world in the docs

19:22 <hkaiser> k

19:22 <Yorlik> This deserves a whole section, imo.

19:23 <Yorlik> ad_hpx_executable for example takes care nicely of installation setup

19:23 <hkaiser> nikunj here as well

19:27 <hkaiser> Yorlik: I agree

19:29 <Yorlik> hkaiser: Whenever you have time I'd be ready to do some more talking and documenting. I think I have enough open questions rteady.

19:39 <hkaiser> Yorlik: let's talk now, I have about 30 minutes

19:40 <Yorlik> Great

19:40 <hkaiser> appear.in?

19:40 <Yorlik> Yes - I'm already in :)

22:15 <maxwellr96> hkaiser: Did you write any tests or features which use distributed_matrix?

22:23 <hkaiser> maxwellr96: no

22:23 <hkaiser> ionly for distributed_vector

22:23 <hkaiser> distributed =_matrix is 98% similar to distributed_vector, however

22:24 <maxwellr96> Okay, I couldn't find any, and I'm getting unresolved external symbol errors when trying to use it

22:25 <maxwellr96> Stuff like this:

22:25 <maxwellr96> dist_dot_operation_double.obj : error LNK2019: unresolved external symbol "public: static int __cdecl hpx::traits::component_type_database<class phylanx::util::server::distributed_matrix_part<double>,void>::get(void)" (?get@?$component_type_database@V?$distributed_matrix_part@N@server@util@phylanx@@X@traits@hpx@@SAHXZ) referenced in function "int __cdecl hpx::components::get_component_type<class phylanx::util::server::distribu

22:25 <maxwellr96> ted_matrix_part<double> const >(void)" (??$get_component_type@$$CBV?$distributed_matrix_part@N@server@util@phylanx@@@components@hpx@@YAHXZ)

22:26 <diehlpk_work> hkaiser, you were write, they compile all paper by hand

22:26 <diehlpk_work> *right

22:26 <diehlpk_work> After they compiled ours, they forgot to update that it was compiled and they had to update it by hand again

23:27 <hkaiser> maxwellr96: uhh, let's look tomorrow, there is something missing/wrong