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/
bita has joined #ste||ar
parsa[m] has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has quit [Ping timeout: 264 seconds]
hkaiser has joined #ste||ar
<gonidelis[m]> hkaiser: K-ballo what's the motive behind not having a `::type` thing for `iterator_range` ?
<k-ballo[m]> what would it do?
<gonidelis[m]> what does `::type` usally do?
<k-ballo[m]> denote a type
<gonidelis[m]> then, that.
<k-ballo[m]> which type would it denote?
<gonidelis[m]> `iterator_range`: a custom type of our own
<k-ballo[m]> it's a range after all, not a metafunction
<gonidelis[m]> k-ballo: ok that sounds conviencing...
<k-ballo[m]> `iterator_range::type` that denotes `iterator_range`?
<k-ballo[m]> what would be the point?
<gonidelis[m]> ok we mainly use `::type` for metafunctions then. couldn't recall that. cool
<k-ballo[m]> ?
<gonidelis[m]> nevermind. i am jsut revising some basic concepts.
<hkaiser> gonidelis[m]: by convention, ::type denotes the 'return value' of a meta function
<hkaiser> gonidelis[m]: see my lecture about template meta programming and traits
<gonidelis[m]> hkaiser: yup... already doing that right now ;)
<hkaiser> it's one of those patterns I refer to the other day
<hkaiser> referred*
<gonidelis[m]> hkaiser: exactly :)
<gonidelis[m]> just one other thing: since `iterator_range` has two template arguments `I` and `S`, can I use it like `iterator_range<range_iterator<Rng>>`
<gonidelis[m]> sounds like the one cancels the other ;p
<k-ballo[m]> from the bug it looks like it has only ever been used as `iterator_range<Iter>`
<gonidelis[m]> I thought `range_iterator<Rng>` was an `Iter`... what bug?
<hkaiser> probably: typename iterator_range<typename range_iterator<Rng>::type>::type
<k-ballo[m]> ::end's return type is wrong
<gonidelis[m]> hkaiser: ahh... `iterator_range` does not have a `::type` :p
<hkaiser> well, whatever
<gonidelis[m]> ok I just wanted to be sure on that.
<hkaiser> you're certainly right, iterator_range is not a meta function
<gonidelis[m]> hkaiser: ok great. I have spent my last two days on that. so here is my point: when my result type is an `algorithm_result<ExPolicy, some_type>`, it's like the compiler complains when the `some_type` does not have a `::type` thing
<gonidelis[m]> where `some_type` is exactly what we talked about 5 minutes ago
<hkaiser> gonidelis[m]: I would assum it complains about algorithm_result<> not having a ::type, but I might be wrong
<gonidelis[m]> hkaiser: check on your own ;)
<hkaiser> gonidelis[m]: I would need to see the whole thing
<hkaiser> looks like borrowed_subrange_t is not defined
<hkaiser> or just forward declared
<hkaiser> gotta run now, however
<gonidelis[m]> hkaiser: it is defines. sorry for not passing any code
<gonidelis[m]> hkaiser: okk no prob ;)
<gonidelis[m]> k-ballo: could you lend a hand?
<k-ballo[m]> looks like your brackets are not balanced correctly
<gonidelis[m]> the angle brackets ?
<gonidelis[m]> (vs code not providing a highlighting option for that makes me furious)
<gonidelis[m]> wth!! i replaced `borrowed_subrange_t` with `hpx::util::iterator_range` and it worked
<gonidelis[m]> k-ballo: the brackets were fine actually ...
<gonidelis[m]> so I guess my using statement is off?
<k-ballo[m]> you had typename foo_t, which doesnt make sense
<gonidelis[m]> k-ballo: ok I get what you are saying, but how does compiler even know that
<gonidelis[m]> it's just a wrong naming convention of mine
<k-ballo[m]> it's usually typename foo<>::type, or just foo_t
<k-ballo[m]> typename iterator_range doesn't make sense either
<gonidelis[m]> k-ballo: why?
<k-ballo[m]> iterator_range is already known to be a type, since it's not dependent on anything
<k-ballo[m]> typename is needed when a name is dependent and could either be a type or a value
<gonidelis[m]> k-ballo: i thought it wouldn't hurt to give a little push for the comiler to not have to look that up
<gonidelis[m]> given that `borrowed_subrange_t` (or `iterator_range` anyways) is a type indeed, `typename` cannot lead to a compile error
<k-ballo[m]> ?
<k-ballo[m]> `typename foo` is an error
<gonidelis[m]> even when `foo` is a type ?
<gonidelis[m]> whaaaaat? i think you are right there...
<gonidelis[m]> (notice the workaround in the `using` decl. don't know if it's better that way)
<gonidelis[m]> it's the `typename` that produces the error indeed... but how ?
<gonidelis[m]> since it's a class...
<gonidelis[m]> k-ballo: is this supposed to return an iterator?
<k-ballo[m]> an iterator type, yes
<k-ballo[m]> the type that begin(rng) returns
<gonidelis[m]> and its usage is like typename `hpx::traits::range_iterator<Rng>::type`
<gonidelis[m]> what's that `0L` supposed to mena?
<gonidelis[m]> mean*
<gonidelis[m]> k-ballo:
<k-ballo[m]> literal 0 with type long
<gonidelis[m]> oh ok
<gonidelis[m]> could that Iterator replace a FwdIter type?
<k-ballo[m]> not known
<gonidelis[m]> you mean you don't know, or that it depends/
<gonidelis[m]> ?
<k-ballo[m]> it isn't known, it is whatever type the range returns for begin
<gonidelis[m]> but how could I determine that?
<k-ballo[m]> it could be an input iterator, or forward, or..
<gonidelis[m]> ohh it depends the range
<gonidelis[m]> right?
<k-ballo[m]> it is the range's iterator type, it depends on the range, yes
<gonidelis[m]> hkaiser: yt?
<hkaiser> here now
<gonidelis[m]> when I use `make_iterator_range` I get:
<gonidelis[m]> and I just can't stop suspecting that it's again some `dispatch` overload missing
<hkaiser> hmmm
<hkaiser> those overloads are needed for the segmented algorithms only
<gonidelis[m]> do you see that the problem is turning a `lcos(sth)` to `sth` ?
<gonidelis[m]> `lcos::futre`
<gonidelis[m]> yeah.... that's what I thought. But !
<hkaiser> algorithm_result<..., T>::type can be either T (synchronous invocation) or future<T> (asynchronous invocation
<gonidelis[m]> async does not mean segmented.... right?
<hkaiser> right
<hkaiser> async means par(task) used as an execution policy
<gonidelis[m]> perfect. that's where it hits actually (on the test).
<gonidelis[m]> so! when we use `seq(task`
<gonidelis[m]> `seq(task)` ^^
<hkaiser> yah, seq(task) is async as well
<gonidelis[m]> buuut here is the catch
<gonidelis[m]> does this return an `algorithm_result<...,T>`
diehlpk_work_ has joined #ste||ar
<gonidelis[m]> I mean... since it's seq, it could have no exec policy at all (???)
<hkaiser> it returns algorithm_result<>::type
<hkaiser> sure it can
<hkaiser> remove_if(seq, ...) is sequential
<gonidelis[m]> remove_if(seq,...) is exactly the same with remove_if(...)
<gonidelis[m]> right?
<hkaiser> right
diehlpk_work has quit [Ping timeout: 264 seconds]
<gonidelis[m]> ahhhhhh........ I think I got it!!!
<gonidelis[m]> hkaiser: thanks :))
<gonidelis[m]> I just needed to communicate it in order to untangle it
<gonidelis[m]> hkaiser: btw I have seen various talks of yours about our exec policies, but do we have any docs somewhere were I could refer to systematically?
<hkaiser> probably no :/
<gonidelis[m]> ok... let's put that on gsoc... or gsod maybe.
<gonidelis[m]> for example when we call `auto f = remove_if(par, ...)`, could I obtain `f` like `f.get()` ? (I know it's redundant -if possible- but I don't if it's actually possible in the first place)
<gonidelis[m]> know^^
<gonidelis[m]> hkaiser:
<hkaiser> no
<hkaiser> par makes the algorithm return the straight value (so does seq)
<hkaiser> par(task) make the algorithm return a future<> of that very same type (so does seq(task))
<gonidelis[m]> ok great so I think I have finally formed my question then:
<gonidelis[m]> this is working fine with `test_remove_if(seq, DataType());`
<gonidelis[m]> and ` test_remove_if(par, DataType());`
<gonidelis[m]> etc...
<gonidelis[m]> but when I call `test_remove_if_async(seq(task), DataType());`, it hits on the first argument (which I have highlighted for you) because it returns a future<iterator>`, while `make_iterator_range` expects just an `iterator`
<gonidelis[m]> `future<iterator>` ^^
<gonidelis[m]> (sorry for messing the code markup
<gonidelis[m]> )
<hkaiser> right, so you can't just use make_iterator_range
<gonidelis[m]> yeah... I need sth in the middle. but that can't be an `f.get()` where I call the highlighted part before returning `make_iterator_range`
<hkaiser> if you really need something like that, you will have to create facilities that can handle both cases, similar to what we have with get_second_argument (I forgot the name)
<gonidelis[m]> yy. i should check the other adapted algos again, I guess.
<gonidelis[m]> hkaiser: is creating a `make_iterator_range` overload for futures an option?
<hkaiser> well the async algorithm should return a future<iterator_range<>>, so such an overload should do that
bita has joined #ste||ar
<gonidelis[m]> can we call `make_future` with just one template argument?
<gonidelis[m]> hkaiser: do you have any idea on whether i should use the `zipiter` for the `iterator` `sentinel` pair?
<gonidelis[m]> could/should ^^
<hkaiser> why should you?
<gonidelis[m]> nevermind ... i wrack my brain over how to engineer this thing out :q
<gonidelis[m]> i just didn't know if `make_future` could take two arguments
<gonidelis[m]> it shouldn't... it's just AN `iterator_range` i can hear my brain saying...