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/
weilewei has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
weilewei has quit [Remote host closed the connection]
shahrzad has quit [Quit: Leaving]
bita has quit [Read error: Connection reset by peer]
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
beauty2 has joined #ste||ar
beauty1 has quit [Ping timeout: 272 seconds]
K-ballo has joined #ste||ar
<gonidelis[m]> what's a `local_raw_iterator` ?
hkaiser has joined #ste||ar
<gonidelis[m]> hkaiser: although I made the changes we were talking about I get this
<hkaiser> gonidelis[m]: looks better now ;-)
<hkaiser> I woul dhave to see the full thing (your changes) to suggest anything
<gonidelis[m]> it seems there is a mismatch between `in_in_out_result<local_iterator....>` and `in_in_out_result<traits1::local_raw_iterator...>`
<gonidelis[m]> hkaiser: sure it look better
<hkaiser> yah, try to find out what those typedef resolve to
<K-ballo> have you fixed the conversion bug I flagged yesterday?
<gonidelis[m]> I don't think there is anything wrong here
<gonidelis[m]> K-ballo: sec
<gonidelis[m]> K-ballo: oh no. sorry. I was cought up in this iterator conversion thing
<gonidelis[m]> but, what did you mean `conversion operators` ?
<K-ballo> the iterator conversion should be fine I reckon
<gonidelis[m]> yy
<K-ballo> the algorithm result types have broken conversion operators
<K-ballo> the in_in_out_result in your error, for example
<gonidelis[m]> What is a conversion operator?
<hkaiser> gonidelis[m]: the specializations you linked look ok, afaics
<gonidelis[m]> hkaiser: thanks
<gonidelis[m]> K-ballo: ok so you are talking about this line
<gonidelis[m]> ?
<gonidelis[m]> and #L126
<gonidelis[m]> ?
<K-ballo> yes, as well as all the others in that file
<gonidelis[m]> yeah I am already cross checking along with the spec
<gonidelis[m]> I promise I can't spot any difference
<K-ballo> > 12:56:42 PM - K-ballo: from const& to non-const&, that's your bug
<hkaiser> K-ballo: hmm, I don't see the problem
<gonidelis[m]> where do you see `non-const&`?
<gonidelis[m]> K-ballo:
<K-ballo> std::is_convertible<I1 const&, II1&>::value
<K-ballo> vs requires convertible_to<const I1&, II1>
<gonidelis[m]> oh shit
<K-ballo> all the const& ones have it
<gonidelis[m]> we should fix in `in_out_rslt` too then
<hkaiser> excellent catch!
<gonidelis[m]> and `in_in`
<gonidelis[m]> hkaiser: he is a maniac
<hkaiser> that error is my fault - interesting it didn't show up before
<hkaiser> gonidelis[m]: could you please create a separate PR fixing this?
<gonidelis[m]> ok could `local_raw_iterator` have to do anything with this `const&` `non const&` issue?
<gonidelis[m]> hkaiser: ahh yeah
<gonidelis[m]> it should be pushed before the `transform` PR right?
<hkaiser> yes, please
<gonidelis[m]> np
<gonidelis[m]> K-ballo: thanks a lot
<K-ballo> could it? the error telling you about in_in_out_results not being convertible?
<hkaiser> K-ballo: I think that's the problem
<K-ballo> a conversion from T const& to non-const U& is highly unlikely to ever succeed
<K-ballo> it would take something like reference wrapper
<gonidelis[m]> K-ballo: ok I am trying to figure out the machinery behind this spec implementation
<K-ballo> yes?
<gonidelis[m]> first of all what's the diff between the `const&` operator and the `&&` operator?
<gonidelis[m]> the one is const ref and the other is an rvalue ref I know
<gonidelis[m]> but what do they indicate in this context? K-ballo
<K-ballo> you mean the member function "qualifiers" (not really)?
<gonidelis[m]> yeas
<gonidelis[m]> yes ^^
<K-ballo> roughly speaking one applies to lvalues and the other to lvalues
<K-ballo> grr
<gonidelis[m]> what?
<K-ballo> one applies to lvalues and the other one to rvalues
<gonidelis[m]> why gr?
<K-ballo> because I said lvalues twice the first time
<gonidelis[m]> lol ok
<gonidelis[m]> great
<gonidelis[m]> thanks
<gonidelis[m]> and in the lvalue case
<K-ballo> incidentaly, it's slightly suspicious that a result object is an lvalue
<gonidelis[m]> hmm yeah that's true
<gonidelis[m]> is there any "but" here?
<hkaiser> K-ballo: you could store it locally before using it
<K-ballo> yeah, but why would you do it? that's what's suspicious
<hkaiser> auto r = transform(...);
<K-ballo> that's suspicious, why not return transform(...) ?
<hkaiser> and then use r.out in the next algorithm
<K-ballo> sure, but then you wouldn't be hitting the lvalue conversion operator
<K-ballo> gonidelis[m]: can you track down the line that's triggering the lvalue conversion/
<gonidelis[m]> K-ballo: yeah sure
<hkaiser> true - fair point
<gonidelis[m]> 1. why wouldn't you hit the lvalue conversion in that case?
<gonidelis[m]> 2. why is it that in the lvalue qualifier case, we need `is_convertible<const I1&, II1>`?
<K-ballo> there are no conversions at all
<gonidelis[m]> `next_algo(r.out)`
<gonidelis[m]> oh yeah. `r.out` is lvalue from the beginning
<gonidelis[m]> (??)
<K-ballo> I don't know what's on your mind, maybe add more detail
<K-ballo> a conversion requires a destination with a different type than the source
<K-ballo> there are no conversions in `auto r = ...;`, auto deduces the destination type to that of the source
<K-ballo> and there are no conversions in `r.out`, there's not even a destination type
<gonidelis[m]> ok what's a case where ` constexpr operator in_in_result<II1, II2>() && ` is used?
<K-ballo> when the result object is an rvalue
<K-ballo> in_in_result<I1, I2> fun();
<K-ballo> in_in_result<II1, II2> x = fun() // fun() yields an rvalue in_in_result<I1, I2>
<K-ballo> auto lvalue = fun(); // put it in an lvalue
<K-ballo> in_in_result<II1, II2> x = lvalue;
<gonidelis[m]> isn't `auto lvalue = fun();` an r to and lvalue conversion?
<gonidelis[m]> since `fun()` is rvalue
<gonidelis[m]> and `lvalue`, well, it's lvalue
<K-ballo> what's an r to...?
<K-ballo> auto lvalue = fun(); is initialization
<gonidelis[m]> an r to an l ^^
<K-ballo> what is an "r to an l"? that's not a thing
<gonidelis[m]> K-ballo: so you can't find a case where an rvalue need to be converted to lvalue with these result types?
<gonidelis[m]> rvalue to an lvalue^^^
<K-ballo> rvalue to lvalue conversion is not a thing
<K-ballo> lvalue to rvalue conversion is a thing, maybe you are confusing the two?
<gonidelis[m]> sec
<K-ballo> lvalue to rvalue conversion is basically when you have an object but you need a value
<gonidelis[m]> > 14:31 <K-ballo> incidentaly, it's slightly suspicious that a result object is an lvalue
<gonidelis[m]> ok that's why I was confused
<K-ballo> if we want to discuss that, I'm going to have to start again and use more precise terminology
<K-ballo> "a result object is an lvalue" basically means it's put in a variable, given a name
<K-ballo> so you are getting this result object, putting it in a variable, and then returning the variable for some reason
<gonidelis[m]> oh okk i get that
<gonidelis[m]> so in the `constexpr operator in_in_result<II1, II2>() const &` case
<gonidelis[m]> you are asking, "why would one return an lvalue" ?
<K-ballo> yeah, why would one store a result object instead of simply returning it
<gonidelis[m]> hmmmm
<gonidelis[m]> ok great
<K-ballo> the code triggering the conversion has to look like this:
<K-ballo> auto result = transform(...);
<K-ballo> return result;
<K-ballo> // do something here
<K-ballo> which is not a very nice pattern
<gonidelis[m]> why?
<K-ballo> because it's not the same as returning the result directly then doing something
<gonidelis[m]> in `// do sth here` you are not doing anything with `result`?
<K-ballo> even if you are
<K-ballo> once you locate the line that's triggering it we may discuss the specific case
<K-ballo> I only said "slightly suspicious", it may be ok
<K-ballo> actually that scenario would also trigger the rvalue conversion due to implicit move, so it has to be weirder than that
<gonidelis[m]> I get what you describe
<gonidelis[m]> I just don't get why it's weird
<K-ballo> it would have to be something more like return storage.result;
<gonidelis[m]> let me look for the line anyways
<K-ballo> result objects would normally be returned, not copied around
<gonidelis[m]> K-ballo: should the compiler denote the line?
<K-ballo> if it's still failing to compile, probably, but you would likely be getting a lot of extra information too
<gonidelis[m]> I haven't fix anything yet
<gonidelis[m]> I am trying to find the line
<gonidelis[m]> in order to learn
<gonidelis[m]> from our discussion
<K-ballo> if you add a static_assert to the lvalue conversion operator you should get a more precise stack dumped than when things sfinae out
<gonidelis[m]> could that be the cse?
<gonidelis[m]> case *
<K-ballo> it could be
<gonidelis[m]> I just provided a `dispatch` version in this branch that works with `in_in_out_result`
<K-ballo> what happens if it were auto out = ...;
<K-ballo> wait no, that shouldn't be it
<K-ballo> dispatch should return an rvalue, does it not?
<gonidelis[m]> is that an rvalue or an lvalue?
<K-ballo> unknown
<K-ballo> it would be wrong for it to be any kind of reference
<gonidelis[m]> how would it be if it was return an rvalue
<gonidelis[m]> ?
<K-ballo> it should be returning a non-reference type
<K-ballo> if it returned an && it would still be an rvalue, but still be wrong
<K-ballo> but even if it did, it wouldn't be triggering the lvalue conversion
<gonidelis[m]> oh ok
<K-ballo> put a dependent static_assert inside the lvalue conversion, see what the error trace tells you
<K-ballo> static_assert(sizeof(II1) == 0);
<gonidelis[m]> where?
<gonidelis[m]> on the `in_out_result` impl?
<gonidelis[m]> `in_in_out_result` *
<K-ballo> inside the lvalue conversion operator
<gonidelis[m]> what about that?
<gonidelis[m]> could that be
<gonidelis[m]> ?
<K-ballo> shouldn't be, `util::in_out_result<SegIter, OutIter>{olast, odest}` is a prvalue
<K-ballo> so is the return from the lambda, `util::in_out_result<SegIter, OutIter>`
<gonidelis[m]> I 've never understood what's a `prvalue` in my life
<K-ballo> X is a prvalue, X& is an lvalue, X&& is an xvalue
<K-ballo> an rvalue is a prvalue or an xvalue
<K-ballo> 5 is a prvalue, X{} is a prvalue
<K-ballo> since I'm not being precise with terminology anyways, I'll just say prvalue is a value with no name
<gonidelis[m]> that's better ;p
<gonidelis[m]> what about the `static_assert(sizeof(II1) == 0);` case
<gonidelis[m]> should I put it inside the body of the conversion?
<K-ballo> inside the lvalue conversion operator
<gonidelis[m]> like that `std::is_convertible<I1 const&, static_assert(sizeof(II1) == 0);>` ?
<K-ballo> no, that's not a place you can put a static assert (it's a declaration)
<K-ballo> you need to put it in the body of the conversion operator
hkaiser has quit [Quit: bye]
<gonidelis[m]> K-ballo: what did we expect from the static assert?
<K-ballo> a trace for the stack that leads to its instantiation
<gonidelis[m]> K-ballo: do you understand sth new from here
<gonidelis[m]> ?
<gonidelis[m]> from this*
<K-ballo> gonidelis[m]: what's the source corresponding to this trace?
<gonidelis[m]> i knew that from the beginning ;p
<gonidelis[m]> it was the first error in the stack
<gonidelis[m]> why is ti the problem though?
<gonidelis[m]> from the aspect of the wrong conversion?
<K-ballo> I was wondering why it was taking you so long to locate the source of the call
<gonidelis[m]> I thought i needed to find sth more sophisticated
<gonidelis[m]> (I wasn't working the past 1 hour though)
<gonidelis[m]> anyways, why is that the problem?
<K-ballo> I'd imagine the `R` given to algorithm_result_helper<R> is not what the algorithm actually returns.. but that doesn't cover the lvalue aspect
<K-ballo> waaaaait, that's a warning
<K-ballo> is sizeof(II1) == 0???
<K-ballo> it is still all sfinae in the trace
<gonidelis[m]> <K-ballo "is sizeof(II1) == 0???"> I have no idea
<K-ballo> in standard c++ that is always false, but gnu has extensions
<K-ballo> can't imagine how those extensions would apply here though
<K-ballo> fix the warning (as per the fix-it), see if you can then get an actual errro
<gonidelis[m]> I just put a message there
<gonidelis[m]> right?
<K-ballo> the fix it says to add `, ""`
<gonidelis[m]> yy
<gonidelis[m]> btw does master still not compile with gcc?
<gonidelis[m]> K-ballo: why?
<K-ballo> because if that's intended then the conversion shouldn't be kicking in
<gonidelis[m]> that what intended?
<K-ballo> that function there to be called
<K-ballo> you appear to be expecting raw iterators to transform to plain iterators, but appear to be calling it with plain iterators
<gonidelis[m]> what's the difference between a raw and a plain iter?
<K-ballo> no idea
<K-ballo> the conversion should be happening in its return ...; statement
<gonidelis[m]> hmmm i just copied the `in_out_result` impl there
<K-ballo> if the `in_out_result` one works then it must be being called with raw iterators as intended
<gonidelis[m]> I don't know what's a raw iter ;p
<gonidelis[m]> I am asking since yesterday qr
<gonidelis[m]> ;p *
<gonidelis[m]> K-ballo: how is this conversion called `std::is_convertible<I const&, I2>::value` ?
hkaiser has joined #ste||ar
gonidelis[m] has quit [Ping timeout: 240 seconds]
henrietaMag has quit [K-Lined]
mkeyn[m] has quit [Ping timeout: 246 seconds]
gnikunj[m] has quit [Ping timeout: 246 seconds]
ms[m] has quit [Ping timeout: 240 seconds]
rori has quit [Ping timeout: 260 seconds]
heller1 has quit [Ping timeout: 244 seconds]
tiagofg[m] has quit [Ping timeout: 268 seconds]
k-ballo[m] has quit [Ping timeout: 246 seconds]
klaus[m] has quit [Ping timeout: 260 seconds]
parsa[m] has quit [Ping timeout: 264 seconds]
gonidelis[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
mkeyn[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
parsa[m] has joined #ste||ar
rori has joined #ste||ar
tiagofg[m] has joined #ste||ar
klaus[m] has joined #ste||ar
heller1 has joined #ste||ar
ms[m] has joined #ste||ar
hkaiser has quit [Quit: bye]