09:15 <ste||ar-github> [hpx] msimberg pushed 6 new commits to master: https://github.com/STEllAR-GROUP/hpx/compare/e880a1a2e8b2...090b5c2dca3b

09:15 <ste||ar-github> hpx/master b7811bb Christopher Hinz: Fix the BZip2 find module

09:15 <ste||ar-github> hpx/master 837ce74 Christopher Hinz: Remove the '_lib' suffix from all library targets...

09:15 <ste||ar-github> hpx/master 11fe5e5 Christopher Hinz: Remove the '_exe' suffix from all executable targets...

09:25 <zao> Hmm, doesn’t things collide if you strip suffixes?

09:38 <chinz07[m]> No. Since the target name without the suffix is used as part of other identifiers, it needs to be unique anyway.

09:40 <chinz07[m]> Without the suffixes CMake will at least complain if we have a collision instead of just overwriting another variable.

10:04 <zao> I was of the impression that they were there when you have non-hierarchical target names, but I may be mistaken of course :)

10:04 <ste||ar-github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://github.com/STEllAR-GROUP/hpx/commit/57f716d1eb9a287413425bef59791196ff7723ab

10:04 <ste||ar-github> hpx/gh-pages 57f716d StellarBot: Updating Sphinx docs

10:14 <chinz07[m]> I think the purpose of the hierarchical target names is organization and not disambiguation.

10:28 <zao> Oh well, as long as you've tested it on the weirdo toolchains (MSVC) and the flattening options :)

10:29 <zao> Just mentioning the past horrors around target naming.

10:30 <chinz07[m]> Which flattening options?

11:13 <simbergm> mmh, @chinz07:matrix.org we've had things like this in the past: https://github.com/STEllAR-GROUP/hpx/issues/3215

11:14 <simbergm> we don't really have the full hierarchical names on windows because of... reasons (that I don't fully understand)

11:14 <simbergm> if it turns out we have conflicts I think we can still manage by renaming targets

11:16 <chinz07[m]> Thanks. That might be a problem. In this case the pseudo targets might collide with the real target.

11:16 <simbergm> @chinz07:matrix.org: if you don't mind me asking, how come you're working on our cmake setup? (we love it!)

11:17 <simbergm> just a hobby or you're doing this for work?

11:45 <chinz07[m]> As I am employed as a physicist, I am unfortuntely not payed to program software. Even if we need it. So this is more a, very educational, hobby for me.

11:45 <chinz07[m]> Recently, HPX's build system has caused some problems and I thought it might be a good idea to fix these problems upstream. :-)

12:14 <simbergm> @chinz07:matrix.org: Thanks, that sounds great! It's always interesting to hear about people using hpx

12:14 <simbergm> qubus doesn't happen to be open-source, does it?

12:25 <chinz07[m]> ms: Not yet. I am currently cleaning up the code base. The quality of some parts is ... atrocious. Hopefully, I will have finished most of the refactoring by the end of the year. Afterwards, I will release the first beta.

12:31 <simbergm> sure, it's always like that :)

12:39 <chinz07[m]> Yes, the eternal companion of a software developer. Horrid code :) But we should still strive to do better IMHO.

12:40 <jbjnr__> we love chinz07[m] :)

12:40 <jbjnr__> Cleaning up our cmake is a great way to become popular

12:40 <chinz07[m]> Speaking of doing better. My build has finished. Back to work.

12:40 <chinz07[m]> :)

12:41 <zao> I compile scientific software for a living. You can't be _that_ bad compared to the competition.

12:43 <chinz07[m]> Yeah. Compared to some of the ancient Fortran 77 codes I have to maintain my code is probably the text-book example of good code.

12:44 <chinz07[m]> At least it does not dump all data into a single global array and uses goto to implement function calls.

12:46 <chinz07[m]> For me its a matter of professional pride not to plague others with my own mess.

13:17 <heller_> hkaiser: hey

