<simbergm>
hmm, that one on the other hand should have the root prepended
<hkaiser>
right
<simbergm>
I'll look at it, don't worry
<simbergm>
but phylanx was happy with that, right?
<hkaiser>
yes
<simbergm>
ok, so it configures for me now
<simbergm>
I had another typo in partitioned vector
<simbergm>
did you already make the change on master?
<hkaiser>
no
<simbergm>
I'll push in that case
<hkaiser>
I'll tets it then
<simbergm>
hkaiser: there, give it a try
<hkaiser>
works, thanks a lot!
<simbergm>
good, sorry for the trouble
eschnett has joined #ste||ar
<hkaiser>
no worries!
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
<hkaiser>
simbergm: you guys are on the roll!
<hkaiser>
simbergm: we should create a review queue for the modules as the PRs depend on each other
rori has joined #ste||ar
aserio has joined #ste||ar
<hkaiser>
simbergm: is #3636 refelcting the order the PRs should be merged?
<simbergm>
hkaiser: yeah, well, we're leaving the hard part for last... ;)
<simbergm>
3636 does not reflect the order
<simbergm>
basic rule is oldest first
<hkaiser>
simbergm: I'm looking for some guidance which ones I should review next
<hkaiser>
ahh, ok
<simbergm>
yep, #3957 and #3979 first, please :)
<hkaiser>
simbergm: just please give me some time to keep up with Phylanx wrt the #include changes ;-)
<hkaiser>
so no more than one a day, perhaps ?
<simbergm>
hkaiser: oh, right
<simbergm>
you can keep the old headers (mostly) because of the compatibility headers, unless you have deprecation warnings and werror turned on?
<simbergm>
and we don't expect you to have time to go through them immediately :) we'll just keep opening them to have the ci check for silly errors
<hkaiser>
yah, I think the compatibility is on by default which breaks all builds because of -werror
<simbergm>
mmh, we could turn the warnings off but then we wouldn't catch old headers in hpx itself
<hkaiser>
right
<hkaiser>
no worries
<simbergm>
in any case, there's no big rush, just take your time
<simbergm>
I can approve them some as well, but I didn't want to so far because I did a bunch of the changes
<hkaiser>
simbergm: I'm in Cologne right now, so might have more time
<simbergm>
I'd be blind to dumb things
<simbergm>
hmm, you're saying the meeting isn't going to be very interesting? ;)
<hkaiser>
it never is ;-)
<simbergm>
btw, I'm sorry I keep force pushing some PRs all the time
<hkaiser>
simbergm: no problem
<jgurhem>
Hi ! I'm working on a distributed LU factorization with HPX. I already have a multithreaded version (https://github.com/jgurhem/HPX_LA) and I would like to go for a distributed version. Could you give me some pointers so that I can make a distributed version ? Jérôme
<hkaiser>
jgurhem: you might want to look either at the 1d_stencil sequence of examples or the stencil 2d example from the tutorials
<simbergm>
jgurhem: hey
<simbergm>
hkaiser: for context, jgurhem was at the course at hlrs
<simbergm>
I guess your best bet is channels then ;)
<jgurhem>
Hi ! I guess it is. The answer was super fast !
<hkaiser>
yah, channels are nice abstractions, not sure if they are useful for an LU factorization
<hkaiser>
things like a distributed object might be better suited
<jgurhem>
hkaiser Thank you. I'm currently looking into the 1d stencil from the examples
nikunj has joined #ste||ar
<hkaiser>
jgurhem: I think you should understand how HPX is doing remote function invocation (actions)
<hkaiser>
the rest is very similar to 'normal' code
nikunj has quit [Remote host closed the connection]
diehlpk_mobile has quit [Ping timeout: 276 seconds]
eschnett has joined #ste||ar
aserio has left #ste||ar [#ste||ar]
nikunj has joined #ste||ar
<Yorlik>
When writing a struct {void * ptr; uint32_t i;} (=12 bytes w/o padding) to some pointer location in a buffer: Is it defined if the padding will be written or not? Is it UB or is it implementation defined what happens?
<Yorlik>
I am experimenting with a super packed event type and am restricting myself to 16 bytes with 2 bytes being the event type and the rest depending on the event type, using a union and accessor APIs with casts in the functions.
<Yorlik>
The event struct essentially is a struct {std::byte bytes[14]; uint16_t event_type};
<Yorlik>
And the bytes will be reinterpreted to whatever.Making them a union didn't really work, since as soon as theres a pointer inside the union grows to 16 byte alignment already
<Yorlik>
So I desided to just use a buffer and an event type.
<Yorlik>
But writing a struct like {void*p; uint32_t i;} makes me nervous