hkaiser 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/ | GSoC: https://github.com/STEllAR-GROUP/hpx/wiki/Google-Summer-of-Code-%28GSoC%29-2020
nikunj97 has joined #ste||ar
Nikunj__ has quit [Ping timeout: 272 seconds]
Nikunj__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 260 seconds]
nan11 has quit [Remote host closed the connection]
bita_ has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Disconnected by services]
Yorlik_ is now known as Yorlik
Yorlik has quit [Read error: Connection reset by peer]
Yorlik has joined #ste||ar
hkaiser has quit [Quit: bye]
Yorlik has quit [Ping timeout: 246 seconds]
Nikunj__ has quit [Quit: Leaving]
nikunj97 has joined #ste||ar
Nikunj__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 272 seconds]
weilewei has quit [Remote host closed the connection]
bita_ has quit [Ping timeout: 260 seconds]
<ms[m]> we can also go with rfc or something like that, hep is definitely not a must
<ms[m]> hkaiser: I thought it was HPX Enhancement Proposal ;)
<heller1> I guess the name needs to go through a HEP
<ms[m]> of course!
<heller1> :P
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<heller1> hmmm, why do we not have a variant?
<jbjnr> I would like to suggest an HEP - get rid of regression tests as a 'thing' simply move them into unit tests where applicable and delete obsolete ones. Anyone else??
Yorlik has joined #ste||ar
<ms[m]> jbjnr: indifferent
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
Nikunj__ has quit [Read error: Connection reset by peer]
rtohid has quit [Remote host closed the connection]
<heller1> me too
<heller1> but yay: no unit tests for optional
<heller1> can we not have move only types inside of optional?
<K-ballo> move only types are fine
<heller1> hmmm
<heller1> then I am messing something else up
<heller1> `return R{};` works `optional<R> r= /*...*/; return *move(r);` doesn't
<heller1> `R r{}; return std::move(r);` doesn't either
<K-ballo> sounds like R is not movable
<heller1> `struct R { R(R const&) = delete; R& operator=(R const&) = delete; int i; }`
<K-ballo> so not movable then
<heller1> ok, after default the move ctor and move assign op
<heller1> it works
<heller1> why are those not implicitly generated in that case?
<K-ballo> they are inhibited by your user declared copy operatoins
<K-ballo> if your copy is special, your move would likely be too
<heller1> wow, I was not aware that even deleted functions count as user declared. Thanks!
<K-ballo> for move-only you can just default the moves, and that deletes the copies
<heller1> awesome, thanks
<heller1> I was looking where I messed up the return type calculation
hkaiser has joined #ste||ar
<hkaiser> apparently the iterator you changed was used in other places that need fixes now
<hkaiser> in particular the test count_3646.cpp
<K-ballo> was that the workaround for static initialization not triggering on invalid C++ code?
<ms[m]> this force linking stuff will become extra painful with the libhpx split (because almost nothing is used directly in the lower level library, just exported)
<ms[m]> no, I just found it as a potential equvalent to `--whole-archive` that we use on linux
<ms[m]> it does say "linked executable" so I don't know if that means it won't work for our special case of linking static libs to shared libs
<ms[m]> maybe it doesn't care
<hkaiser> ms[m]: I was not aware of this
<hkaiser> might actually be useful
<ms[m]> 👍️ (that means it's not doomed at least)
<ms[m]> I just pushed a change with that so let's see what the builders say...
<hkaiser> sounds like exactly what we need
<hkaiser> ms[m]: very nice find indeed
<ms[m]> I guess "introduced in Visual Studio 2015 Update 2" won't be a problem for any of you?
<ms[m]> I really hope this works because I was ready to do something nasty when I realized we might have to force link a lot of stuff...
<hkaiser> no problem
<hkaiser> we agreed to support not more than the latest two versions
<ms[m]> 👍️
<hkaiser> ms[m]: this solution would be even better than the object libraries
parsa| has joined #ste||ar
parsa| has quit [Client Quit]
<Yorlik> Why does returning a local variable from a function that returns a reference only generates a warning and not an error? After all this is fully fledged UB, isn't it?.
<K-ballo> not until you touch the return value?
weilewei has joined #ste||ar
karame_ has joined #ste||ar
<ms[m]> hkaiser: do you think I could ask you to have a look at WHOLEARCHIVE? the feedback loop is not very fast with gh actions...
<hkaiser> ms[m]: will try
<ms[m]> I currently have `target_link_libraries(hpx_${libname} PRIVATE "/WHOLEARCHIVE:hpx_${modulename}")` and get ` LINK : fatal error LNK1104: cannot open file '\WHOLEARCHIVE:hpx_affinity.obj'`
<hkaiser> do you have it in the build system already somewhere?
<ms[m]> I guess we might need to get the `OUTPUT_NAME` of the module and use that
<ms[m]> yeah, it's the latest state of `msimberg/core-shared-lib`
<ms[m]> note: just adding a `/WHOLEARCHIVE` without specifying which archive does it for everything that's linked and that fails with multiple definitions
<ms[m]> thank you!
<ms[m]> I won't push anything in the meantime
<ms[m]> (meaning today...)
bita_ has joined #ste||ar
<ms[m]> the linking happens in `cmake/HPX_AddModule.cmake` now btw...
<hkaiser> ok
<hkaiser> ms[m]: btw, if the forward slash is misinterpreted... you can always use '-' instead
nikunj has quit [Ping timeout: 260 seconds]
nikunj has joined #ste||ar
rtohid has joined #ste||ar
<ms[m]> ok, good to know
<ms[m]> I don't think that's the problem here... it's a question of expanding `hpx_${modulename}` to something that the linker knows is the static library file
<hkaiser> understood
<K-ballo> $<TARGET_FILE:hpx_${modulename}> (assuming hpx_${modulename} is the name of the static library)?
<bita_> hkaiser, can I ask a question?
akheir has joined #ste||ar
<hkaiser> sure
<hkaiser> K-ballo: right
<ms[m]> K-ballo: thank you
<bita_> having blaze::DynamicMatrix<int> a{{}}, a.rows() is 1! Am I missing something or it is a bug? I expect it to be zero
<ms[m]> hkaiser: I'll try that change
<hkaiser> what about if you write a(0, 0) instead?
<hkaiser> in your example it has one row, so it's not a bug
<bita_> in the physl I show an empty matrix with [[]] and I check extract_numeric_value_dimensions vs its annotations
<bita_> I don't think I can change it
<bita_> and in numpy that shape is (0,0). I don't think it has a row (the way numpy counts commas to figure out the shape results in empty)
<hkaiser> bita_: that's how blaze does things...
<hkaiser> should we change PhySL?
<bita_> I can use an if to not confront with this problem. But it doesn't make sense to me that {{}} has a row
<bita_> If we want to comply with numpy, we might wanna change physl
<K-ballo> 1 row with 0 values.. that's what I'd expect C++wise
<bita_> Okay, I will add the if statement :)
nan11 has joined #ste||ar
<ms[m]> hkaiser, K-ballo ` LINK : fatal error LNK1356: cannot find library `\D:/a/hpx/hpx/build/Debug/lib/hpx_affinityd.lib\.lib' specified to be whole archived`
<K-ballo> where's the extra .lib coming from?
<ms[m]> I guess it expects a library path without a `.lib` suffix? or would it be happy even with just `hpx_affinityd`? without the full path?
<K-ballo> note .lib\.lib
<ms[m]> it's `target_link_libraries(... "/WHOLEARCHIVE:$<TARGET_FILE:hpx_affinity>")` so I suppose either target_link_libraries adds it or the windows linker? (the first seems more likely)
<ms[m]> target_link_options might not add .lib...
<gonidelis[m]> hkaiser: Just saw your message. I will try to fix it....
<gonidelis[m]> right now ^^
<hkaiser> gonidelis[m]: ok, thanks
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
nikunj has quit [Ping timeout: 265 seconds]
nikunj has joined #ste||ar
<hkaiser> ms[m]: /WHOLEARCIVE works fine now
<hkaiser> some linker errors for things depending on HPX, but the core and full libraries build now
<ms[m]> hkaiser: \o/
<ms[m]> thanks for the patch, I'll apply that
<hkaiser> hpx::serialization::load/save for std::exception_ptr is missing, but I think tose got lost with the changes to the exception serialization
<gonidelis[m]> hkaiser: Could that be part of the reason why my build was failing?
<hkaiser> that is why your build is failing, yes
<ms[m]> yep, most likely
<ms[m]> that I should be able to deal with
<gonidelis[m]> hkaiser: thank you
<hkaiser> ms[m]: I have not removed the force_linking stuff, however, so I'm not sure if that is still needed
<hkaiser> gonidelis[m]: most welcome
<hkaiser> ;-)
<ms[m]> hkaiser: no worries, thank you for doing this
<ms[m]> I can remove the force linking stuff
<ms[m]> I can try removing it...
<hkaiser> sure, I'll be happy to test
<hkaiser> ms[m]: btw, cmake times are back to normal with that as well
<ms[m]> hkaiser: very good
kale_ has joined #ste||ar
kale_ has quit [Client Quit]
kale_ has joined #ste||ar
kale_ has quit [Client Quit]
kale_ has joined #ste||ar
<kale_> @hkaiser, Can you tell me the email id of parsa ?
kale_ has quit [Quit: Leaving]
kale_ has joined #ste||ar
kale_ has quit [Client Quit]
<weilewei> kordejong have you solved apex issue that "pthread_setaffinity_np: Invalid argument"? I searched on March 27, you asked this question, and I am running into similar issue.
<weilewei> I built hpx with apex, RelWithDebInfo, and build dca with this hpx version. Once I run the app, it gives me this error and then terminates the program. Does anyone have any idea?
<hkaiser> weilewei: in a meeting...
<weilewei> hkaiser no worries...
akheir has quit [Quit: Leaving]
Yorlik has quit [Ping timeout: 260 seconds]
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 260 seconds]