15:39 <chinz07[m]> I am running into a problem with Boost. FindBoost does not support optional components prior to CMake 3.11. Since even the current LTS release of Ubuntu does not ship with CMake 3.11 or higher, I am on the fence. On one hand, it would be great to properly fix the Boost integration once and for all. On the other hand, CMake 3.11 is quite new and might not be readily available. Unfortuntely, the workarounds I have come up

15:39 <chinz07[m]> with are rather ugly and brittle.

15:39 <chinz07[m]> Any preferences?

15:43 <chinz07[m]> In addition, Boost.Iostreams is not installed as part of the CircleCI docker image. Since the process component, among others, depends on this library and is a mandatory part of HPX (?) the CI pipeline fails. Could somebody look into this please?

15:46 <chinz07[m]> HPX optionally depends on context, thread, log and regex.

16:02 <chinz07[m]> When I think about it, we could make all Boost libraries mandatory dependecies for CMake < 3.11 and make those four libraries optional otherwise. This would fix the problem without requiring a recent version of CMake. Somebody would just need to update the Docker image accordingly.

16:03 <jbjnr__> has anyone looked at the modular cmake enabled boost that in principle we could just clone on demand into a subdir of hpx?

16:03 <K-ballo> lol

16:03 <jbjnr__> (in our dreams)

16:03 <K-ballo> chinz07[m]: we don't actually require optional components, do we?

16:04 <jbjnr__> boost logging in the parcelport

16:04 <jbjnr__> but I could replace that with std::cout

16:04 <K-ballo> that doesn't exist, not my problem

16:04 <K-ballo> what I meant was..

16:04 <K-ballo> we don't make use of cmake's OPTIONAL COMPONENT facility, we do a QUIET check for just those components

16:04 <chinz07[m]> The runtime depends optionally on Boost.Context and Boost.Thread.

16:06 <chinz07[m]> This does not work unfortunetly if you use a target-based workflow. In this case the find module will not create all required targets.

16:08 <K-ballo> we can't really use target-based boost anyways, not before 11.3

16:10 <chinz07[m]> Why not? Even CMake 3.6 supports targets for Boost.

16:10 <K-ballo> only for the version of boosts that each cmake release knows about

16:11 <chinz07[m]> Sure, but if you want to use a recent version of Boost I think it might not be too much to ask to install a sufficiently recent version of CMake.

16:16 <K-ballo> so why is the 3.11 requirement a problem if there is already another requirement for 3.11 anyway?

16:16 <heller_> hkaiser: Hey, you pinged me yesterday?

16:20 <chinz07[m]> K-ballo: Sorry, you lost me. Which other requirement for 3.11?

16:20 <chinz07[m]> We only need CMake 3.11 if we want to support optional Boost dependencies for all versions of CMake. If we can make the "optional" libraries mandatory for CMake < 3.11 we only need to bump the version to 3.6 (or better 3.8).

16:22 <K-ballo> we only have this restriction due to wanting to use boost targets, which before 3.11 was heavily discouraged as it didn't work at all with non-known versions of boost

16:26 <K-ballo> how about we backport FindBoost.cmake from 3.11 ourselves?

16:27 <chinz07[m]> Has this changed with CMake 3.11? I haven't found anything about this in the release notes.

16:30 <chinz07[m]> Backporting might work, but somebody would have to maintain that version. In that case I would rather create one target for Boost manually from the old variables and just propagate all libraries to every downstream target for now. Not pretty but this would not increase the maintenance burden.

16:30 <K-ballo> yes, they started supporting boost targets for unknown versions using the latest dependency information

16:30 <K-ballo> my suggestion is to use a backported FindBoost.cmake pre 3.11, use theirs post

16:31 <K-ballo> else drop cmake < 3.11, I personally don't care but I know it's a rather hard requirement that might not fly

16:47 <heller_> chinz07[m]: so it's only about the targets?

16:49 <heller_> Is it really worth it to go for a modularized find boost considering that boost itself is monolithic anyways

