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
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 268 seconds]
Yorlik has joined #ste||ar
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: YT?
<hkaiser>
Yorlik: here
<Yorlik>
I am getting some weird errors from boost asio these days. And I'm not using it in my code
<Yorlik>
Compile errors, that is.
<hkaiser>
Yorlik: we're not using it anymore either
<Yorlik>
Guess I have to fugure out where it's coming from then.
<hkaiser>
we use asio, but not boost asio
<Yorlik>
I'll check back with you if it's HPX related in any way.
<hkaiser>
ok
<Yorlik>
I made some progress using vcpkg and features, if you're still interested.
<hkaiser>
Yorlik: I am, just running at full capacity :/
<Yorlik>
Moar coffeeses :D
<hkaiser>
lol, good point
<Yorlik>
Just as a spoiler: depending on the HPX port, certain use cases / configurations or compile time switches, conditional dependencies can easily be integrated.
<Yorlik>
At least anything that is boolean type
<hkaiser>
Yorlik: nice - I think we shouldn't expose all and everything, but rather two, max four different configurations
<Yorlik>
Yes, could be simple collections of settings.
<Yorlik>
Also tests, examples, docs - can easily be made conditional.
<hkaiser>
true
<hkaiser>
I think we disabled those by default - nobody needs those built, usually
<Yorlik>
Yes.
<Yorlik>
In the past they even broke stuff for me (examples not compatible with windows)
<Yorlik>
Not sure if that's still an issue
<hkaiser>
not sure - you never reported those issues ;-)
<Yorlik>
I did, but not as an issue. I just dropped building the tests. I think there was a short chat here.
<Yorlik>
hkaiser: I guess I found the issue: We're using boost-asio and get double definitions. I guess I need to use the HPX version of asio to have it work again.
<hkaiser>
Yorlik: yes, that you need
<hkaiser>
if you specify HPX_WITH_FETCH_ASIO (vcpkg doesn't do that, but relies on vcpkg-asio) it will be installed as well
<Yorlik>
I'll just use Asio instead and find the according headers we need. Our Asio using code isn't that complicated.
<hkaiser>
yes
Yorlik has quit [Ping timeout: 268 seconds]
K-ballo has joined #ste||ar
Yorlik has joined #ste||ar
<Yorlik>
hkaiser: What were the reasons to not use the boost version of asio ?
<Yorlik>
Just curious
<hkaiser>
Yorlik: remove boost dependencies, step by step
<Yorlik>
I still don't understand why using asio instead of boost::asio is an advantage. Is it more compatible with the networking TS? They should be pretty much identical anyways. Or are there specific advantages? I simply don't want to duplicate functionality in my codebase. So - since we are more or less married with HPX I'll try to use anything HPX already offers, since it reduces integration complexity and a
<Yorlik>
bunch of other issues.
<hkaiser>
no other reason as to reduce dependency on boost
<hkaiser>
don't forget boost asio itself depends on other boost libraries
<Yorlik>
So asio is more self contained?
<hkaiser>
yes, 100% self-contained, depends only on std library
<Yorlik>
That's a strong reason imo.
<hkaiser>
nod
<Yorlik>
Had some issues switching which are still not resolved, but I now see why it makes sense.
<hkaiser>
shouldn't be hard to to switch, for us it was trivial
<Yorlik>
It's just a bit of work.
<Yorlik>
I'm mostly fighting myself being a bit rusty after the last months.
Yorlik has quit [Ping timeout: 240 seconds]
tufei__ has joined #ste||ar
tufei_ has quit [Remote host closed the connection]