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]
diehlpk_work_ has quit [Remote host closed the connection]
hkaiser has quit [Quit: bye]
bita has quit [Ping timeout: 260 seconds]
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
parsa has quit [Client Quit]
K-ballo has joined #ste||ar
<ms[m]> K-ballo: probably no good reason
<ms[m]> only possible reason I can think of is that they're used by other inline functions in headers, but it's probably just a mistake
<K-ballo> they aren't, they are only being used from parse_affinity_sth.cpp
<K-ballo> it looks like it may have been a standalone thing in the past
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
hkaiser has joined #ste||ar
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
henrietaMag has joined #ste||ar
<K-ballo> min/max are never actually used, they are always defaulted
<hkaiser> K-ballo: hmmm, I thought the parser would allow for specifying a list of entities
<hkaiser> -c3,4 or somesuch
<K-ballo> is that supposed to result in the min and max params being set?
<hkaiser> good question
<hkaiser> why?
<K-ballo> it mentions max_entities, which is min/max's defaulted value
<hkaiser> you mean all_entities()?
<K-ballo> *all_entities
<hkaiser> nod
<hkaiser> I don't remember the details, the idea was to be able express single entities, lists of entities and ranges of those
<hkaiser> ranges are stored as {min,-max} where -max != all_entities()
<hkaiser> the spec_type is filled through: https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/affinity/src/parse_affinity_options.cpp#L38-L42 - not sure if you have seen that
<K-ballo> yeah, the constructor only seems to be used as default or type conversion, never min/max
<hkaiser> K-ballo: true
<hkaiser> so it's a leftover from something else :/
<gnikunj[m]> clang-format is such a life saver. It seems like I was living under the rock all this time trying to format my file myself!
<gonidelis[m]> gnikunj[m] not so great with template programming though ;p
<hkaiser> gonidelis[m]: we have mostly good experiences
<hkaiser> it's not perfect, but good enough
<gonidelis[m]> i once contributes to a paper about coding readability btw ;p
<gonidelis[m]> hkaiser: sure. I don't mean to undermine its work. My code for sure would be a lot shittier without it
<gnikunj[m]> gonidelis[m]: strange. Probably I didn't use any advanced template programming then :P
<gonidelis[m]> gnikunj[m]: I will feel cheated if you tell me that your long arguments inside the angle brackets `<>`, are properly alligned
diehlpk_work has joined #ste||ar
<gnikunj[m]> gonidelis[m]: Aah that is not well aligned sadly :/
<hkaiser> gonidelis[m]: that's what we decided to go with
<gonidelis[m]> yy I am not comlaining at all
<gonidelis[m]> just fooling with my friend nikunj
<hkaiser> we went with the clang-format options as close as possible to what we've been doing before
<gnikunj[m]> gonidelis[m]: :D
<gnikunj[m]> hkaiser: and I must say that that clang-format file is such a boon to work with as well!
<K-ballo> the benefit of auto formatting is not in beauty, but in that you no longer have to (nor should) care about it
<gonidelis[m]> fair
<gonidelis[m]> hkaiser: I have added the iterator wrapper on local - segmented iterators, we were talking about at a past meeting
<gonidelis[m]> although the same error remains and it keeps deriving from the very same line
<gonidelis[m]> it's all about this call
<K-ballo> is this the one that was trying to do the conversion backwards?
<gonidelis[m]> yes
<K-ballo> what was the specialization that caused it?
<gonidelis[m]> i could show you the test-call i am making in order to produce the error, but is it cogent for clang not to trace it completely?
<gonidelis[m]> K-ballo:
<K-ballo> no, I pointed out one concrete specialization that was (directly or indirectly) bogus
<K-ballo> something is causing those raw iterators to be converted to remove earlier than they should
<K-ballo> code later on still expects raw iterators, and tries to convert them back
<gonidelis[m]> 1. i reckon you do not talk about this fix: https://github.com/STEllAR-GROUP/hpx/pull/5072/files
<gonidelis[m]> 2. "to be converted to remove"?
<gonidelis[m]> K-ballo: ^^
<K-ballo> remote
<K-ballo> no, it was after that fix was in place that it was clear the conversion was backwards
<gonidelis[m]> the specialization is the one that includes this call
<gonidelis[m]> where the error pops in
<K-ballo> is that the one I pointed out?
<gonidelis[m]> when did you point out?
<K-ballo> a week ago? maybe two? when we were discussing the issue
<K-ballo> right after the conversion fix
<gonidelis[m]> ?
<K-ballo> I don't see it there, no, where?
<gonidelis[m]> sec
<gonidelis[m]> it must have been the next day
<gonidelis[m]> this must be it
<gonidelis[m]> yy exactly
<gonidelis[m]> so you are talking about the `static_assert` debugging thing?
<K-ballo> I don't know, I don't think so.. wasn't that earlier?
<K-ballo> the static_assert tracing thing didn't kick, which is what made evident that the conversion was going backwards
<gonidelis[m]> ok the error is pretty clear I think
<gonidelis[m]> `hpx::local_vector_iterator<int, std::vector<int, std::allocator<int> > >` cannot be converted to `typename traits1::local_raw_iterator`, right?
<gonidelis[m]> and the conversion should be talking place here
<gonidelis[m]> right?
<K-ballo> the error is that your local_raw_iterators were converted into local_vector_iterators too early
<gonidelis[m]> i suppose you have no clue what a local_raw_iter is...
<K-ballo> does it matter?
<gonidelis[m]> thanks you. that's what i expected
<gonidelis[m]> ok i may suspect sth. give me a sec
<K-ballo> your function expects X but you are passing it Y, because you already converted your Xs into Ys
<gonidelis[m]> that's the initial code (that was compiling fine supposedly)
<gonidelis[m]> and that's my change
<gonidelis[m]> So these things are **already** `local_iter`s
<gonidelis[m]> how do you know that the error is due to early conversion?
<K-ballo> no, that's not it
<gonidelis[m]> what? why?
<K-ballo> why do you think that's it?
<gonidelis[m]> why do i think what? I am just pointing out the place where "these things" become local_iters
<K-ballo> btw these variables that only hold a result, they should use inference
<K-ballo> no, that's later on, the problem happens before dispatch can return
<gonidelis[m]> but I do call them as `local_iters` in the first place
<gonidelis[m]> K-ballo: ?
<K-ballo> those are inputs, not outputs
<gonidelis[m]> and you suggest that they are converted to `raw` at some point and then again back to `local` (but too early)
<gonidelis[m]> ?
<K-ballo> no, other way around
<K-ballo> the output is raw, dispatch expects to convert raws to local, but somehow it receives already converted locals
<K-ballo> or if by "they" you meant the inputs? those are irrelevant
<gonidelis[m]> the inputs lead to the outputs
<K-ballo> the type of the inputs is just fine
<gonidelis[m]> ok ok
<gonidelis[m]> i get it
<K-ballo> the algorithm is supposed to produce raws, but somewhere in the way to dispatch (which is responsible for converting those to local) they get converted early
<gonidelis[m]> it seems that i should be fine till this end of the trace
<gonidelis[m]> these ARE `raw`
<K-ballo> you don't get to that call, do you? isn't that the one I flagged?
<gonidelis[m]> yy
<gonidelis[m]> hmmmmmm
<gonidelis[m]> you are right
<gonidelis[m]> wtf
<gonidelis[m]> hey
<gonidelis[m]> it is explicitly stated here that it wants `local`s
<K-ballo> inputs should be local
<gonidelis[m]> could the case may be that you do know what's wrong but you are just letting me fight with the beast just to gain the XP?
<K-ballo> not really, but I would if I tried to compile the code
<gonidelis[m]> i gave you the full error though
<K-ballo> yeah, so?
<gonidelis[m]> do you expect your compilation do be different?
<gonidelis[m]> you said you would know the source in case you compiled it
<K-ballo> you mean the output? nah
<gonidelis[m]> ok here is a good question: why is `dispatcher_helper` popping up in the first place. I can find anyone anywhere calling it
<gonidelis[m]> it's just `dispatcher` calling `base_dispatcher::sequential`
<K-ballo> dispatcher uses dispatcher_helper
<gonidelis[m]> shit
<gonidelis[m]> just saw it
<gonidelis[m]> so I should search before the `dispatcher_helper`1 instantiation
<gonidelis[m]> the thing is I have not touched the code before that. and I have not touched the code after the `out = dispatch()` main call
<K-ballo> the code before and after out = dispatch() is irrelevant
<gonidelis[m]> yet you suggest that the problem is somewhere in between
<K-ballo> it's somewhere inside the dispatch() call itself that something goes wrong
<gonidelis[m]> i am not talking about lines
<gonidelis[m]> i mean the execution sequence
<K-ballo> the execution sequence is not before nor after that line either
<gonidelis[m]> "it's somewhere inside the dispatch() call itself that something goes wrong"
<gonidelis[m]> but you said the inputs are fine
<gonidelis[m]> do you mean inside the `dispatch()` implementation?
<K-ballo> yes
<gonidelis[m]> no one touched that either
<gonidelis[m]> btw the same error pops here
<gonidelis[m]> so there is a case where execution sequence passes through the `algo.call()`
<K-ballo> anything after the first TU error message you should ignore in general
<gonidelis[m]> when I can't find anything about the first tu being wrong though....
<K-ballo> anything after the first error message is based on the compiler guesses and assumptions of what you actually meant
<gonidelis[m]> i just can't see the `raw` popping up anywhere before that and i don't know why it is converted earlier
<K-ballo> and in general the compiler isn't very good at guessing with these templated scenarios
<gonidelis[m]> Could my `in_in_out_resul` impl cause the error?
<K-ballo> highly unlikely, but anything's possible
<hkaiser> gonidelis[m]: how can I reproduce this?
<gonidelis[m]> my branch is updated
<gonidelis[m]> if you compile with clang
<gonidelis[m]> `make -j tests.unit.modules.segmented_algorithms.partitioned_vector_transform_binary1`
<gonidelis[m]> sorry: `make -j tests.unit.modules.segmented_algorithms.partitioned_vector_transform_binary` will do. `1` is redundant
<gonidelis[m]> it's the same anyways
<hkaiser> gonidelis[m]: is that the PR?
<gonidelis[m]> yes
<hkaiser> ok
<gonidelis[m]> it's the `adapt_transform`branch
<gonidelis[m]> hkaiser: any luck>
<gonidelis[m]> ?
<hkaiser> not yet, give me some time, pls
<hkaiser> need to set things up first
<gonidelis[m]> no prob
<hkaiser> gonidelis[m]: ok, got it reproduced now, sorry it took so long
<gonidelis[m]> Plz don't apologize