16:58 <chinz07[m]> heller_: Yes. If we can use the targets for Boost, we can selectively choose to propagate the libraries to the downstream targets. Most Boost libraries are not used in HPX's interface and thus are not needed by them. If we are okay with a monolithic Boost, we can just create a single target for all required libraries.

16:58 <chinz07[m]> Personally, I would like to get rid of all the unnecessary dependencies in my projects. But maybe Boost is currently just too monolithic for this to work.

16:59 <hkaiser> heller_: thanks, I resolved it

17:31 <heller_> chinz07[m]: yes, and for hpx itself, it's currently not worth the effort either. I'd suggest to tackle the dependencies once we have our stuff under control

17:35 <chinz07[m]> heller_: Okay. That makes sense. I will add Boost as a single dependency. Somebody will still need to install Boost.Iostreams on the CI machines.

18:30 <simbergm> hkaiser, would you mind asking alireza to restart buildbot?

18:57 <heller_> chinz07[m]: how so?

19:04 <hkaiser> simbergm: will do

19:55 <maxwellr96> hkaiser numpy's vsplit function can copy data depending on what array of indexes is passed to it, do we want Phylanx's version to also be able to do that?

20:41 <chinz07[m]> heller_: The process component uses Boost.Iostreams and as far as I can determine, this library is not installed as part of the Docker image.

22:18 <mbremer> @hkaiser yt?

22:18 <hkaiser> mbremer: here

22:18 <mbremer> I'm trying to replicate the inheritance_2_classes_concrete with simple_components

22:19 <hkaiser> ok

22:19 <mbremer> and it's not working. I don't believe there is a relevant unit test

22:19 <hkaiser> sec

22:24 <hkaiser> mbremer: need a couple of minutes, sorry

22:24 <mbremer> No worries!

22:24 <mbremer> Let me know when you get back.

22:28 <hkaiser> mbremer: I'd expect for everything to work for simple components :/

22:29 <mbremer> Yeah, so here is the test

22:29 <mbremer> https://github.com/bremerm31/hpx_mwe/blob/master/src/inheritance_2_classes_concrete_simple.cpp

22:30 <hkaiser> mbremer: ok, I'll make it work, give me a day or so

22:30 <mbremer> The destructor flags don't seem to be flipped. (It also fails non-deterministically)

22:30 <mbremer> [max@peano build]$ ./inheritance_2_classes_concrete_simple --hpx:threads=1

22:30 <mbremer> /home/max/hpx_mwe/src/inheritance_2_classes_concrete_simple.cpp(130): test 'a_dtor' failed in function 'int hpx_startup::user_main()'

22:30 <mbremer> /home/max/hpx_mwe/src/inheritance_2_classes_concrete_simple.cpp(143): test 'a_dtor' failed in function 'int hpx_startup::user_main()'

22:30 <mbremer> /home/max/hpx_mwe/src/inheritance_2_classes_concrete_simple.cpp(144): test 'b_dtor' failed in function 'int hpx_startup::user_main()'

22:30 <mbremer> /home/max/hpx_mwe/src/inheritance_2_classes_concrete_simple.cpp(158): test 'b_dtor' failed in function 'int hpx_startup::user_main()'

22:30 <mbremer> /home/max/hpx_mwe/src/inheritance_2_classes_concrete_simple.cpp(157): test 'a_dtor' failed in function 'int hpx_startup::user_main()'

22:31 <mbremer> So that's how it's failing. I can open an issue, unless you see something immediately off that I should look into.

22:33 <hkaiser> mbremer: please create an issue

22:33 <mbremer> Will do!

22:34 <hkaiser> mbremer: I'll try to get to it asap, no promises, though ;-)

22:34 <mbremer> No worries! There are plenty of things for me to do XD. I appreciate you looking at it though.

23:03 <mbremer> @hkaiser: Issue submitted. I wonder if it's some kind of garbage collection issue, where the component still exists, even though the client has been destroyed. Anywho, I'll keep an eye on the issue. Thanks for taking a look.