K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
<gnikunj[m]>
@hkaiser : not yet
diehlpk_work has quit [Remote host closed the connection]
<rori>
<gonidelis[m] "plus, haven't we bumped the mini"> This is the docs related to the last release, have a look at master docs ;)
<gonidelis[m]>
rori: thanks !
K-ballo has joined #ste||ar
<gonidelis[m]>
K-ballo: where could I find the constraints, if any, of the `|` operator usage on range-v3? I mean, could I just chain a whatever X view with a whatever Y view? shouldn't there be requirements?
<K-ballo>
requirements will be specified by whichever Y range adaptor object you are using
<K-ballo>
| for range adaptor objects is just equivalent to a function call, and that function call is usually equivalent to some view construction, so requirements usually come from the particular view
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<jedi18[m]>
@hk
<hkaiser>
hey jedi18[m]
<jedi18[m]>
hkaiser: I've shared my initial draft on gsoc proposal, would really appreciate it if you could review it, thanks!
<hkaiser>
jedi18[m]: ok, thanks
<hkaiser>
when is the deadline, btw?
<jedi18[m]>
13th April
<hkaiser>
cool
<jedi18[m]>
Btw should I also add stretch goals in the proposal? (stuff I want to work on if I finish my work early)
<hkaiser>
jedi18[m]: doesn't hurt ;-)
<jedi18[m]>
Ok, thanks :)
<gonidelis[m]>
K-ballo: adaptors provide views? and by adaptor we mean `ranges::views::transform()` for exapmle?
<K-ballo>
I said "range adaptor objects"
<K-ballo>
and they *usually* construct views
<K-ballo>
`ranges::views::transform` constructs a `transform_view`
<gonidelis[m]>
and is a range adaptor object
<K-ballo>
yes
<gonidelis[m]>
so for `ranges::views::zip(x,y) | ranges::views::transform(mult)` it is the `transform()` obj. adaptor AND the `mult` arg that specify if the pipe is valid
<gonidelis[m]>
K-ballo: right?
<hkaiser>
gonidelis[m]: conceptually, range adaptors are still ranges, they support std::begin/std::end
<K-ballo>
and whatever `ranges::view::zip(x,y)` yields
<K-ballo>
is that what passes as "docs" for ranges-v3?
<K-ballo>
eric wasn't kidding about writing docs
<gonidelis[m]>
K-ballo: people who hate docs are just normal people
<gonidelis[m]>
hate writing*
<K-ballo>
you can see the cause of the error from the error message snippet, but probably is clear in the rest of the stack
<K-ballo>
you can always desugar the call, to reduce the complexity of the message by skipping all those layers
<K-ballo>
you should in theory get even clearer reports if you enable real concepts (although that remains to be seen...)
<gonidelis[m]>
<K-ballo "you can see the cause of the err"> what do you mean? look beyond the error lines i posted to you?
<gonidelis[m]>
<K-ballo "you should in theory get even cl"> do range-v3 use concepts? so in practice i use some contemporary experimental compiler version?
<gonidelis[m]>
wow... they do use concepts.
<K-ballo>
no need for experimental versions, latest msvc/gcc should do it, clang I believe is lacking a bit on the library side
<gonidelis[m]>
K-ballo: actually aren't concepts written inside range-v3? like, i don't need a compiler's stdlib.h if range-v3 already provides them for me
<K-ballo>
the standard library concepts were defined based on range-v3 faux ones, so it's not entirely surprising they support them
<ms[m]1>
pedro_barbosa: CUDA versions have specific requirements on which GCC versions they can be used with (not too old, not too recent)
<K-ballo>
if range-v3 only uses concepts it defines itself, then you don't need other concepts, sure
<K-ballo>
whether ranges-v3 does that or not, no idea
<ms[m]1>
if you have the correct gcc available you would set -DCMAKE_CXX_COMPILER=<path_to_your_gcc>
<K-ballo>
in general, I've only had trouble using concepts with latest clang, things tend to work fine with msvc/gcc
<pedro_barbosa[m]>
<ms[m]1 "if you have the correct gcc avai"> I was able to use the current versions to install the 1.6 version, thought it would still work for 1.5.1
<gonidelis[m]>
K-ballo: range-v3 wouldn't be compilable without proper compiler support in other case
<gonidelis[m]>
i am just avoiding chaning the compiler here...
<K-ballo>
I don't know what that means
<jbjnr>
ms: where did you say was a good example to look at at the correct (modern) CPO implementation ... I am quickly skimming through the parallel algorithms but not seeing the wood for the trees ...
<jbjnr>
^example of - (as simple as poss for copying to other places)
<ms[m]1>
pedro_barbosa: if you're really using the same compiler versions that would be a bug, but both 1.5.1 and 1.6.0 should compile with the same cuda/gcc versions (as far as I remember)
<pedro_barbosa[m]>
I think I was able to install version 1.5.1 with these CUDA and GCC versions before, going to try again without using the -DHPX_WITH_PARCELPORT_MPI=ON flag
<K-ballo>
the C++20 library concepts are based on his range-v3 work, yes
<ms[m]1>
pedro_barbosa: cuda 10 only supports gcc up to and including version 8, so if you managed to use those versions before I'd be surprised...
<K-ballo>
which were based on the palo alto tr, which in turn was based on stepanov early work
<gonidelis[m]>
K-ballo: exactly, so do we expect to have concepts that do not exist in range-v3? i could expect the opposite, yes. but c++20 concepts are a subset of range-v3
<K-ballo>
I would not expect the c++20 concepts to be a subset of those of range-v3, not at all
<gonidelis[m]>
ah... you greedy ones added more. i see
<pedro_barbosa[m]>
<ms[m]1 "pedro_barbosa: cuda 10 only supp"> It's what I've been using with the 1.6 version, not sure why it worked, maybe I updated the GCC version without noticing
<K-ballo>
or just standardization differences
<K-ballo>
that's how the standardization process usually goes
<gonidelis[m]>
hm... yeah ok. true
<gonidelis[m]>
range-v3 should compile with compilers prior to c++20, that's the goal i think. c++20 shouldn't
<gonidelis[m]>
c++20 ranges/concepts
<K-ballo>
just by glancing at the docs, I can see ranges kept all the original concept namings, whereas standardization changed them
<gonidelis[m]>
K-ballo: back to subject, i think that answers the view_closure question
<K-ballo>
it's impossible to tell whether view_closure is a range-v3 internal implementation detail, or a user facing interface lacking docs
nanmiao has joined #ste||ar
<gonidelis[m]>
thanks eric
<jbjnr>
@,s - thanks. I will digest - should have been @ms - thanks. I will digest
<jbjnr>
* @,s - thanks. I will digest - should have been ms - thanks. I will digest
diehlpk_work has joined #ste||ar
shubham has joined #ste||ar
<pedro_barbosa[m]>
I used these 2 exports (export CC=/usr/bin/gcc-8 & export CXX=/usr/bin/g++-8) in order to install hpx 1.5.1, but now whenever I try to build a project it says that I should use the same version I used in the HPX build (the default gcc version is 9.3.0). I tried adding (set(HPX_CXX_COMPILER=/usr/bin/g++-8)) and similar lines to the CMakeLists.txt file but it doesn't seem to work. Anyone knows what I need to do to fix
<pedro_barbosa[m]>
it?
<K-ballo>
you need those two exports before configuring your cmake build for the first time
nanmiao has quit [Quit: Connection closed]
<pedro_barbosa[m]>
yeah I set the exports and get the same error
<K-ballo>
if you get the same error it means cmake is not picking those compilers, which means you aren't actually setting those variables, it's not the first build configuration, or you are messing with the toolchain in some other way
<K-ballo>
(by variables I mean environment variables, export)
<pedro_barbosa[m]>
I forgot to delete a file from a previous build, thanks
<pedro_barbosa[m]>
but shouldn't I be able to set the compiler via the cmake file?
<K-ballo>
no, no no no no
<K-ballo>
the project can't choose the toolchain
<K-ballo>
the toolchain could try and set the toolchain, but that doesn't make a lot of sense either
<pedro_barbosa[m]>
Ok I'll keep that in mind, thank you
<K-ballo>
although in a sense, when you set CC/CXX, you are instructing the default toolchain to use those specific compilers (and related utilities)
<K-ballo>
also for completeness, it would have been `set(foo bar)`, `set(foo=bar)` is un-setting a variable named `foo=bar`
<pedro_barbosa[m]>
Ok just another question, last week I was trying to build a program where I was using fold expressions and it wasn't working cause it said it only worked with c++17 or something and so I added the line "set(HPX_CXX_STANDARD 17)" to the cmake file. It solved the problem but now I'm not sure of what I did
<K-ballo>
it told the hpx cmake project to ask cmake for c++17 support
<pedro_barbosa[m]>
Ohhh ok, got it. Thanks
shubham has quit [Quit: Connection closed for inactivity]
nanmiao has joined #ste||ar
<hkaiser>
gonidelis[m]: yt?
<gonidelis[m]>
hkaiser: hey
<hkaiser>
gonidelis[m]: see email, pls
<K-ballo>
hkaiser: for some time now I've been seeing msvc fail to build properly, mix old and new builds and cause all kinds of odd crashes, have you experienced any?
<K-ballo>
often I find myself forced to rebuild all to get proper runs... it's a very VC++6.0 feeling