00:05
LiliumAtratum has joined #ste||ar
00:06
<
LiliumAtratum >
@hkaiser, I have provided a more accurate and formally correct example for the hpx issue #4787. Unfortunately I see no option for me to reopen the issue. I would be grateful if you could have another look. Thanks!
00:07
<
LiliumAtratum >
that's the one with the noncommutative but associative operator for the transform_inclusive_scan
00:10
LiliumAtratum has quit [Remote host closed the connection]
00:10
<
K-ballo >
just do the string concatenation ones we already have...
00:36
kale[m] has quit [Ping timeout: 260 seconds]
00:36
kale[m] has joined #ste||ar
00:49
LiliumAtratum has joined #ste||ar
00:50
LiliumAtratum has quit [Remote host closed the connection]
01:18
<
weilewei >
it seems adding bidirectional ring algorithm in DCA will take only 75% time of original uni-directional runtime (60 ranks for 10 nodes situation)
01:20
<
weilewei >
more cleanup is needed, however...
02:05
RostamLog has joined #ste||ar
02:26
<
hkaiser >
weilewei: nice result!
02:26
<
weilewei >
hkaiser thanks!
03:01
hkaiser has quit [Quit: bye]
03:10
K-ballo1 has joined #ste||ar
03:11
K-ballo has quit [Ping timeout: 265 seconds]
03:11
K-ballo1 is now known as K-ballo
03:12
Yorlik has quit [Ping timeout: 260 seconds]
03:14
nanmiao11 has quit [Remote host closed the connection]
04:37
kale[m] has quit [Ping timeout: 260 seconds]
04:38
kale[m] has joined #ste||ar
05:38
bita__ has quit [Ping timeout: 260 seconds]
05:54
kale[m] has quit [Ping timeout: 244 seconds]
05:54
kale[m] has joined #ste||ar
06:03
nikunj97 has joined #ste||ar
06:06
Nikunj__ has joined #ste||ar
06:09
nikunj97 has quit [Ping timeout: 260 seconds]
06:16
kale[m] has quit [Ping timeout: 260 seconds]
06:17
kale[m] has joined #ste||ar
06:28
kale[m] has quit [Ping timeout: 240 seconds]
06:30
kale[m] has joined #ste||ar
07:31
kale[m] has quit [Ping timeout: 265 seconds]
07:34
kale[m] has joined #ste||ar
07:43
kale[m] has quit [Ping timeout: 256 seconds]
08:06
Nikunj__ has quit [Read error: Connection reset by peer]
08:07
Nikunj__ has joined #ste||ar
08:11
kale[m] has joined #ste||ar
08:15
nikunj97 has joined #ste||ar
08:19
Nikunj__ has quit [Ping timeout: 260 seconds]
08:58
hkaiser has joined #ste||ar
09:16
kale[m] has quit [Ping timeout: 246 seconds]
09:17
kale[m] has joined #ste||ar
09:22
kale[m] has quit [Ping timeout: 260 seconds]
09:22
kale[m] has joined #ste||ar
09:50
kale[m] has quit [Ping timeout: 260 seconds]
09:50
kale[m] has joined #ste||ar
09:53
<
gonidelis[m] >
Also as I am still getting familiar with the cluster, why can't I git fetch upstream?
09:55
kale[m] has quit [Ping timeout: 260 seconds]
09:55
kale[m] has joined #ste||ar
10:18
<
gonidelis[m] >
Also where is my .gitconfig file on the cluster? ... ahh I am confused
10:24
<
gonidelis[m] >
And lastly, does master compile for you guys?
10:32
<
ms[m] >
gonidelis: yes, things are compiling ok at least for me (and ci)
10:33
<
ms[m] >
is that the error you have up there? is that on master with a clean build directory?
10:39
<
gonidelis[m] >
ms[m]: thanks for your response... let me try with a clean build (it should take a while)
10:39
<
gonidelis[m] >
and speaking of "taking a while" do you know why can't I `git fetch upstream` on my rostam git repo?
10:39
<
gonidelis[m] >
this is what I get
10:59
<
ms[m] >
gonidelis: not sure what could be the problem there... does `git remote show upstream` show something useful?
10:59
<
ms[m] >
could be a firewall issue? is it only for upstream? does your the remote of your own fork work fine?
11:01
<
gonidelis[m] >
ahh my bad... i think origin is at stellar which mean I git cloned from stellar instead of my fork
11:01
<
gonidelis[m] >
I am sory
11:08
kale[m] has quit [Read error: Connection reset by peer]
11:09
kale[m] has joined #ste||ar
11:11
<
kale[m] >
Is highfive a necessary dependency of Phylanx ?
11:31
<
gonidelis[m] >
Do we know what's going on with the `is_deferred_callable` `deferred_result_of`warnings???
11:46
kale[m] has quit [Ping timeout: 240 seconds]
11:47
kale[m] has joined #ste||ar
12:28
kale[m] has quit [Ping timeout: 256 seconds]
12:28
kale[m] has joined #ste||ar
12:35
<
gonidelis[m] >
hkaiser: Should `is_sentinel_for` used in the other specializations (segmeneted and detail) except from here?
12:35
<
gonidelis[m] >
I reckon it should....
12:38
<
hkaiser >
kale[m]: it's optional
12:40
<
hkaiser >
gonidelis[m]: we should use it wherever a iterator/sentinel pair is supported
12:40
<
hkaiser >
I don't think we have adapted any of the segmented algorithms however
12:46
<
hkaiser >
looks like we need to adapt some of our links, however, the readme redirects to a different directory
12:51
<
gonidelis[m] >
hkaiser: oh ok.. I don't really know what segmented algos do...
12:51
<
hkaiser >
gonidelis[m]: they work with special containers that have their data segmented (partitioned), possibly across more than one HPX locality
12:54
<
gonidelis[m] >
wow great! Thank you :)
12:59
Yorlik has joined #ste||ar
13:18
<
hkaiser >
I wouldn't know where I should change that
13:20
<
hkaiser >
all I did was referring stellar-group.github.io to hpx-docs.stellar-group.org
13:20
<
hkaiser >
the fact that the old pages work using the new domain shows that the redirection is working
13:24
<
hkaiser >
ms[m]: where are those directories come from: hpx-docs/branches/?
13:24
<
ms[m] >
where is that set up? I see there's something in the github pages section on the hpx repo... can we do the same on the hpx-docs repo?
13:25
<
ms[m] >
I tried setting it there but get "The CNAME `hpx-docs.stellar-group.org` is already taken."
13:25
<
ms[m] >
the hpx-docs repo
13:25
<
hkaiser >
the redirection is done on the hpx-docs repo and on the site where stellar-group.org is hosted
13:26
<
ms[m] >
I see no custom domain on the hpx-docs repo...
13:27
<
hkaiser >
we have configured it on the wrong repository
13:30
<
ms[m] >
hkaiser: amazing! thanks :D
13:31
<
ms[m] >
I'll update the links
13:32
<
ms[m] >
they're nice and short now :)
13:43
akheir has joined #ste||ar
13:48
kale[m] has quit [Ping timeout: 265 seconds]
13:50
nanmiao11 has joined #ste||ar
13:58
kale[m] has joined #ste||ar
14:55
<
K-ballo >
hkaiser: I don't quite grasp the situation in #4786, too many things intertwined at once.. what's the divergence there?
14:56
<
hkaiser >
K-ballo: we believe the standard is wrong ;-)
14:56
<
K-ballo >
that seems to be only one part of it
14:56
<
K-ballo >
there's like 17 different concerns all at once
14:57
<
hkaiser >
if we could agree on how to interpret the standard everything should fall in place
14:58
<
hkaiser >
and then 2.3 saying that binary_op() should return something convertible to U
14:59
<
hkaiser >
there are two possible ways to fix this obvious mistake
14:59
<
hkaiser >
either say that U is decltype(*first) or decltype(unary_op(*first))
15:00
<
hkaiser >
msvc and clang apparently chose the latter
15:01
<
K-ballo >
U is iterator_traits<decltype(first)>::value_type
15:02
<
K-ballo >
the value_type of the iterator
15:02
<
hkaiser >
yes, that would be the first option
15:02
<
K-ballo >
not quite, but ok
15:02
<
K-ballo >
it's not a mistake
15:02
<
K-ballo >
the value type of the iterator is iterator_traits<Iter>::value_type
15:03
<
hkaiser >
I agree with that, but it says U should be decltype(first), i.e. the iterator type itself
15:03
<
K-ballo >
no no, it says U should be the
*value type* of decltype(first)
15:03
<
hkaiser >
missed that :/
15:03
<
K-ballo >
me too, subtle
15:04
<
hkaiser >
but then msvc and clang do it wrong
15:04
<
K-ballo >
what do they do?
15:05
<
hkaiser >
they assume U to be unary_op(value_type)
15:05
<
K-ballo >
how is that even observable?
15:05
<
hkaiser >
it wouldn't compile otherwise
15:06
<
hkaiser >
U is the type used for the internal accumulator variable
15:06
<
K-ballo >
how is that observable?
15:06
<
hkaiser >
it's not, but it wouldn't compile if it wasn't
15:06
<
K-ballo >
I don't follow
15:07
<
hkaiser >
if you use the value_type of first as the internal accumulator type, then binary_op has to return something convertible to it
15:07
kale[m] has quit [Ping timeout: 240 seconds]
15:08
<
hkaiser >
unary_op as well, btw
15:08
<
hkaiser >
but the code in the comment does not provide a conversion path from Integer to int
15:08
<
hkaiser >
compiles anyways
15:09
<
hkaiser >
the code in the comment can compile only if the accumulator value's type is whatever unary_op returns
15:12
<
weilewei >
hkaiser meeting today?
15:17
kale[m] has joined #ste||ar
15:31
<
K-ballo >
using the transformed type as accumulator is the only sensible interpretation, to be able to achieve what we wanted with the transform_* variants
15:32
<
hkaiser >
that's what I've implemented now
15:33
<
K-ballo >
"interpretation" in a very loose sense
15:33
<
hkaiser >
sure, I think we agree
15:34
<
hkaiser >
and msvc/clang agree as well
15:49
<
K-ballo >
hkaiser: I don't see reflected on the issue the fact that the binary predicate was being called twice for each pair
15:51
<
K-ballo >
reportedly, for every invocation of binary_op(x, y) there was also binary_op(y, x)
15:59
<
hkaiser >
K-ballo: who reported that?
16:13
<
K-ballo >
lithium something
16:14
<
zao >
`LiliumAtratum`
16:17
kale[m] has quit [Ping timeout: 240 seconds]
16:19
kale[m] has joined #ste||ar
16:30
<
hkaiser >
K-ballo: ok - for the parallel version this makes sense
16:30
<
hkaiser >
the sequential version should invoke binary_op exactly N times
16:31
<
hkaiser >
however the swapped arguments are a bug (fixed on that PR)
16:52
<
K-ballo >
LiliumAtratum, that's it, thanks zao
16:52
<
K-ballo >
let's get them to file an LWG issue
16:52
<
K-ballo >
the constrain was introduced by P0574
18:01
bita__ has joined #ste||ar
19:21
kale[m] has quit [Ping timeout: 260 seconds]
20:19
nikunj97 has quit [Ping timeout: 240 seconds]
22:00
kale[m] has joined #ste||ar
22:47
bita__ has quit [Ping timeout: 244 seconds]
23:55
nanmiao11 has quit [Ping timeout: 245 seconds]