<K-ballo>
maybe add some unevaluated expression to get syntactic checks going?
<heller>
K-ballo: unused variable warnings
<K-ballo>
ok, let's start from an equal ground and compare those
hkaiser has joined #ste||ar
<heller>
I obviously wasn't aware of the bloat that lambdas might add here...
<K-ballo>
I'm looking at achieving the same goals but without the lambdas, if the same goals can't be achieved then let's just pay for it.. it's only debug symbol bloat, compile time cost, not release binary size
K-ballo has quit [Ping timeout: 276 seconds]
K-ballo has joined #ste||ar
<K-ballo>
looks like we already define the macros as empty when HPX_DEBUG is not set
Coldblackice has joined #ste||ar
Coldblackice_ has quit [Read error: Connection reset by peer]
rori has quit [Ping timeout: 250 seconds]
rori has joined #ste||ar
<simbergm>
hkaiser: yt?
rori has quit [Ping timeout: 246 seconds]
<hkaiser>
simbergm: gotta run, I'll ping you in an hour or so
<hkaiser>
simbergm: we can resolve the circular dependencies either at compile time or at runtime
<simbergm>
I'd like to start implementing something for it, but I'd like some consensus before I do so
<hkaiser>
at compile time this could be done using (partial) template specialization, where the code using things relies on a trait to be specialized by some other piece that would otherwise cretae a cycle
<hkaiser>
at runtime this can be done using callback function registration as done in other places
<hkaiser>
we normally the registration in constructors of global objects
<hkaiser>
(all the actions are registered that way)
<simbergm>
right, do the global objects never cause problems with initializing the runtime in a global object? or how is that handled?
<simbergm>
or maybe it's not tested...
<hkaiser>
simbergm: for things that require a certain initialization sequence things become tricky
<hkaiser>
otherwise everything is fine as the global initialization is done sequentially anyways
Coldblackice_ has joined #ste||ar
Coldblackice has quit [Ping timeout: 240 seconds]
Coldblackice|2 has joined #ste||ar
<simbergm>
mmh, and the first option, doesn't that still require that whatever type is used to specialize is available the module using the specialization?
<hkaiser>
simbergm: just keep in mind that the default initialization order is undefined
<hkaiser>
simbergm: yes, in this case it might not work
<hkaiser>
we discover at runtime what's available so the compile time option is not available
<simbergm>
yeah, I'd like to not go the global object route unless necessary
<hkaiser>
well, what do you suggest?
Coldblackice_ has quit [Ping timeout: 240 seconds]
<simbergm>
I'd like to move the rp initialization fully into hpx_init
<simbergm>
(btw, sorry if it came off as me picking on your suggestions)
<simbergm>
but doing that requires api changes
Coldblackice has joined #ste||ar
<hkaiser>
right
<hkaiser>
and no worries, I didn't take any offense - all is fine
<simbergm>
it does feel like the correct thing to do though
<hkaiser>
yah, I never liked the rp initialization outside of init
<simbergm>
I was thinking for the init/start overloads we could move to passing an init struct instead with appropriate default values
<hkaiser>
cleaning up init is definitely worth, it has too many options already
<simbergm>
we'd have fewer overloads and one could change only the options one wants to change
<hkaiser>
sounds good to me, I'd like to leave the main overloads as they are, however
<simbergm>
and it could get an additional field(s) for rp init
<hkaiser>
init(argc, argv), for instance
<simbergm>
yeah, they'd have to stay around
<simbergm>
indeed
<simbergm>
the most commonly used ones can definitely stay
Coldblackice_ has joined #ste||ar
<hkaiser>
and the others could be deprecated simply forwarding to the new API that takes the struct
Coldblackice|2 has quit [Ping timeout: 276 seconds]
<simbergm>
exactly
<hkaiser>
nod, deal
Coldblackice_ has quit [Read error: Connection reset by peer]
<simbergm>
okay, deal :P
Coldblackice_ has joined #ste||ar
Coldblackice has quit [Ping timeout: 265 seconds]
<simbergm>
I just wanted to make sure I wasn't missing something from your comment
<simbergm>
thanks!
<hkaiser>
well, thanks for your work on this!
<hkaiser>
simbergm: btw, we talked to your boss (and his boss) at SC
<simbergm>
yeah, I heard :)
<simbergm>
did you come to some sort of understanding?
<simbergm>
first time you met thomas?
<hkaiser>
first time I met Jost, I have met Thomas before
<hkaiser>
Thomas wants to have a decision on either abandon HPX or go full force in as the current state of affairs is not half not full
<hkaiser>
I had the impression he is looking for excuses to go in full force
Coldblackice_ has quit [Ping timeout: 245 seconds]
<simbergm>
I can see that
<hkaiser>
simbergm: Thomas is most worried about sustainability and a governance model for the HPX development
<simbergm>
I think he thinks things aren't really moving quickly enough
<hkaiser>
I didn't hear him saying anything like that
Coldblackice has joined #ste||ar
<simbergm>
ok
<hkaiser>
he invests 3FTEs currently, but that isn't sufficient if he wants to get the Meteo code (gridtools) ported
<simbergm>
we should discuss this in more detail once... I haven't met either joost or john after sc so I haven't had the full update
Coldblackice_ has joined #ste||ar
<simbergm>
I have to go in a minute, sorry
<hkaiser>
sure, ttyl
<simbergm>
should we set up the next hpx call for next week?
<hkaiser>
ok, let's do that
<hkaiser>
simbergm: Adrian is leaving, so I mind need help in organizing things in the future, btw
<hkaiser>
I might*
<simbergm>
sounds like it would be a good idea to debrief that discussion without thomas around ;)
<hkaiser>
indeed
Coldblackice_ has quit [Max SendQ exceeded]
Coldblackice_ has joined #ste||ar
<simbergm>
sure, no problem, we're happy to pick up some of the things he was organizing
<simbergm>
how soon though? should I send an invite for next week? ;)
<hkaiser>
simbergm: please do, he's still around, but out all of this week
Coldblackice has quit [Ping timeout: 240 seconds]
<hkaiser>
simbergm: he'll be with us until end of the year
<simbergm>
ok
<simbergm>
is the usual wednesday 4pm our time (9 am your time?) ok with you
<hkaiser>
simbergm: last note: Jost was pushing in favor of HPX
<hkaiser>
sounds good
<hkaiser>
thanks!
<simbergm>
heller rori call next week?
<simbergm>
yeah, he's positive :)
<simbergm>
anyway, ttyl
<hkaiser>
jbjnr: ^^ ?
weilewei has joined #ste||ar
<rori>
works for me if it's after wednesdqy
<rori>
(including wednesday)
<rori>
cause I'm in vacation on monday and tuesday
<rori>
it's my graduation :D
<weilewei>
hkaiser - this is jb using weile's account - if I have a function returning void, and I need to store the result of the function, then return it later, how do I correctly use void_guard. I can't get it to compile
Coldblackice has joined #ste||ar
<K-ballo>
that's not what void_guard does, it does not store the result for later
<hkaiser>
void_guard is not doing such a thing
<weilewei>
is there a way to do it though
<K-ballo>
storing void? then return it later?
<weilewei>
temp = f(...); do_something; return temp; when temp is void type?
<K-ballo>
drop `temp = `, drop `return temp;`, profit
<K-ballo>
or is `f(...)` only sometimes void?
<weilewei>
it is inside a templated thing that normally, doesn't have void type, normally it is a normal function
<K-ballo>
then you'll have to resort for a scope guard, or outright specialization, depending on what the "do_something" actually does
<weilewei>
ok. annoying
Coldblackice|2 has joined #ste||ar
<weilewei>
thanks
Coldblackice_ has quit [Ping timeout: 250 seconds]
<K-ballo>
btw `temp = ` and `return temp;` is discouraged on its own, even for non-void
<weilewei>
because ?
<weilewei>
auto &&temp = ... ; return std::move(temp); ....
<K-ballo>
in the case `f(...)` is a prvalue, `temp` isn't.. it introduces copy/move requirements
<K-ballo>
you probably don't want to move there but forward, still killing prvalue-ness
<weilewei>
well, I can only do my best. I don't know another way of inserting code into the end of the function