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
<gonidelis[m]>
hkaiser: yt?
<hkaiser>
gonidelis[m] : here
<gonidelis[m]>
should we go for RC2 or the final release?
<gonidelis[m]>
i reckon rc2 would be best
<K-ballo>
what were the changes?
<hkaiser>
gonidelis[m]: rc2, I created anothe rPR today that needs to go in, but will take some time to be ready
<hkaiser>
K-ballo: since rc1? bunch of minor changes, mostly CI related
<gonidelis[m]>
alright!
diehlpk has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
diehlpk has quit [Quit: Leaving.]
Yorlik_ has joined #ste||ar
Yorlik_ is now known as Yorlik
Yorlik has quit [Ping timeout: 260 seconds]
Yorlik has joined #ste||ar
<john98zakaria[m]>
<hkaiser> "john98zakaria: it's a bit late..." <- Sorry to bother, Have you gotten a chance to look at it?
Yorlik has quit [Ping timeout: 260 seconds]
Yorlik has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 276 seconds]
heller[m] has joined #ste||ar
Yorlik_ has quit [Ping timeout: 246 seconds]
Yorlik has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 260 seconds]
Yorlik_ has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
<gnikunj[m]>
srinivasyadav227: hkaiser : no meeting today?
<hkaiser>
gnikunj[m]: we moved the meetings to Wednesdays
<gnikunj[m]>
Ohh yeah, totally forgot about that
diehlpk has joined #ste||ar
diehlpk has left #ste||ar [#ste||ar]
<gonidelis[m]>
hkaiser: should i change the CITATION.cff for the current Rc?
<hkaiser>
gonidelis[m]: if you want to?
<gonidelis[m]>
will do
<hkaiser>
thanks!
<diehlpk_work>
gonidelis[m], Just run the python script for that
<gonidelis[m]>
diehlpk_work: what do you mean?
<diehlpk_work>
It is a burden to get the cff syntax correct
<hkaiser>
diehlpk_work: this is unrelated to the pjm patch
<gonidelis[m]>
what is the problem with pjm anyways? hkaiser diehlpk_work
<diehlpk_work>
gonidelis[m], Fugaku uses the pjm scheduler and HPX does not support it yet
<diehlpk_work>
To run distributed on Fugaku, we need to support it
<gonidelis[m]>
oh
Yorlik has joined #ste||ar
<gonidelis[m]>
you mean cluster scheduler?
<diehlpk_work>
Yes
<Yorlik>
I there anything useful one could ever do with A after a B=std::move(A)? I am just wondering if it would make sense to destroy a symbol (here A) after a move as a language feature.
<Yorlik>
Just A=C, or something like that come to my mind, bit somehow I don't like it.
<Yorlik>
s/bit/but/g
<hkaiser>
Yorlik: yes, you can destruct A ;-)
<Yorlik>
Use A to blow up B?
<hkaiser>
Yorlik: no
<gonidelis[m]>
hkaiser: should i mention that apex tag is updated in the release notes?
<hkaiser>
A is still an object
<hkaiser>
gonidelis[m]: yah, might be good
<K-ballo>
Yorlik: what you are descriving is destructive move semantics, didn't work for C++
<Yorlik>
Yes - after all A could be re-used and be filled with a new instance. I guess it's one of the situations where C++ explicitly allows us to shoot ourselves in the foot.
<Yorlik>
I just don't like the UP part of it
<Yorlik>
UB
<Yorlik>
Use after move should trigger either a compiler warning or a dedicated runtime exception.
<Yorlik>
Not sure a compiler could always catch these situations.
<Yorlik>
WOuld probably come at a cost to have that safety.
<K-ballo>
use after move is perfectly fine most of the time
<K-ballo>
it's only UB if you don't fullfill preconditions
<K-ballo>
but that's nothing special of move semantics
<Yorlik>
Which preconditions are you thinking of here?
<K-ballo>
any, all
<K-ballo>
the precondition for vector[i] is i < vector.size(), whether you just created it, filled it with data, moved from it, etc
<Yorlik>
What about objects with some sort of special initialization in their constructors whose results are moved away? Maybe it's a bad example or one should just never do that kind of construction + move..
<K-ballo>
is no different, it will have invariants and preconditions like any other type, and the usual rules still apply
<Yorlik>
I think I'm not really aware of what you mean with usual rules here.
<K-ballo>
the rules of contract programming: invariants always hold, caller must satisfy preconditions (or else UB), callee satisfies postconditions
<Yorlik>
I think contract programming is not something I have really looked into. I guess I use it implicitly a lot in my internal reflection, but I have never systematically learned it.
<Yorlik>
The term makes a lot of sense to me though as you explained it.
<K-ballo>
the point is "moved-from" isn't a special state in the language
<Yorlik>
I always assumed I should generally consider any use after move as UB.
<K-ballo>
that's not the case in C++
<Yorlik>
Do you have any suggested reading on the matter? I was actually doing some learning on immutable data structures, which led me to RValue references and move semantics again.
<K-ballo>
uh... not really
<K-ballo>
there's an entire book on C++ move semantics, but I haven't read it
<Yorlik>
I'm going through this video in the moment, a talk from Kevlin Henney from 7 years ago or so: https://vimeo.com/131640207