<weilewei>
so in hpx thread join(), internally has a std::unique_lock<mutex_type> l(mtx_);
<weilewei>
that's a lock
<hkaiser>
uhh ohh
<weilewei>
otherwise, I am not seeing other locks in my code...
<hkaiser>
what function in thread::join does suspend?
<hkaiser>
there is an explicit suspend, but the lock is unlocked before it's being called
<weilewei>
// register callback function to be called when thread exits if (threads::add_thread_exit_callback( id_, util::bind_front(&resume_thread, this_id))) { // wait for thread to be terminated util::unlock_guard<std::unique_lock<mutex_type>> ul(l);
<hkaiser>
also, ms[m], heller1, everybody: unfortunately we have lost all content that was added since December to all of our websites
<hkaiser>
any help you can give (send old versions of block posts, publications we added to the pages, etc. would be appreciated
<diehlpk_work>
hkaiser, heller1 I think we should add some publication and not only the Zenodo DOI on HPX's Readme
<hkaiser>
diehlpk_work: we could add the link to the publications page
<heller1>
hkaiser: uhoh, what happened?
<hkaiser>
the provider lost a harddrive
<heller1>
We should add the hpx publication
<heller1>
Lol
<hkaiser>
yah
<hkaiser>
some serious hardware trouble apparently - power outage can do that
<heller1>
Ugh
<heller1>
Glad it's back though
<hkaiser>
not all of it yet, but yah
<diehlpk_work>
hkaiser, We should put two publications there and the link to our publication list
<hkaiser>
hpx.stellar-group.org is 100% gone
<diehlpk_work>
We might could add HPX – An open source C++ Standard Library for Parallelism and Concurrency
<hkaiser>
diehlpk_work: ok
<diehlpk_work>
and another one
<heller1>
diehlpk_work: instead of a list of more or less random publications, one should have a "if you want to cite, use this one..."
<diehlpk_work>
Also we should add some references in the documentation
<diehlpk_work>
heller1, Yes, I agree but which one do we use?
<diehlpk_work>
I favor for the JOSS paper and the one above
<diehlpk_work>
HPX – An open source C++ Standard Library for Parallelism and Concurrency
<diehlpk_work>
Most people used this one here in the last two years
<diehlpk_work>
We got 25 citations for this one
<heller1>
And the pgas one
<diehlpk_work>
Ok, so we could add these two and the JOSS paper or?
<heller1>
Which one represents hpx the most?
<diehlpk_work>
I like the HPX – An open source C++ Standard Library for Parallelism and Concurrency
<diehlpk_work>
We have a nice overview of all HPX components there
<diehlpk_work>
or the JOSS paper
<heller1>
Is there joss paper accepted?
<diehlpk_work>
No, hkaiser wants to do a final edit before submissiom
<diehlpk_work>
Since it is official now, I joined the JOSS fournal as the editor for Computational fracture mechanics, Applied mathematics, C++, asynchronous and task-based programming
<ms[m]>
I can try to recreate some of the pages where I more or less remember what they contained
<hkaiser>
ms[m]: nod, let me create a login for you
<ms[m]>
diehlpk_work: do we just want a bibtex entry in the docs that people can copy-paste into their bibtex file? I'm not sure I understood what you were looking for with https://github.com/STEllAR-GROUP/hpx/issues/4698
<zao>
archive.org sadly only has a snapshot from April 2019.
<hkaiser>
ms[m]: what user name should I use, whta email?
<ms[m]>
hkaiser: simbergm@cscs.ch is fine, simbergm as user name
<hkaiser>
ms[m]: done, just go through the change password to login
<diehlpk_work>
ms[m], I was asking if we can put a bibtex file and justy put the bibtex entry in the documentation to obtain the citation
<ms[m]>
hkaiser: thanks
<ms[m]>
diehlpk_work: yes, absolutely
<ms[m]>
we just either include a file inline or have it directly in the docs
<diehlpk_work>
Ok, so if people provide you with the references, could you add them?
<ms[m]>
yeah, sure
<ms[m]>
don't we want just one though? at least as the thing to cite
<ms[m]>
"Use the following information to cite HPX in your work..."
<diehlpk_work>
As starting point we could use the ones from the JOSS paper
<diehlpk_work>
I think these are two different things
<diehlpk_work>
We should provide one or two references on the READMe
<diehlpk_work>
Citing
<diehlpk_work>
In publications the latest release of HPX can be cited as: zenodo_doi .
<diehlpk_work>
I think we should add a paper there. Probably the JOSS paper
<diehlpk_work>
And do the same for the modules
nickrobison12 has joined #ste||ar
<nickrobison12>
Hi folks. I was hoping someone could help me understand the HPX serialization process. I have a pretty simple struct:
<nickrobison12>
struct joined_location { string safegraph_place_id; double latitude; double longitude; uint64_t location_cbg; // Serialization support: even if all of the code below runs on one // locality only, we need to provide an (empty) implementation for the // serialization as all arguments passed to actions have to support this.
<nickrobison12>
friend class hpx::serialization::access; template<typename Archive> void serialize(Archive &ar, const unsigned int version) const { ar & safegraph_place_id & latitude & longitude & location_cbg; }};
<K-ballo>
that's an odd comment to have there..
<nickrobison12>
When compiling I'm getting an error: static_assert failed due to requirement 'dependent_false<const double>::value' "Not serialization method found"
<K-ballo>
your serialize member is const, it's not supposed to as it does both load and save
<nickrobison12>
Well that's embarrassing.
<nickrobison12>
Do components need to implement serialization as well, or only data class?
nickrobison has quit [Remote host closed the connection]
<ms[m]>
hkaiser: heller ? ^
<ms[m]>
diehlpk_work: so we'd want:
<heller1>
nickrobison12: only if you need to migrate them
<ms[m]>
1. the zenodo doi on the readme and in the docs for citing hpx the software
<ms[m]>
2. a page in the docs with all the hpx papers (joss and some of the older papers, including bibtex entries)
<ms[m]>
3. a page with hpx-related papers, but this should be what already existed on hpx.stellar-group.org before it went down
<diehlpk_work>
ms[m], 1. the zenodo doi and the JOSS paper on the readme and a link to all publication on our webpage
<heller1>
nickrobison12: also, if you're just local, there's no need to use actions. But yes, all arguments to actions need to be serializable.
<diehlpk_work>
2. I would put the references on the module page
<ms[m]>
diehlpk_work: is the idea that people cite both joss and zenodo?
<heller1>
The const needs to go, as K-ballo said
<ms[m]>
the modules shouldn't be cited
<ms[m]>
I'm not sure what references you want to put there
<nickrobison12>
heller1 That's what I was thinking. It's making more sense now, appreciate the answers to by dumb questions!
<diehlpk_work>
yes, joss for hpx in general and zendoo for the specific version
<heller1>
There are no dumb questions
<ms[m]>
diehlpk_work: ok, zenodo and joss make sense in that case
<diehlpk_work>
ms[m], Fir the module it is not about citing them. More for details
<ms[m]>
I'd probably add just one page in the docs though, and link to it from the readme
<ms[m]>
right, well, that's module specific
<ms[m]>
I don't think we have many papers to cite for any module
<ms[m]>
some are in the code and I like them more there because it's much easier to notice for someone changing that particular part
<gonidelis[m]>
hkaiser: Is it a good idea to use `iter_sent.hpp` that I created last week, for my `is_sentinel_for` trait test? If not, then how could I find a proper sentinel iterator pair for testing?
nan11 has joined #ste||ar
weilewei has joined #ste||ar
<hkaiser>
gonidelis[m]: sure, feel free to use it
<K-ballo>
gonidelis[m]: make sure to test with iterator pairs as well
<gonidelis[m]>
ok thank you both :)
akheir has joined #ste||ar
bita_ has joined #ste||ar
<gonidelis[m]>
hkaiser: Just watched the Template Meta Programming lecture... Just amazing! The lecture answered like 5-6 questions that I already had while your students questions were right on point on what I would ask if I was there. You described the core concepts of template programming in a way that it can't be found in regular reference pages. I am really thrilled... Going back to code should be a lot easier now :q
nickrobison12 has quit [Remote host closed the connection]
<K-ballo>
test(...) is C style variadics, check cppreference
<K-ballo>
fwiw that's an old style trait.. apparently because it needed to support vs2013?
<K-ballo>
maybe we can bring it up to this century now
<gonidelis[m]>
K-ballo: I mean, where could I find how test works?
<gonidelis[m]>
`test()` ^^
<K-ballo>
some old school books... abraham's metaprogramming one, probably
<K-ballo>
test() doesn't do anything, it never runs
<K-ballo>
it is only being used to drive overload resolution, and find out which overload the compiler picks
<K-ballo>
that's one yucky trait..
<diehlpk_work>
hkaiser, LSU will integrate GitHub classroom into LSU;s moodle this fall.
<diehlpk_work>
So we can use it in our course
<hkaiser>
nice
nan11 has quit [Remote host closed the connection]
karame_ has quit [Remote host closed the connection]
karame_ has joined #ste||ar
<diehlpk_work>
can't install hpx:
<diehlpk_work>
- nothing provides libboost_program_options.so.1.69.0()(64bit) needed by hpx-1.4.1-2.fc33.x86_64
<diehlpk_work>
Anyone seen this issue?
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<hkaiser>
diehlpk_work: is boost program_options available?
<diehlpk_work>
hkaiser, Need to check it is a bug in the upcoming Fedora release
nan11 has joined #ste||ar
weilewei has quit [Remote host closed the connection]
weilewei has joined #ste||ar
akheir has quit [Read error: Connection reset by peer]
nikunj has quit [Ping timeout: 246 seconds]
nikunj has joined #ste||ar
<weilewei>
Does anyone have successfully built hpx these days? With what commit?
<zao>
Haven't tried in a while.
<Yorlik>
weilewei: I built the core library just yesterday or yesterday before
<Yorlik>
Actually I built that PR doing the changes on thread_mapper, and then the recent stable
<weilewei>
Yorlik don't you have compilation issue with /gpfs/alpine/proj-shared/cph102/weile/dev/src/hpx_mpi_async/hpx/components/containers/partitioned_vector/src/partitioned_vector_component_std_string.cpp:33:10: required from here/gpfs/alpine/proj-shared/cph102/weile/dev/src/hpx_mpi_async/hpx/libs/futures/include/hpx/futures/future.hpp:426:42: error:
<weilewei>
static assertion failed: Cannot use the dummy implementation of future_then_dispatch, please use one of the template specialization. static_assert(sizeof(Future) == 0, "Cannot use the
<Yorlik>
I do not build the mpi stuff
<Yorlik>
So hpx_mpi_async stuff I'm, pretty sure is not in my build
<weilewei>
even without hpx mpi async, same error occurs
<weilewei>
hpx_mpi_async is my folder name...
<Yorlik>
woops
<Yorlik>
You're building on Alpine Linux?
<Yorlik>
<-- Does Windoze
<weilewei>
it is on debian linux
<Yorlik>
Stable or Sid?
<Yorlik>
Stable Debian is very conservative / lagging behind.
<weilewei>
not sure...
<Yorlik>
Buster (Debian 10) is current
<Yorlik>
If you didn't do anything special you're on Buster most likely
<Yorlik>
But I think it ~should build there.
<Yorlik>
weilewei: Did you change many of the default CMake flags? Because I did not
<Yorlik>
My build is prety close to default.
<Yorlik>
And i am not building tests or examples
<weilewei>
Yorlik mine too, same
<Yorlik>
Is this build error of yours in the core library?