hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
<hkaiser>
john98zakaria[m]: I'll merge it, this will build the image
<hkaiser>
john98zakaria[m]: do we need to modify the CI that builds the docs?
<hkaiser>
do we need to activate the Python env in some way there?
<john98zakaria[m]>
<hkaiser> "do we need to activate the..." <- No need to activate the environment, I applied the venv to the whole container running python / pip will result in invoking the virtual environment. As I appended the the new venv to path it gains precedence over the system env.
<hkaiser>
as said, it prevents finding the tag_invoke overload inside that namespace
<gonidelis[m]>
> If there is an identifier that you want to prohibit in your source code, you can “poison” it, in order to get a compile error if that identifier appears in your codebase.
<gonidelis[m]>
got it
<K-ballo>
mnope, that's not the same kind of poison thing
<K-ballo>
ordinary lookup looks for a name in a given scope, and if it doesn't find anything, it tries again in the outer scope, and so on and so forth until the global scope
<K-ballo>
the customization point poison pill is there to give something to ordinary lookup, so that it stops looking right there and won't find some global tag_invoke or whatever
<K-ballo>
note the poison tag_invoke takes no arguments at all, so the candidate selected by ordinary lookup will never be viable
Undername has joined #ste||ar
<K-ballo>
it's as if ordinary lookup had effectively been disabled, so the code is essentially performing only argument dependent lookup
<satacker[m]>
That's so awesome
<gonidelis[m]>
K-ballo: > note the poison tag_invoke takes no arguments at all, so the candidate selected by ordinary lookup will never be viable
<gonidelis[m]>
what do you mean the candidate will never be avail?
<gonidelis[m]>
the candidate is the poison?
<satacker[m]>
it does not take the tag (and not any args as well), ig
<gonidelis[m]>
yes that I can see
<gonidelis[m]>
I am asking what does the candidate will never be avail? What is the candidate? The user calls `tag_invoke` unqualified, ordinary lookup hits the poison, then... fails? or keeps looking further up?
<gonidelis[m]>
* be avail mean? What
<gonidelis[m]>
what if the user just calls `tag_invoke()`
<gonidelis[m]>
and are we actually talking about the unqualified case or the `std::tag_invoke()` one?
<gonidelis[m]>
(I wanna punch stuff rn cause this is the 1000th time I go through tag_invoke and still don't get it 100%)
<K-ballo>
the end user can't never reach the pill
rtohid[m] has joined #ste||ar
<K-ballo>
I think std::tag_invoke(std::tag_invoke) may reach the pill, not sure
<K-ballo>
no, scratch that, it's an object
<K-ballo>
you'd have to define a different tag_invoke then make an unqualified call to your own tag_invoke using std::tag_invoke as the argument
Undername has left #ste||ar [#ste||ar]
<gonidelis[m]>
what's the purpose of the pill if the user can not reach it?
Undername has joined #ste||ar
<gonidelis[m]>
<gonidelis[m]> "I am asking what does the..." <- also what bout that?
Undername has left #ste||ar [#ste||ar]
<K-ballo>
what would be the point if the user reached it, it's not defined
<K-ballo>
and even if it were defined, it takes no arguments, so it's never viable
<K-ballo>
it's certainly not there to be called
<K-ballo>
it's there to stop ordinary lookup within the tag-invoke eo-namespace from looking outside of it
<gonidelis[m]>
why?
<gonidelis[m]>
how could ordinary lookup reach there?
<K-ballo>
?
<K-ballo>
within the exposition only tag-invoke namespace
<satacker[m]>
Ordinary lookup finds `tag_invoke` within namespace scope but signatures don't match hence switch to ADL?
<K-ballo>
it's not a switch, they both take place
<gonidelis[m]>
K-ballo: what does exposition only mean?
<gonidelis[m]>
what is its purpose?
<K-ballo>
exposition
<K-ballo>
it's used to define via code how something behaves, without the code actually existing
<gonidelis[m]>
how do you define via code how sth behaves w/o actually writing the code down?
<K-ballo>
what stops you from doing it?
<gonidelis[m]>
the non existence of code
<K-ballo>
?
<gonidelis[m]>
you understand what i am saying
<K-ballo>
no
<gonidelis[m]>
ok exposition-only does not have to compile
<gonidelis[m]>
i didn't know that
<gonidelis[m]>
it's a rough description
<K-ballo>
it does have to compile
<K-ballo>
if it doesn't compile it doesn't have meaning
<gonidelis[m]>
ok
<gonidelis[m]>
back to subject
<gonidelis[m]>
<K-ballo> "tell me what ordinary_lookup..." <- it will look within the tag_invoke_t_ns, it will crash into `void tag_invoke();` (there is no definition there, shouldn't that be an error) and it will stop looking
<gonidelis[m]>
obviously that's not the case, but that's what i see as a logical path
<K-ballo>
"crash" isn't the most appropriate word
<gonidelis[m]>
whatever
<gonidelis[m]>
hit
<gonidelis[m]>
find
<K-ballo>
name lookup only looks up names, it doesn't care about definitions
<gonidelis[m]>
ah
<K-ballo>
the result of name lookup won't change based on whether something is defined or not
<gonidelis[m]>
alright
<gonidelis[m]>
so what's wrong with my suggestion
<K-ballo>
what's your suggestion?
<gonidelis[m]>
it will look within the tag_invoke_t_ns, it will crash into void tag_invoke(); and it will stop looking
<gonidelis[m]>
stop looking further up ^^
<gonidelis[m]>
so ordinary lookup "fails" (?) and ADL kicks in ?
<K-ballo>
to be entirely correct, it will keep looking but it won't go past the namespace
<gonidelis[m]>
K-ballo: right?
<K-ballo>
ordinary lookup and argument dependent lookup are orthogonal, they both take place independently and at the same time
<gonidelis[m]>
and who wins if both find sth?
<gonidelis[m]>
who decides who wins?
<gonidelis[m]>
and how?
<K-ballo>
neither wins, the candidate set is made of the union of all their results
<gonidelis[m]>
find sth suitable that fits^^
<gonidelis[m]>
there has to be a prevalent candidate in the end no?
<gonidelis[m]>
or is that runtime ?
<K-ballo>
that's something overload resolution will do, name lookup just finds names
<gonidelis[m]>
so we basically form the set compile time and see what happens when things spark?
<K-ballo>
it returns a set of candidates, from which later overload resolution will try to pick a "winning" candidate
<K-ballo>
spark?
<gonidelis[m]>
overload resolution is in compile time or runtime?
<K-ballo>
overload resolution is in compile time
<gonidelis[m]>
spark = start the execution
<K-ballo>
it's entirely type based
<K-ballo>
no, not spark at all
<gonidelis[m]>
coo
<gonidelis[m]>
awesome
<gonidelis[m]>
again going back
<gonidelis[m]>
is my suggestion correct until that point?
<gonidelis[m]>
so we amputate ordinary lookup and ADL kicks in
<gonidelis[m]>
ADL then sees `tag` and looks into `Tag`'s namespace
<gonidelis[m]>
????
<K-ballo>
no
<K-ballo>
ordinary lookup completes successfully, and adl also completes successfully, they are independent
<K-ballo>
don't bother with the "cute" terminology, it's hindering you
<gonidelis[m]>
ok but does not contribute to the overload set (ordinary lookup I mean)
<gonidelis[m]>
cute, you mean?
<K-ballo>
"crash", "spark", "amputate"
<K-ballo>
ordinary lookup most definitely contributes to the overload set, it contributes the poison pill
<gonidelis[m]>
making it in popular terms helps normal folk understand it
<K-ballo>
"popular" terms don't have meaning
<gonidelis[m]>
is normal folk
<gonidelis[m]>
\me
<K-ballo>
we are discussing a technical specification
<gonidelis[m]>
they have to diverge from the exact reality that's true cause they contribute more to understanding. that's not a debate between formalism and pop science tho
<gonidelis[m]>
ok, it ONLY contributes the pill!
<gonidelis[m]>
that's the catch ^^>
<gonidelis[m]>
?
<K-ballo>
except crash means something else in technology, spark doesn't imply runtime at all to me, and amputate suggests to me something completely different than what the spec is actually doing
<gonidelis[m]>
i shall respect your definition boundaries then
<gonidelis[m]>
bottom line is that we only want ADL to find the overload that will eventually prevail?
<K-ballo>
yes
<gonidelis[m]>
and that's the purpose of the poison
<gonidelis[m]>
and the reason that we do not want ordinary lookup to go further up is ...?
<K-ballo>
if I define void tag_invoke(int) at global namespace then ordinary lookup would find it
<K-ballo>
without the pill, that is
<gonidelis[m]>
would find it if you didn't have the pill
<gonidelis[m]>
yes
<gonidelis[m]>
sounds like that should be with every standard facility name, no?
<K-ballo>
why?
<gonidelis[m]>
cause we want to reserve the name for the facility we provide (as standard library authors i mena)
<gonidelis[m]>
s/mena/mean/
<K-ballo>
names are only reserved within the std:: namespace (...and sometimes maybe the global namespace)
<K-ballo>
furthermore, the name tag_invoke isn't reserved
<K-ballo>
it would be pointless if it were reserved, since it's meant for users to customize
<gonidelis[m]>
awesome
<K-ballo>
unless by "reserve" you mean something cute instead
<gonidelis[m]>
no
<gonidelis[m]>
how could the compiler find my outside std tag_invoke definition?
<gonidelis[m]>
ordinary lookup would stop deeper in
<K-ballo>
you should be able to figure that out
<K-ballo>
we just discussed exactly how we want std to find outside tag_invoke definitions