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-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 260 seconds]
K-ballo1 is now known as K-ballo
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: Bye!]
Yorlik_ is now known as Yorlik
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 276 seconds]
K-ballo1 is now known as K-ballo
<Yorlik> Is there a way to initialize a vector from a dynamic start* and size_t size without copying and transfer ownership of the memory area to it? We cannot use span in this example, since we are on C++17 and can't go to C++20 (Unreal Engine constraint)? We are interfacing unsafe C code here which requires start* and size (low level networking stuff).
<Yorlik> Since the data is not yet deserialized and will be copied again, I'd like to save us from at last one copy.
<Yorlik> My current workaround resorts to memcpy after default initializing the vector, but I don't really like it.
<john98zakaria[m]> <Yorlik> "Is there a way to initialize a..." <- Check if this could guide you towards the desired solution
<john98zakaria[m]> <Yorlik> "Is there a way to initialize a..." <- Or maybe this one
<john98zakaria[m]> // Taken from the rdma example
<Yorlik> john98zakaria[m]: Thanks! Gotta do something else now - I'll look into it later.
hkaiser has joined #ste||ar
<srinivasyadav227> hkaiser: hi, small question regarding this https://github.com/STEllAR-GROUP/hpx/pull/5858#discussion_r900426942 , I think everything is in place because we need to capture HPX_EVE_ROOT.
<srinivasyadav227> I have done same thing that is being used for Asio currently (https://github.com/STEllAR-GROUP/hpx/blob/4543c1f4e502550f26d3d63774e3060d5b6bf1aa/cmake/templates/HPXConfig.cmake.in#L21) ..
<hkaiser> srinivasyadav227: in what dircetory is datapar.hpp located?
<hkaiser> ahh, hold on you're asking about the other comment - sorry
<srinivasyadav227> yes, for HPXConfig.cmake.in
<hkaiser> srinivasyadav227: yes, you're right - we need HPX_EVE_ROOT there
<hkaiser> I have resolved the comment
<srinivasyadav227> cool, thanks ! :), i will push the changes for other 2 comments right away!
<hkaiser> thanks!
<hkaiser> srinivasyadav227: btw, hpx/local/datapar.hpp doesn't exist yet, I think
<srinivasyadav227> should it be in libs/core/local_include/hpx/local ?
<hkaiser> yes
<srinivasyadav227> oh, yea, i does not exist
<srinivasyadav227> it*
<hkaiser> nod
<hkaiser> we still need to clean up all of the various include directories
<srinivasyadav227> should I just create datapar.hpp and add #include <hpx/parallel/datapar.hpp>
<hkaiser> if that's all it needs, sure
<srinivasyadav227> yes, because we already have datapar.hpp in libs/core/algorithms/include/parallel/datapar.hpp
<hkaiser> right, that's what I meant - we need clean up ...
<srinivasyadav227> got it! 💯
<hkaiser> now, that the whole local/remote repo separation is off the tabe, we have to unify things again
<srinivasyadav227> yeah
<hkaiser> srinivasyadav227: sorry for the latest comment ;-)
<srinivasyadav227> hkaiser: np ;-), sorry, silly mistake 😅
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 256 seconds]
K-ballo1 is now known as K-ballo
<satacker[m]> hkaiser: gonidelis Some mistake https://github.com/STEllAR-GROUP/hpx/pull/5920/files causes `is_invocable` to return false, but I think the logic is okay? no?
<hkaiser> I'll need a bit of time to understand what you're up to
<satacker[m]> https://pastebin.com/YW7ac1yS are the failing tests
<hkaiser> one note right away - please don't use variable names that start with underscores, those are reserved for the implementation
<satacker[m]> hkaiser: sorry, never again, i remember our meet
<hkaiser> no problem! no need to apologize
<satacker[m]> I made a mess because I had to get parameter pack from tuples which was in a variant
<hkaiser> your _is_invocable_f_tuple_unpack returns whether the expression is noexcept, is that what you want?
<satacker[m]> I referred some part of `std::apply` https://en.cppreference.com/w/cpp/utility/apply
<satacker[m]> The problem is that it's failing a simple test, is_receiver_of seems to have some problem
<hkaiser> satacker[m]: you could do that by just specializing a template, something like: https://gist.github.com/hkaiser/216ef0455b08fef4080e7f13c30b7b96
<satacker[m]> Are the ones failing
<hkaiser> the intention of your _is_invocable_f_tuple_unpack is to check whether things are invocable, but you're checking whether something is noexcept instead
<satacker[m]> That is used of the is_nothrow_receiver_of
<hkaiser> ok
<hkaiser> I missed that
<hkaiser> the gist I linked demonstrates how you can easily unpack the variant arguments
<satacker[m]> Yes, that's much easier and looks neat than the mess I made
<hkaiser> satacker[m]: for how to debug your issue: I usually take it step by step starting to manually instantiate the traits from the top down until you find the flaw
<satacker[m]> <hkaiser> "satacker: you could do that by..." <- https://godbolt.org/z/8qqh1nzra This unpacking fails
<hkaiser> sure
<hkaiser> you're trying to match a variant<tuple<Ts...>> against a variant<Ts...> specialization
<hkaiser> this works: https://godbolt.org/z/81W13rWea
<satacker[m]> Thanks, i was really confused when you suggested
<hkaiser> satacker[m]: I wanted to make it as simple as possible
<satacker[m]> I thought the tuple magically unpacked
<satacker[m]> XD
<satacker[m]> * magically unpacked (There must be something I don't know I thought)
<satacker[m]> <satacker[m]> "hkaiser: gonidelis Some mistake..." <- I found my mistakes, thanks (silly mistakes, not worth mentioning)
<hkaiser> satacker[m]: \o/