01:17 <hkaiser> USTOBRE: yah, definitely typo

02:31 <USTOBRE> @hkaiser Thanks!

06:44 <simbergm> heller: hkaiser is it the name or the contents (or both) you're unhappy about? I realize now with your new branch that execution might be too broad of a name for the module that hkaiser is renaming so perhaps we should stick with executors after all (hkaiser is going to love renaming it again...)

06:44 <simbergm> I think we should try as much as possible to keep the local synchronization primitives in a separate module from execution_context or whatever yours ends up being called

07:08 <heller> simbergm: as I mentioned in the comments, each context will expose an executor

07:09 <heller> Each executor will return futures, each future needs a mutex and a condition variable

07:10 <heller> Without having them in one module, we end up with circular dependencies

07:13 <simbergm> heller: ok, let me catch up with the comments

07:39 <heller> simbergm: having this ability is IMHO a huge benefit

07:39 <heller> simbergm: the effect is: hpx::future can be used without an hpx thread

07:41 <heller> simbergm: also, new and different thread pools can be developed without any disruption

07:41 <heller> completely independent even

07:42 <heller> with a hopefully nice interface ;)

11:37 <jbjnr> heller: "each context will expose an executor" - currently we have lots and lots of executors. How does your statement above affect the current situation?

11:37 <jbjnr> is the executor that is exposed the "base" of any other executor for that context?

11:37 <heller> jbjnr: it doesn't

11:38 <heller> each context should have something like a default executor

11:38 <heller> but you can build other executors given a specific context

11:38 <heller> and a specific context can use resources

11:38 <jbjnr> ok, that's what I meant by "base"

11:39 <heller> yeah sure, any other executor uses that specific context to spawn new agents

11:39 <heller> so it's the context that is the "base" for those executors

11:40 <jbjnr> what sort of abstractions for affinity exist in the default executor?

11:40 <jbjnr> (I didn't look at the Pr)

11:40 <jbjnr> I guess none yet, cos the pr only handles the context

11:42 <heller> correct

11:47 <jbjnr> ok

11:47 <jbjnr> tks

13:57 <simbergm> heller: jbjnr should we still try to talk today? later in the evening?

14:00 <simbergm> hkaiser, aserio do you know if ali is aware of the state of rostam? this time it doesn't look like maintenance anymore...

14:00 <aserio> simbergm: ? what do you mean?

14:02 <jbjnr> simbergm: sorry. forgot all about it. I'm leaving in half an hour and stopping off at the pool. will be home about 7pm probably, could chat then, or maybe exchange emails over the weekend between the 3 of us

14:02 <simbergm> aserio: how does this look to you http://rostam.cct.lsu.edu/grid?

14:03 <simbergm> this week it hasn't even loaded pages every now and then (or it loads with page full of errors)

14:03 <simbergm> jbjnr: let's check again later, can't promise anything

14:03 <simbergm> but otherwise emails, yes

14:22 <maxwellr96> Does anyone know why when building blaze_tensor (master) it throws errors about including blaze_tensor/math/smp/openmp/DenseArray.h?

14:23 <maxwellr96> Was that removed, or is it that BLAZE_OPENMP_PARALLEL_MODE shouldn't be defined?

14:27 <hkaiser> right

14:27 <hkaiser> this file does not exist yet

14:28 <hkaiser> define BLAZE_PARALLEL_MODE to HPX (not sure what's the actual name is)

14:28 <hkaiser> maxwellr96: ^

14:32 <maxwellr96> Okay, is that set in CMake with like blaze_parallelization_mode?

14:33 <maxwellr96> hkaiser: ?

14:58 <hkaiser> yes, sec

14:58 <hkaiser> -DBLAZETENSOR_USE_HPX_THREADS=ON

14:59 <hkaiser> same for blaze (-DBLAZE_USE_HPX_THREADS=ON)

14:59 <hkaiser> sorry, its -DBLAZE_SMP_THREADS=HPX

15:19 <maxwellr96> Okay, thanks! That solved most of the errors, but I'm still getting one about 'posix_memalign' identifier not found, which appears to only occur if BLAZE_WIN64_PLATFORM is not defined. I'm building on windows, so it seems like that should be defined

15:20 <hkaiser> maxwellr96: ok, I was not aware of this

16:03 <simbergm> disks are full on rostam: http://rostam.cct.lsu.edu/builders/hpx_gcc_8_boost_1_69_centos_x86_64_release/builds/137/steps/git_pull/logs/stdio?

16:07 <hkaiser> simbergm: ok, thanks for the heads-up

16:08 <hkaiser> simbergm: akheir is onw here, he'll look into it

16:10 <akheir> simbergm: increased the storage to 1.5T /dev/mapper/rostam-buildbot 1.5T 1000G 501G 67% /buildbot

16:12 <simbergm> akheir: thank you!

16:13 <simbergm> I don't think we need to hold on to all the old data if cleaning things up would be better

16:13 <akheir> sorry it was my bad. I am a bit busy recently and the these notifications skip my radar.

16:14 <akheir> these are not old data. each build generate a lot of data

16:14 <akheir> they are just for last build

16:15 <akheir> buildbot has a database that stores some log files but those are not large

19:09 <simbergm> I wonder if we regressed in binary sizes...

19:17 <heller> simbergm: I think I like basic_execution and then a higher level module execution, which does what we have already

19:17 <heller> Sounds like a plan?

19:18 <heller> And in between we can have more stuff