00:26
<
github >
hpx/serialization_access_data f15975d Hartmut Kaiser: Updating example to utilize buffering
00:27
<
github >
hpx/uninitialized_default_construct 302d17a Hartmut Kaiser: Adding uninitialized_default_construct and uninitialized_default_construct_n
00:28
<
github >
[hpx] hkaiser opened pull request #2669: Adding uninitialized_default_construct and uninitialized_default_construct_n (master...uninitialized_default_construct)
https://git.io/vHRPb
00:32
hkaiser has joined #ste||ar
00:32
hkaiser_ has quit [Read error: Connection reset by peer]
00:39
eschnett has joined #ste||ar
00:55
<
github >
hpx/fixing_2663 fb6da29 Hartmut Kaiser: Attempt to fix problem in managed_component_base
01:36
zbyerly_ has quit [Quit: Leaving]
02:11
K-ballo has quit [Quit: K-ballo]
02:17
EverYoung has quit [Ping timeout: 246 seconds]
02:21
hkaiser has quit [Quit: bye]
03:29
ajaivgeorge has joined #ste||ar
03:58
pree has joined #ste||ar
05:22
pree has quit [Ping timeout: 245 seconds]
05:24
pree has joined #ste||ar
05:49
jaafar has quit [Ping timeout: 246 seconds]
06:41
Matombo has joined #ste||ar
07:28
bikineev has joined #ste||ar
07:31
Matombo has quit [Remote host closed the connection]
07:39
ajaivgeorge has quit [Quit: ajaivgeorge]
08:17
david_pfander has joined #ste||ar
08:55
bikineev has quit [Remote host closed the connection]
09:02
bikineev has joined #ste||ar
09:06
bikineev has quit [Remote host closed the connection]
09:26
bikineev has joined #ste||ar
09:43
bikineev has quit [Remote host closed the connection]
10:01
mcopik has quit [Ping timeout: 245 seconds]
10:38
K-ballo has joined #ste||ar
11:19
pree has quit [Ping timeout: 245 seconds]
11:34
bikineev has joined #ste||ar
12:05
hkaiser has joined #ste||ar
12:06
eschnett has quit [Quit: eschnett]
12:09
<
github >
[hpx] hkaiser closed pull request #2633: Distributed define_spmd_block (master...lcos_define_spmd_block)
https://git.io/v9NYA
12:22
mcopik has joined #ste||ar
12:29
<
heller_ >
hkaiser: 'morning
12:29
<
heller_ >
hkaiser: any idea about the failing resource manager test?
12:29
<
hkaiser >
heller_: have not looked yet
12:29
<
heller_ >
we need more reviewers ;)
12:31
<
heller_ >
and faster testing ...
12:32
bikineev has quit [Ping timeout: 258 seconds]
13:06
eschnett has joined #ste||ar
13:12
pree has joined #ste||ar
13:12
patg_ has joined #ste||ar
13:18
patg_ has quit [Quit: See you later]
13:46
aserio has joined #ste||ar
13:59
<
aserio >
david_pfander, heller_, hkaiser, jbjnr, parsa[[[w]]], wash[m]: Op. Bell Meeting
14:36
<
aserio >
heller_: how is writing going?
14:58
akheir has joined #ste||ar
14:58
akheir has quit [Remote host closed the connection]
14:59
<
heller_ >
aserio: Bad
14:59
<
heller_ >
aserio: I was attending a prace exascale meeting today...
15:00
<
heller_ >
Those guys are dragging me into politics :(
15:00
<
aserio >
heller_:
*slap*
15:01
hkaiser has quit [Quit: bye]
15:03
akheir has joined #ste||ar
15:10
<
zao >
Burn it all down!
15:20
<
heller_ >
aserio: I have a 5 hour train ride in front of me
15:21
<
aserio >
heller_: how many pages will you write?
15:26
Matombo has joined #ste||ar
15:30
pree has quit [Ping timeout: 258 seconds]
15:31
<
heller_ >
aserio: over 9000
15:31
<
heller_ >
aserio: between 150 and 250
15:33
pree has joined #ste||ar
15:39
EverYoung has joined #ste||ar
15:39
EverYoung has quit [Remote host closed the connection]
15:40
EverYoung has joined #ste||ar
15:41
bikineev has joined #ste||ar
15:43
arashamini has joined #ste||ar
15:43
arashamini has quit [Client Quit]
15:49
hkaiser has joined #ste||ar
15:56
EverYoung has quit [Ping timeout: 245 seconds]
15:56
hkaiser has quit [Quit: bye]
15:59
EverYoung has joined #ste||ar
15:59
EverYoung has quit [Remote host closed the connection]
16:00
EverYoung has joined #ste||ar
16:15
bikineev_ has joined #ste||ar
16:17
bikineev has quit [Ping timeout: 240 seconds]
16:27
david_pfander has quit [Ping timeout: 255 seconds]
16:42
jaafar has joined #ste||ar
16:46
<
github >
[hpx] atrantan opened pull request #2670: Integrate spmd multidimensionnal views for partitioned_vectors (master...partitioned_vector_view)
https://git.io/vHEmT
16:47
bikineev_ has quit [Ping timeout: 245 seconds]
16:56
EverYoung has quit [Remote host closed the connection]
16:56
EverYoung has joined #ste||ar
16:59
<
github >
hpx/invoke 1fad75e Agustin K-ballo Berge: Add C++11 range utilities
16:59
<
github >
hpx/invoke 35efa08 Agustin K-ballo Berge: Cleanup acquire traits, replace boost::range with util/range in their implementation, patch broken whens
16:59
<
github >
hpx/invoke ce30c7f Agustin K-ballo Berge: Replace core boost::range with util/range, remove redundant parallel traits
16:59
<
K-ballo >
ugh.. bad base
16:59
EverYoun_ has joined #ste||ar
17:02
EverYoung has quit [Ping timeout: 258 seconds]
17:05
<
github >
hpx/invoke 9bcc896 Agustin K-ballo Berge: Provide and use C++17 is_invocable[_r] forms
17:05
<
github >
hpx/invoke 87c0159 Agustin K-ballo Berge: Provide and use C++17 invoke_result forms
17:05
<
github >
hpx/invoke 06e028f Agustin K-ballo Berge: Remove obsolete SFINAE workaround
17:07
<
pree >
Maybe I have a different notion of distribution policies for components. Because I haven't thought of using performance counters for the distribution policies , what I actually thought is creating components in cyclic manner as such in default_layout. Why performance counter comes into play in policies ?
17:07
bikineev has joined #ste||ar
17:21
<
heller_ >
pree: should be configurable
17:21
<
pree >
In runtime sense ?
17:22
<
heller_ >
pree: you could place components on the locality that is the least busy
17:22
<
heller_ >
So you get automatic load balancing, of some sorts
17:23
bikineev_ has joined #ste||ar
17:24
bikineev has quit [Ping timeout: 268 seconds]
17:25
<
pree >
so taking care at runtime of creating components and not distributing or migrating ? I guess
17:26
<
heller_ >
The distribution policies do distribute the components. You just decide dynamically where to place them
17:27
<
pree >
okay thank you @ heller.
17:32
hkaiser has joined #ste||ar
17:32
bikineev has joined #ste||ar
17:32
bikineev_ has quit [Ping timeout: 255 seconds]
17:54
<
github >
hpx/uninitialized_default_construct 56d66b1 Hartmut Kaiser: Adding missing #include
17:56
<
K-ballo >
is it a bad line-end?
17:56
<
K-ballo >
I bet is a bad line end
17:57
<
github >
hpx/inspect_addressof 2c85183 Hartmut Kaiser: Adding include check for std::addressof
17:59
<
github >
hpx/fixing_vcpkg ec0c6ef Hartmut Kaiser: Fixing linker problems when HPX is built using vcpkg
18:03
<
hkaiser >
K-ballo: bug in inspect?
18:04
<
K-ballo >
yeah, the same old one, it's a windows line end \n\r
18:04
<
K-ballo >
so on windows that line has "trailing whitespace"
18:04
<
K-ballo >
err, other way around? \r\n
18:11
<
hkaiser >
K-ballo: after reading the file there shouldn't be any \r in the string anymore
18:12
hkaiser_ has joined #ste||ar
18:12
hkaiser has quit [Read error: Connection reset by peer]
18:18
<
github >
hpx/uninitialized_value_construct 15f12c2 Hartmut Kaiser: Adding uninitialized_value_construct and uninitialized_value_construct_n
18:31
<
K-ballo >
hkaiser_: there shouldn't? then I don't know why that isn't flagged on linux, it is on windows
18:31
<
K-ballo >
that and about 30 too long lines as well
18:32
<
K-ballo >
one of the gsoc students (I think) also run into it a few days ago
18:36
<
hkaiser_ >
K-ballo: ok, then the file isn't read in text mode
18:37
<
heller_ >
hkaiser_: -fstack-protector gets confused with our context switches. some distributions ship with that flag being on by default.
18:37
<
heller_ >
shouldn't git also "fix" the different line endings?
18:37
<
hkaiser_ >
heller_: it does, that's exatly the problem ;)
18:38
<
hkaiser_ >
heller_: ok, should we set -fstack-protector=off always?
18:38
<
heller_ >
I am especially dense right now, so I just shut up ;)
18:38
<
K-ballo >
the files aren't read in text mode, no, it's explicitly open as binary for some reason
18:39
<
K-ballo >
all the way from the initial commit in boost it's been that way, no clue as to why
18:39
<
heller_ >
hkaiser_: I would rather document it explicitly, IIUC, it is only gentoo who does that (and nobody should use that anyway :P)
18:39
<
github >
hpx/uninitialized_default_construct 848bfc0 Hartmut Kaiser: Adding more test cases
18:39
<
heller_ >
hkaiser_: let's see what he responds
18:39
<
hkaiser_ >
heller_: did you respond on the ML?
18:39
<
heller_ >
hkaiser_: I did
18:39
<
hkaiser_ >
I have not seen any email
18:40
<
heller_ >
hkaiser_: slow train wifi ...
18:41
<
heller_ >
oh crap. all my mails I was sending today are still in my local queue, and I was wondering why I didn't get replies :(
18:42
<
heller_ >
hkaiser_: here is something to cheer you up
18:42
<
heller_ >
hkaiser_: I was at this PRACE exascale planning meeting today, and guess what
18:42
<
heller_ >
hkaiser_: HPX is a finally a thing
18:42
<
github >
hpx/uninitialized_value_construct 353e594 Hartmut Kaiser: Adding uninitialized_value_construct and uninitialized_value_construct_n
18:43
<
hkaiser_ >
heller_: yah?
18:43
<
hkaiser_ >
how do you know?
18:43
<
heller_ >
well, it is recognized as one of the solutions to the problem ;)
18:44
<
heller_ >
because I was sitting in the sessions?
18:44
<
hkaiser_ >
good good
18:44
<
heller_ >
and gave a talk...
18:44
<
heller_ >
not sure if it is good or not, yet ;)
18:46
<
hkaiser_ >
heller_: as long as they spell it right I don't care ;)
18:46
<
heller_ >
how can you spell HPX wrong?
18:47
<
hkaiser_ >
you could write it as hpx5 or so...
18:47
ArashA has joined #ste||ar
18:47
ArashA has quit [Client Quit]
18:47
denis_blank has joined #ste||ar
18:47
<
heller_ >
sure, you could also write covefefe
18:48
<
heller_ >
as far as the EC is concerend, HPX had its version 1.0 released a few weeks ago ;)
18:49
<
github >
hpx/uninitialized_value_construct a333ef7 Hartmut Kaiser: Add documentation support
18:50
<
github >
[hpx] hkaiser opened pull request #2671: Adding uninitialized_value_construct and uninitialized_value_construct_n (master...uninitialized_value_construct)
https://git.io/vHE2L
18:51
<
hkaiser_ >
heller_: do you see now how impoartant that was?
18:52
<
heller_ >
I never doubted the importance, I just don't like the fact that you need it ;)
18:53
<
github >
hpx/serialization_access_data 6335a35 Hartmut Kaiser: Updating example to utilize buffering
18:55
Matombo has quit [Remote host closed the connection]
19:04
aserio has quit [Ping timeout: 260 seconds]
19:06
aserio has joined #ste||ar
19:09
<
github >
hpx/master 9085f6b Denis Blank: Add documentation to hpx::util::unwrapped and hpx::util::unwrapped2....
19:09
<
github >
hpx/master a12045d Hartmut Kaiser: Merge pull request #2660 from Naios/unwrap_doc...
19:27
bikineev has quit [Remote host closed the connection]
19:27
pree has quit [Ping timeout: 258 seconds]
19:45
hkaiser_ has quit [Read error: Connection reset by peer]
19:52
bikineev has joined #ste||ar
19:55
hkaiser has joined #ste||ar
19:59
bikineev has quit [Remote host closed the connection]
20:01
bikineev has joined #ste||ar
20:07
hkaiser has quit [Quit: bye]
20:13
bikineev has quit [Remote host closed the connection]
20:21
eschnett has quit [Quit: eschnett]
20:23
eschnett has joined #ste||ar
20:48
denis_blank has quit [Quit: denis_blank]
20:59
bikineev has joined #ste||ar
21:03
hkaiser has joined #ste||ar
21:06
<
K-ballo >
^ there's a considerable number of mechanical changes in that PR, could use extra pair of eyes
21:07
<
hkaiser >
K-ballo: ok
21:07
<
hkaiser >
K-ballo: we have an interesting problem with our future implementaton, btw
21:07
<
K-ballo >
I actually meant it for the general public, I expect you to look at it regardless :P
21:08
<
K-ballo >
what's with the future?
21:08
<
hkaiser >
K-ballo: future<future<void>> --> future<void> does the right thing (it unwraps)
21:08
<
hkaiser >
but future<future<T>> --> future<void> is currently enabled and does the wrong thing
21:08
<
hkaiser >
it discard the inner future
21:09
<
K-ballo >
I can imagine that
21:10
<
hkaiser >
K-ballo: I'm considering either completely deleting this conversion or at least make it explicit
21:10
<
hkaiser >
but deleting is probably the correct thing as this involves 2 conversion steps
21:11
<
K-ballo >
either sounds good
21:11
<
K-ballo >
it involves 2 steps?
21:11
<
hkaiser >
future<future<T>> --> future<T> --> future<void>
21:11
<
K-ballo >
you mean to just delete `future<future<T>>` overload?
21:11
<
hkaiser >
yes, if the target is future<void>
21:12
<
hkaiser >
and if T != void
21:12
<
K-ballo >
ah, I thought remove it completely.. let me think
21:16
<
K-ballo >
what happens if you just disable the -> void converting constructor for the future<future<T>> source?
21:16
<
hkaiser >
that's what that does (I think)
21:17
<
K-ballo >
no, not exactly, this one "wins" to the converting constructor
21:18
<
K-ballo >
where's the converting constructor now?
21:18
<
hkaiser >
still there
21:19
<
hkaiser >
unchanged
21:19
<
K-ballo >
`std::is_void<R>::value && !detail::is_future<T>::value` is what I was asking about
21:19
<
K-ballo >
that should still allow implicit unwrapping?
21:19
<
hkaiser >
K-ballo: hmm, sorry you lost me
21:20
<
hkaiser >
if I add the two deleted constructors everything seems to work fine
21:20
<
hkaiser >
K-ballo: ok, I see now what you mean
21:21
<
hkaiser >
yes, that should work as well
21:21
<
K-ballo >
the unwrapping constructors are not templates, might work
21:21
<
K-ballo >
unwrapping constructor might trump =deleted, which in turn would win to -> void
21:22
jaafar has quit [Quit: Konversation terminated!]
21:22
jaafar has joined #ste||ar
21:23
<
hkaiser >
K-ballo: yah, that was my reasoning
21:23
<
hkaiser >
but doing what you suggest is simpler
21:23
<
hkaiser >
and the error message (msvc) is better as well ;)
21:26
aserio has quit [Quit: aserio]
21:44
<
github >
hpx/fixing_2667 84d6663 Hartmut Kaiser: Inhibit direct conversion from future<future<T>> --> future<void>...
21:45
<
github >
[hpx] hkaiser opened pull request #2673: Inhibit direct conversion from future<future<T>> --> future<void> (master...fixing_2667)
https://git.io/vHuec
21:47
<
github >
hpx/fixing_2667 e3de252 Hartmut Kaiser: Inhibit direct conversion from future<future<T>> --> future<void>...
21:55
<
hkaiser >
K-ballo: can we assume that is_callable etc was not used by applications?
21:56
<
K-ballo >
not really, but it's not documented so we are within our rights to remove it (although as a courtesy I didn't)
21:56
<
hkaiser >
K-ballo: ok
21:57
<
K-ballo >
I'll plan to revisit later and deprecate, and even later remove
22:03
Matombo has joined #ste||ar
22:11
<
github >
hpx/uninitialized_default_construct 2ae58c9 Hartmut Kaiser: Adding more test cases
22:13
<
github >
hpx/fixing_2667 887cc42 Hartmut Kaiser: Inhibit direct conversion from future<future<T>> --> future<void>...
22:15
<
hkaiser >
K-ballo: if is_callable etc is stil available, could you add those to inspect to make sure they don't sneak back in?
22:15
<
K-ballo >
it's not even deprecated yet, but sure I'll add it
22:16
<
hkaiser >
nod, thanks
22:16
<
hkaiser >
saves you a lot of trouble with older branches
22:35
hkaiser has quit [Read error: Connection reset by peer]
22:51
Matombo has quit [Remote host closed the connection]
22:52
Matombo has joined #ste||ar
22:58
hkaiser has joined #ste||ar
23:31
<
K-ballo >
hkaiser: how do I check for it, since it may not always be fully qualified?
23:38
Matombo has quit [Remote host closed the connection]
23:42
EverYoun_ has quit [Ping timeout: 245 seconds]
23:47
EverYoung has joined #ste||ar
23:47
EverYoung has quit [Remote host closed the connection]
23:48
EverYoung has joined #ste||ar
23:53
eschnett has quit [Quit: eschnett]