spring[m] has quit [Read error: Connection reset by peer]
spring[m] has joined #ste||ar
Yorlik has quit [Ping timeout: 256 seconds]
diehlpk_work has quit [Remote host closed the connection]
nanmiao11 has quit [Remote host closed the connection]
hkaiser has quit [Quit: bye]
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
bita_ has quit [Ping timeout: 260 seconds]
akheir has quit [Quit: Leaving]
bita_ has joined #ste||ar
bita_ has quit [Ping timeout: 246 seconds]
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 240 seconds]
<jbjnr>
I just read that ref qualifiers article. very good. I didn't know about them either.
Yorlik has joined #ste||ar
mdiers has joined #ste||ar
mdiers[m] has joined #ste||ar
mdiers[m] has left #ste||ar [#ste||ar]
mdiers has quit [Remote host closed the connection]
kale[m] has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
<mdiers[m]>
Has anyone ever tried to use the 1.5.0-rc1 with the new intel compiler 19.1 (and -std=c++20)?
<jbjnr>
mdiers: I doubt anyone has bothered. We stopped supporting the intel compiler quite a while ago due to it's many problems. If they have finally switched to a clang based version then it might be worth trying again.
<ms[m]>
Not 19, but we do test prs with 18 I think
hkaiser has joined #ste||ar
<gonidelis[m]>
freenode_biddisco[m]: the one I sent yesterday?
<jbjnr>
yes
<gonidelis[m]>
indeed very helpful
<gonidelis[m]>
hkaiser: yt?
<hkaiser>
here
<gonidelis[m]>
I am lookin into this `transform_iteration` function. Could you explain what it's doing? I reckon it is applying transform on separate parts of the container? Maybe in order to be able to parallelize the whole thing?
<gonidelis[m]>
hkaiser:
<hkaiser>
yes
<gonidelis[m]>
!!!!
<hkaiser>
this (and the for_each_iteration) initially were just plain lambdas which we had to replace
<hkaiser>
NVidia's NVCC compiler was (and is) braindead at that time...
<gonidelis[m]>
hmm... ok that makes sense. 1. The difference with these functions and the segmented overloads is that the `*_iteration` ones are for CUDA and thus parallel computing while the segmented aim to distributed systems ? 2. I hear a lot of niggling around NVCC for quite a long time. What's the problem actually?
<gonidelis[m]>
hkaiser: ^^
<hkaiser>
no idea what's the problem with nvcc, not enough money, lack of competenct developers, who knows
<gonidelis[m]>
Any article where I can read about its bad reputation?
<gonidelis[m]>
or is it sth more like an inside opinion?
<gonidelis[m]>
(I am that curious because we were taught NVCC in my school and it is considered one of the most important classes in my school. The teacher praises it a lot and declares that "whoever works with cuda this semester shall have a free pass in the future market" ::shrug:: )
<hkaiser>
not sure if anybody has written about it, but if you ask anybody working with nvcc you will hear the same
<hkaiser>
also, wash[m] here works at nvidia, he might be able shed some light on the issue
diehlpk has joined #ste||ar
diehlpk_work has joined #ste||ar
kale[m] has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
weilewei has joined #ste||ar
akheir has joined #ste||ar
diehlpk has quit [Remote host closed the connection]
diehlpk has joined #ste||ar
nanmiao11 has joined #ste||ar
bita_ has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 264 seconds]
K-ballo1 is now known as K-ballo
diehlpk has quit [Ping timeout: 244 seconds]
<gonidelis[m]>
what is the usage of `util::detail::algorithm_result<>`
<gonidelis[m]>
I tried reading the src but didn't get it
<gonidelis[m]>
K-ballo: ok? and what does that mean in that particular case?
<K-ballo>
that ::get(pair(...)) call will return either a pair or a ready future<pair>, depending on policy
<gonidelis[m]>
oh okk thanks :)
<gonidelis[m]>
I have this initial API `transform` function which calls `function_()` and dispatches accordingly to the segmented or the non-segmented version
<tiagofg[m]>
hkaiser: I've tried but I don't know how to concatenate all __VA_ARGS__ to create the HPX_REGISTER_COMPONENT macro. In this case, this only work if __VA_ARGS__ size was 1. Do you have an alternative, or a solution, to create components with variadic templates?
<K-ballo>
there's another one
<tiagofg[m]>
K-ballo: hummm I don't know that, sorry
<tiagofg[m]>
K-ballo: You can't see my message because it's code? Here are no problem
<K-ballo>
we don't see them *inline*
<K-ballo>
"3:47:26 PM * tiagofg[m] sent a long message: <link here>"
<K-ballo>
and we need to click (if we are curious enough), and go see the message on a separate window, out of context
<tiagofg[m]>
what is the solution, btw?
<K-ballo>
no idea
<hkaiser>
tiagofg[m]: some recursive solution might do the trick
<tiagofg[m]>
Can you give me some tips? if you don't mind, I don't have much experience with macros.
<hkaiser>
the tiagofg[m]: boost preprocessor library has facilities for this
<hkaiser>
you can convert variadics into a BOOST_PP_SEQ which then can be enumerated
<K-ballo>
__VA_ARGS__ is variadic macros, not variadic templates
<gonidelis[m]>
when I adapt `transform_loop` like that I get an error which I just can't find where it comes from
<gonidelis[m]>
no matching function for call to ‘hpx::parallel::util::in_out_result<test::test_iterator<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, std::forward_iterator_tag>, __gnu_cxx::__normal_iterator<int*, std::vector<int> > >::in_out_result(std::remove_reference<test::test_iterator<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, std::forward_iterator_tag>&>::type,
<K-ballo>
that one is triggering aggregate initialization
<gonidelis[m]>
i thought that using {} was the same with using ()
<K-ballo>
it's not
<gonidelis[m]>
(ok yeah in certain cases)
kale[m] has quit [Ping timeout: 240 seconds]
<K-ballo>
in C++20 the parens would have worked for aggregate-init
<K-ballo>
btw in a return statement you don't need to repeat the type for aggregates, can just be return {in, out}
<K-ballo>
but it would not be return (in, out); not even in 20
<gonidelis[m]>
So the parens here are a function call and not an "aggregate-init".... ?
<K-ballo>
eh, not really... ugh, initialization in C++ is bonkers (google that)
<K-ballo>
the parents would be direct init, and the braces are direct list-init
<K-ballo>
init only considers constructors (before 20), list-init considers initializer_list constructors first, then constructors, then aggregates
<gonidelis[m]>
ok just a sec here... is aggregate-init the same thing with uniform init? (or even member-init-list ?)
<K-ballo>
no
<K-ballo>
also, unicorn init, uniform init is a lie
<K-ballo>
aggregate-init is losely speaking the kind of initialization that C has
<K-ballo>
were you put the elements of a struct or array within braces
<K-ballo>
it only works for aggregates, which very losely speaking is types without constructors
<gonidelis[m]>
ok ok I get the most of what you said. What are the aggregates actually?
<K-ballo>
the meaning of aggregate has changed in every single standard :P
<K-ballo>
conceptually, it's "just a bunch of things", that means it has no invariants, so it doesn't need constructors/destructors
kale[m] has joined #ste||ar
<gonidelis[m]>
hmmm ok...let me look into your messages once again from the scratch
<K-ballo>
in_out_result simply aggregates in and out
<K-ballo>
it bundles them together in a single place
<gonidelis[m]>
yeah I think that I am trully aware of that. have discussed a lot with mr.kaiser. you said "btw in a return statement you don't need to repeat the type for aggregates, can just be return {in, out}" ... but I think that what is returned here is the whole util::detail::algor_result::get() func
<gonidelis[m]>
std::random_access_iterator_tag]::<lambda(std::size_t, std::size_t)>]’, declared using local type ‘test_transform(ExPolicy, IteratorTag) [with ExPolicy = hpx::parallel::execution::parallel_policy; IteratorTag = std::random_access_iterator_tag]::<lambda(std::size_t, std::size_t)>’, is used but never defined [-fpermissive]`
<gonidelis[m]>
but have no idea what they are about....
<gonidelis[m]>
what's that path anyway?! ;p
<K-ballo>
<algorithm>
<gonidelis[m]>
hah?
<K-ballo>
`gcc/9.3.0/include/c++/9.3.0/bits/stl_algobase.h` is part of libstdc++'s <algorithm>
<gonidelis[m]>
ok I expect this to happen because I adapted only one out of the three overloads of `transform` (very unlikely)
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Read error: Connection reset by peer]
kale[m] has joined #ste||ar
<gonidelis[m]>
K-ballo: do you think that this could create a problem
<gonidelis[m]>
whell inside the parallel version it has an `auto f1 = transform_iteration<......` where this f1 is used inside the `get_in_ou_result()` right after
<gonidelis[m]>
But then again I need a function analogous to `get_in_out_result()`
<gonidelis[m]>
which is `get_in_in_out_result()` but I am sure what I 've done is quite a crappy implementation
<K-ballo>
all those functions should probably disappear in some near future
<gonidelis[m]>
K-ballo: ?
<gonidelis[m]>
the `get_*`s
<gonidelis[m]>
?
<K-ballo>
uhm, or maybe not, I may have misunderstood their purpose.. I thought it was about tagget tuples
<K-ballo>
*tagged
kale[m] has quit [Ping timeout: 256 seconds]
<gonidelis[m]>
ok So as you can see, in my `get_in_in_out_result()` I use `hpx::util::tuple_element` which I don't know if it's correct
<gonidelis[m]>
the problem though is that the compiler complains on `result_types.hpp:125:65: error: wrong number of template arguments (3, should be 2)`
<K-ballo>
what do the other get_ functions use?
<gonidelis[m]>
`hpx::util::tuple_element`
kale[m] has joined #ste||ar
<gonidelis[m]>
the other get function is about the `in_out_result`
<K-ballo>
then why wouldn't it be correct?
<gonidelis[m]>
don't know what it's doing, so don't know why it should be correct (or not)
<K-ballo>
:65? are you sure?
<gonidelis[m]>
:125
<gonidelis[m]>
ok just found it sorry
<gonidelis[m]>
I missed the` >::type ` closing on the second argument
<gonidelis[m]>
(didn't work :) )
<gonidelis[m]>
ok... but why does it say wrong number of arguments
<gonidelis[m]>
?
<gonidelis[m]>
`in_in_out_result` takes 3 arguments according to my impl...
<K-ballo>
try clang-format
<gonidelis[m]>
isn't it?
<K-ballo>
I'm sure there's more to that error message, and likely isn't talking about in_in_out_result but some other template
<gonidelis[m]>
can a tuple have a 2nd element? like 0,1,2?
<K-ballo>
sure
<K-ballo>
there are no arguments to a tuple in the code you mentioned
<gonidelis[m]>
you mean the get_in_in_out func?
<K-ballo>
start by looking at your error message, what is it actually telling you? extract from it all the information you can
<K-ballo>
that _should_ be enough, but if it isn't then try another compiler, different compilers have different varying diagnostics
<gonidelis[m]>
the same happens here though...
<K-ballo>
if that fails as well, then you can try clang-formatting the file, it would indent and align your code as seen by the compiler
<K-ballo>
if all that fails, then share the *actual* error message and the *actual* code that corresponds to the build
<gonidelis[m]>
I make tests.algorithms how could I change the compiler ? Should I have a completely different build dir which is cmake configured to use clang for example?
<K-ballo>
for cmake yes, you'd need separate builds for each compiler
<gonidelis[m]>
soo like... two build dirs looking in the same source file. is that right?
<K-ballo>
if you are not already building with clang, then clang-format is even better as it gets you clang diagnostics
kale[m] has quit [Ping timeout: 256 seconds]
<gonidelis[m]>
ok I will try that dual compiler trick. You are right. I ask questions a little bit more effortlessly than I should...
kale[m] has joined #ste||ar
weilewei has quit [Remote host closed the connection]